By calling circuit_n_chan_done() unconditionally on close, we were
closing pending connections that might not have been pending quite for
the connection we were closing.  Fix for bug 9880.

Thanks to skruffy for finding this and explaining it patiently until
we understood.

Now that we no longer build it from torify.in, we need to list it
manually.

guilhem authored 11 years ago and Nick Mathewson committed 11 years ago

Since torify has been removed from tsocks, it doesn't need to be
preprocessed. Closes #5505.

To fix #6033, we disabled TLS 1.1 and 1.2.  Eventually, OpenSSL fixed
the bug behind #6033.

I've considered alternate implementations that do more testing to see
if there's secretly an OpenSSL 1.0.1c or something that secretly has a
backport of the OpenSSL 1.0.1e fix, and decided against it on the
grounds of complexity.

Makes mingw64 a bit happier.

This avoids skew warnings as authorities test reachability.

Fix 9798; fix not on any released Tor.

this was causing directory authorities to send a time of 0 on all
connections they generated themselves, which means everybody reachability
test caused a time skew warning in the log for that relay.

(i didn't just revert, because the changes file has been modified by
other later commits.)

Implements part of proposal 222.  We can do this safely, since
REND_CACHE_MAX_SKEW is 24 hours.

This isn't actually much of an issue, since only relays send
AUTHENTICATE cells, but while we're removing timestamps, we might as
well do this too.

Part of proposal 222.  I didn't take the approach in the proposal of
using a time-based HMAC, since that was a bad-prng-mitigation hack
from SSL3, and in real life, if you don't have a good RNG, you're
hopeless as a Tor server.

For now, round down to the nearest 10 minutes.  Later, eliminate entirely by
setting a consensus parameter.

(This rounding is safe because, in 0.2.2, where the timestamp mattered,
REND_REPLAY_TIME_INTERVAL was a nice generous 60 minutes.)

Implements part of proposal 222.