Re: [tor-bugs] #7733 [Tor]: Two channels required for bootstrap

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#7733: Two channels required for bootstrap
------------------------+-----------------------------------------------
     Reporter:  dcf     |      Owner:  nickm
         Type:  defect  |     Status:  needs_review
     Priority:  normal  |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-client flashproxy 025-triaged
Actual Points:          |  Parent ID:
       Points:          |
------------------------+-----------------------------------------------
Changes (by nickm):

 * status:  assigned => needs_review
 * milestone:  Tor: 0.2.5.x-final => Tor: 0.2.6.x-final


Comment:

 Diagnosis:

 The reason that we're calling launch_direct_bridge_descriptor_fetch() even
 when starting with a bridge descriptor is that we only reset the download
 schedule on learning a descriptor when we are learning it at startup.
 That's a distraction.

 The reason we're doing it with the ID set to 0 -- and thereby causing
 another channel to be launched -- is that requests for the bridge's
 descriptor always use bridge->identity, and never a learned identity from
 the bridge descriptor.

 So we ''could maybe'' fix this by altering learned_bridge_descriptor so
 that it sets bridge->identity from ri->identity if the bridge identity was
 not previously set.  Something like branch 'bug7733a' in my public
 repository would solve it. (Not tested)

 Alternatively, we could cache bridge-address => identity mappings in the
 state file.

 I worry about two things, though:
   * having learned_bridge_descriptor race with fetch_bridge_descriptors.
 If the second happens first, we'll launch a channel with an unknown
 identity.
   * the change in handling for a bridge that changes its identity.

 It's possible neither of these concerns is valid, but given the relatively
 small impact of this issue, and the possible hard-to-figure-out
 destabilization in bootstrapping, I think this should wait for 0.2.6.

 (Also, this is to a certain extent not-a-bug: it is totally valid for Tor
 to open multiple connections through a single PT to a single bridge; this
 is expected behavior when rotating connections.  PTs should IMO handle
 this.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7733#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs