[tor-bugs] #25061 [Core Tor/Tor]: Relays consider it a bootstrapping failure if they can't extend for somebody else's circuit

[Tor Bug Tracker & Wiki]

#25061: Relays consider it a bootstrapping failure if they can't extend for
somebody else's circuit
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:
                                                 |  catalyst
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.4.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  backport-032, 033-backport,          |  Actual Points:
  stability, 033-triage-20180320,                |
  033-included-20180320, s8-errors, bootstrap    |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8
-------------------------------------------------+-------------------------

Comment (by catalyst):

 There are four places that call control_event_bootstrap_prob_or():

 * `connection_or_about_to_close()` in connection_or.c
     - This seems to have a fair amount of code in the TLS handshake
       failure case, which could probably be factored out.  It also
       calls channel_closed() before any of the other stuff, which
       maybe should be reordered?
     - It's only really called through connection_unlink() in main.c.

 * `connection_or_connect_failed()` in connection_or.c
     - This fairly simple function has multiple callers

 * `connection_or_connect()` in connection_or.c
     - This seems to only handle the case where a PT proxy is missing.
       Notably, it does NOT call `authdir_mode_tests_reachability()`.

 * `connection_or_client_learned_peer_id()` in connection_or.c
     - This seems to be when a router cert has an unexpected ID.

 I'm thinking of ways to move the logic that currently calls
 `control_event_bootstrap_prob_or()` into either the channel layer or even
 higher.  I think having the callers of `control_event_bootstrap_prob_or()`
 call `authdir_mode_tests_reachability()` themselves is unnecessary when
 `control_event_bootstrap_prob_or()` itself could probably safely do so.
 (The one case above where the caller doesn't call
 `authdir_mode_tests_reachability()` is a pluggable transport situation,
 and dirauths don't use pluggable transports that I know of.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25061#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online