This is client side and related to 27471 for previous commit that fixes this
issue.

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

When storing a descriptor in the client cache, if we are about to replace an
existing descriptor, make sure to close every introduction circuits of the old
descriptor so we don't have leftovers lying around.

Ticket 27471 describes a situation where tor is sending an INTRODUCE1 cell on
an introduction circuit for which it doesn't have a matching intro point
object (taken from the descriptor).

The main theory is that, after a new descriptor showed up, the introduction
points changed which led to selecting an introduction circuit not used by the
service anymore thus for which we are unable to find the corresponding
introduction point within the descriptor we just fetched.

Closes #27471.

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

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

Both client and service had their own code for this. Consolidate into one
place so we avoid duplication.

Closes #27549

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

Occasionally, key pinning doesn't catch a relay that shares an ed25519
ID with another relay.  Log the identity fingerprints and the shared
ed25519 ID when this happens, instead of making a BUG() warning.

Fixes bug 27800; bugfix on 0.3.2.1-alpha.

"ours" to avoid version bump.

Commit 488e2b00 introduced an issue, most
likely introduced by a bad copy paste, that made us stop reading on the
connection if our write bandwidth limit was reached.

The problem is that because "read_blocked_on_bw" was never set, the connection
was never reenabled for reading.

This is most likely the cause of #27813 where bytes were accumulating in the
kernel TCP bufers because tor was not doing reads. Only relays with
RelayBandwidthRate would suffer from this but affecting all relays connecting
to them. And using that tor option is recommended and best practice so many
many relays have it enabled.

Fixes #28089.