[tor-bugs] #23605 [Core Tor/Tor]: BOOTSTRAP PROGRESS=80 is a lie

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

#23605: BOOTSTRAP PROGRESS=80 is a lie
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  (none)
  catalyst               |
         Type:  defect   |     Status:  new
     Priority:  High     |  Milestone:  Tor: 0.3.3.x-final
    Component:  Core     |    Version:
  Tor/Tor                |   Keywords:  bootstrap clock-skew tor-guard
     Severity:  Normal   |  usability ux
Actual Points:           |  Parent ID:  #22266
       Points:           |   Reviewer:
      Sponsor:           |
-------------------------+-------------------------------------------------
 Tor can report `BOOTSTRAP_STATUS_CONN_OR` (PROGRESS=80, "Connecting to the
 Tor network") when it actually can do no such thing.  In some situations
 (e.g., clock skew) this causes progress to get stuck at 80% indefinitely,
 resulting in very poor user experience.

 Right now `update_router_have_minimum_dir_info()` reports the
 `BOOTSTRAP_STATUS_CONN_OR` event if there's a "reasonably live" consensus
 and enough descriptors downloaded.  A client with a clock skewed several
 hours into the future can get stalled here indefinitely due to inability
 to select a guard: if the client's clock is skewed, it will never have a
 live consensus.  (Guard selection seems to require a non-expired
 consensus, rather than a reasonably live consensus at least during
 bootstrap.)

 We should either relax the guard selection consensus liveness requirement,
 or avoid reporting `BOOTSTRAP_STATUS_CONN_OR` when we have no reasonable
 chance of actually connecting to a guard for building application
 circuits.

 Arguably we shouldn't start downloading descriptors until we have a non-
 expired consensus either, because that gets represented as a considerable
 chunk of the progress bar (40%->80%) in a way that could be misleading to
 a user.  Making that change without additional work would cause bootstrap
 to get stuck at 40% instead of 80%, which might be an improvement.  This
 can already happen if the client's clock is skewed several hours in the
 past.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23605>
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