George Kadianakis authored 8 years ago and Nick Mathewson committed 8 years ago

- Make sure we check at least two guards for descriptor before making
  circuits. We typically use the first primary guard for circuits, but
  it can also happen that we use the second primary guard (e.g. if we
  pick our first primary guard as an exit), so we should make sure we
  have descriptors for both of them.

- Remove BUG() from the guard_has_descriptor() check since we now know
  that this can happen in rare but legitimate situations as well, and we
  should just move to the next guard in that case.

"Ours" merge to avoid version bump

Apparently some unixes don't like this.
Part of #21581.

Part of 21581.

(But use bash if it's available.)
This is a workaround until we remove bash-specific code in 19699.

Fixes bug 21581; bugfix on 21562, not in any released version of tor.

This is an "ours" merge to avoid a version bump.

This is an "ours" merge to avoid taking a version bump

This is an "ours" merge to avoid taking a version bump, and to
avoid replaying the post-0.2.7.6 history of "maint-0.2.7-redux" onto maint-0.2.8, which already included the relevant changes.

"ours" merge to avoid version bumps

"ours" merge to avoid version bumps

"ours" merge to avoid bumping version

Previously I'd made a bad assumption in the implementation of
prop271 in 0.3.0.1-alpha: I'd assumed that there couldn't be two
guards with the same identity.  That's true for non-bridges, but in
the bridge case, we allow two bridges to have the same ID if they
have different addr:port combinations -- in order to have the same
bridge ID running multiple PTs.

Fortunately, this assumption wasn't deeply ingrained: we stop
enforcing the "one guard per ID" rule in the bridge case, and
instead enforce "one guard per <id,addr,port>".

We also needed to tweak our implementation of
get_bridge_info_for_guard, since it made the same incorrect
assumption.

Fixes bug 21027; bugfix on 0.3.0.1-alpha.

Since 0.2.4.11-alpha (in 01966479) we've tried to randomize
the start time to up to some time in the past.  But unfortunately we
allowed the start time to be in the future as well, which isn't
really legit.

The new behavior lets the start time be be up to
MAX(cert_lifetime-2days, 0) in the past, but never in the future.

Fixes bug 21420; bugfix on 0.2.4.11-alpha.

This ensures we reliably call chutney's newer tools/test-network.sh when
available.

Fixes bug 21562; bugfix on tor-0.2.9.1-alpha.

Part of 21570.

Requires the chutney changes from 21572.
(Otherwise, asks users to upgrade their chutney.)

Implements 21570.

Teor thinks that this connection_dirserv_add_dir_bytes_to_outbuf()
might be the problem, if the "remaining" calculation underflows.  So
I'm adding a couple of checks there, and improving the casts.

Possible fix or diagnostic for 21369.

Requires the equivalent chutney changes in 21571.

Part of 21570.

David Goulet authored 8 years ago and Nick Mathewson committed 8 years ago

When encoding a legacy ESTABLISH_INTRO cell, we were using the sizeof() on a
pointer instead of using the real size of the destination buffer leading to an
overflow passing an enormous value to the signing digest function.
Fortunately, that value was only used to make sure the destination buffer
length was big enough for the key size and in this case it always was because
of the overflow.

Fixes #21553

Signed-off-by: David Goulet <dgoulet@torproject.org>

Fixes a case of 21007; bugfix on 0.3.0.1-alpha when prop271 was
implemented. Found by toralf.

scan-build found that we we checking UseEntryGuards twice.

Fixes bug 21492.