[tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  needs_information
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.2.1-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  regression, tor-bridge-client,       |  Actual Points:
  s8-errors, tbb-wants                           |
Parent ID:                                       |         Points:  0.5
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor8-can
-------------------------------------------------+-------------------------

Comment (by teor):

 I think we might have fixed some more parts of this issue in #24392: we
 now distinguish between bridges that might be reachable, and bridges that
 are definitely reachable.

 This partially reverts some of the changes in #23347 and #17750:
 * we only delay bridge descriptor fetches when we have a bridge that is
 definitely running,
 * we only delay directory fetches when all of our bridges are definitely
 not running,
 * we keep on retrying directory downloads every time we receive a new
 bridge descriptor, until we definitely have a reachable bridge.

 Please re-test my branch bug24367_032 from github.

 Replying to [comment:17 gk]:
 > If you look at the log for d7833c9d27feed9 you'll see that the guard
 list gets updated with `obfs4` bridges as is done in the log for
 6370fb77c586e9a:
 > {{{
 > Nov 22 11:37:05.000 [info] entry_guards_update_primary(): Primary entry
 guards have changed. New primary guard list is:
 > Nov 22 11:37:05.000 [info] entry_guards_update_primary():   1/3:
 [bridge] ($A832D176ECD5C7C6B58825AE22FC4C90FA249637)
 > Nov 22 11:37:05.000 [info] entry_guards_update_primary():   2/3:
 [bridge] ($D9A82D2F9C2F65A18407B1D2B764F130847F8B5D)
 > Nov 22 11:37:05.000 [info] entry_guards_update_primary():   3/3:
 [bridge] ($CDF2E852BF539B82BD10E27E9115A31734E378C2)
 > }}}
 > So, that part is good. However and contrary to what is happening in the
 6370fb77c586e9a case those are not getting used/tried. Rather, the
 previously used `obfs3` bridge is still present:
 > {{{
 > Nov 22 11:37:06.000 [info] sample_reachable_filtered_entry_guards():
 (Selected [bridge] ($A09D536DD1752D542E1FBB3C9CE4449D51298239).)
 > Nov 22 11:37:06.000 [info] select_entry_guard_for_circuit(): No primary
 or confirmed guards available. Selected random guard [bridge]
 ($A09D536DD1752D542E1FBB3C9CE4449D51298239) for circuit. Will try other
 guards before using this circuit.
 > }}}

 This looks like a bug in sample_reachable_filtered_entry_guards(). It
 looks like we are keeping the old bridge
 (A09D536DD1752D542E1FBB3C9CE4449D51298239) as a possible non-primary non-
 confirmed guard, even when it is no longer configured as a bridge. That's
 not good at all. We should be discarding it entirely.

 I'm going to leave this to someone else to fix.

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