[tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[Tor Bug Tracker & Wiki]

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--------------------------+------------------------------------
 Reporter:  arma          |          Owner:
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.3.0.7
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by teor):

 Replying to [comment:4 teor]:
 > Replying to [ticket:22400 arma]:
 > > And it launches a parallel fetch to an authority too, just like it's
 supposed to:
 > > {{{
 > > May 25 20:58:07.185 [info] directory_send_command(): Downloading
 consensus from 154.35.175.225:443 using /tor/status-vote/current
 /consensus-
 microdesc/0232AF+14C131+23D15D+49015F+D586D1+E8A9C4+ED03BB+EFCBE7.z
 > > }}}
 >
 > No, that's a bug: #20604.
 >
 > There's no need for every client to contact an authority: they didn't in
 0.2.8, and they all worked fine. But when the exponential backoff code was
 merged, there was no provision for a set initial delay, and we couldn't
 define the schedules so that we'd get a short delay without blowing out
 the remaining attempts. So we got this compromise.

 Sorry, I was wrong.

 This happened because we never reset download statuses before we use them.
 See #17750.

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