If buf_shrink_freelists calls log_warn for some reason, we don't want the log
call itself to throw buf_shrink_freelists further off the rails.

Sending a log message to a control port can cause Tor to allocate a buffer,
thereby changing the length of the freelist behind buf_shrink_freelists's back,
thereby causing an assertion to fail.

Fixes bug #1125.

We would never actually enforce multiplicity rules when parsing
annotations, since the counts array never got entries added to it for
annotations in the token list that got added by earlier calls to
tokenize_string.

Found by piebeer.

When we introduced the code to close non-open OR connections after
KeepalivePeriod had passed, we replaced some code that said
    if (!connection_is_open(conn)) {
     /* let it keep handshaking forever */
    } else if (do other tests here) {
      ...
with new code that said
    if (!connection_is_open(conn) && past_keepalive) {
     /* let it keep handshaking forever */
    } else if (do other tests here) {
      ...

This was a mistake, since it made all the other tests start applying
to non-open connections, thus causing bug 1840, where non-open
connections get closed way early.

Fixes bug 1840.  Bugfix on 0.2.1.26 (commit 67b38d50).

Sebastian Hahn authored 14 years ago and Nick Mathewson committed 14 years ago

(Partial backport of 150ed553, 161b2750, and 4c948ffd.)

If the voting interval was short enough, the two-minutes delay
of CONSENSUS_MIN_SECONDS_BEFORE_CACHING would confuse bridges
to the point where they would assert before downloading a consensus.
It it was even shorter (<4 minutes, I think), caches would
assert too.  This patch fixes that by having replacing the
two-minutes value with MIN(2 minutes, interval/16).

Bugfix for 1141; the cache bug could occur since 0.2.0.8-alpha, so
I'm calling this a bugfix on that.  Robert Hogan diagnosed this.
Done as a patch against maint-0.2.1, since it makes it hard to
run some kinds of testing networks.

Once upon a time it made sense to keep all the Debian files in the
main Tor distribution, since repeatedly merging them back in was hard.
Now that we're on git, that's no longer so.

Peter's debian repository at debian/tor.git on our git server has the
most recent version of the tor-on-debian packaging stuff, and the versions
in our own repository have gotten out of date.

Resolves bug #1735.

Our code assumed that any version of OpenSSL before 0.9.8l could not
possibly require SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION.  This is
so... except that many vendors have backported the flag from later
versions of openssl when they backported the RFC5476 renegotiation
feature.

The new behavior is particularly annoying to detect.  Previously,
leaving SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION unset meant that
clients would fail to renegotiate.  People noticed that one fast!
Now, OpenSSL's RFC5476 support means that clients will happily talk to
any servers there are, but servers won't accept renegotiation requests
from unpatched clients unless SSL_OP_ALLOW_etc is set.  More fun:
servers send back a "no renegotiation for you!" error, which unpatched
clients respond to by stalling, and generally producing no useful
error message.

This might not be _the_ cause of bug 1346, but it is quite likely _a_
cause for bug 1346.

it's perfect, let's ship it

From http://archives.seul.org/tor/relays/Mar-2010/msg00006.html :

   As I understand it, the bug should show up on relays that don't set
   Address to an IP address (so they need to resolve their Address
   line or their hostname to guess their IP address), and their
   hostname or Address line fails to resolve -- at that point they'll
   pick a random 4 bytes out of memory and call that their address. At
   the same time, relays that *do* successfully resolve their address
   will ignore the result, and only come up with a useful address if
   their interface address happens to be a public IP address.

Treat strings returned from signed_descriptor_get_body_impl() as not
NUL-terminated. Since the length of the strings is available, this is
not a big problem.

Discovered by rieo.

Another dereference-then-NULL-check sequence. No reports of this bug
triggered in the wild. Fixes bugreport 1256.

Thanks to ekir for discovering and reporting this bug.

Fix a dereference-then-NULL-check sequence. This bug wasn't triggered
in the wild, but we should fix it anyways in case it ever happens.
Also make sure users get a note about this being a bug when they
see it in their log.

Thanks to ekir for discovering and reporting this bug.