1. The things we're really trying to protect - contact identities,
message contents, etc - can't be erased from memory because they're
encapsulated inside objects we don't control.
2. Long-term secrets can't be protected by erasing them from memory
because they're stored in the database and the database key has to be
held in memory whenever the app's running.
3. If the runtime uses a compacting garbage collector then we have no
way to ensure an object is erased from memory.
4. Trying to erase secrets from memory makes the code more complex.
Conclusion: Let's not try to protect secrets from an attacker who can
read arbitrary memory locations.
DuplexOutgoingSession flushes its output stream if it's idle for a
transport-defined interval, causing an empty frame to be sent. The TCP
and Tor plugins use a socket timeout equal to twice the idle interval to
detect dead connections.
See bugs #27, #46 and #60.
Two changes have been made to Tor:
1. Set can_complete_circuit to false when the network is disabled, and
don't try to build introduction circuits while can_complete_circuit is
false. This avoids a situation where Tor tries to build introduction
circuits as soon as the network is re-enabled, all the circuits fail,
and then Tor waits 5 minutes before trying to build more.
2. Added a FORGETHS command to the control protocol which clears any
cached client state relating to a specified hidden service. This can be
used to flush state that's likely to be stale before trying to connect
to a hidden service with an unstable network connection.
Support for the FORGETHS command was also added to jtorctl.
Tor has a controller command, TAKEOWNERSHIP, and a configuration option,
__OwningControllerProcess, that work together to ensure Tor shuts down
when the controlling process dies and/or disconnects from the control
port. By using them we can avoid creating runaway Tor processes that
have to be killed with hacks.
akwizgran