[tor-bugs] #20269 [Core Tor/Tor]: bridge users ignore their cached consensus file on startup

[Tor Bug Tracker & Wiki]

#20269: bridge users ignore their cached consensus file on startup
--------------------------+------------------------------------
 Reporter:  arma          |          Owner:
     Type:  defect        |         Status:  needs_review
 Priority:  Medium        |      Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  029-proposed  |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------
Description changed by arma:

Old description:

> When a client has UseBridges set to 1, and it has a cached microdesc
> consensus in its datadir, when it starts up it loads that consensus file
> from disk, and calls {{{networkstatus_set_current_consensus()}}} on it.
>
> That function checks
> {{{
>   if (flav != usable_consensus_flavor() &&
>       !directory_caches_dir_info(options)) {
>     /* This consensus is totally boring to us: we won't use it, and we
> won't
>      * serve it.  Drop it. */
>     goto done;
>   }
> }}}
>
> and in this case, {{{usable_consensus_flavor()}}} checks
> {{{we_use_microdescriptors_for_circuits()}}} which decides
> {{{
>     /* If we are configured to use bridges and none of our bridges
>      * know what a microdescriptor is, the answer is no. */
>     if (options->UseBridges && !any_bridge_supports_microdescriptors())
>       return 0;
> }}}
>
> That is, if you have bridges but you haven't marked any of them up yet,
> then you default to using the old-flavor consensus, so when you read your
> microdesc-consensus from disk, you quietly discard it. This bug results
> in bridge users always fetching a new consensus at start, even when they
> don't need to.
>
> (Bug reported by skruffy's owner.)

New description:

 When a client has UseBridges set to 1, and it has a cached microdesc
 consensus in its datadir, when it starts up it loads that consensus file
 from disk, and calls {{{networkstatus_set_current_consensus()}}} on it.

 That function checks
 {{{
   if (flav != usable_consensus_flavor() &&
       !directory_caches_dir_info(options)) {
     /* This consensus is totally boring to us: we won't use it, and we
 won't
      * serve it.  Drop it. */
     goto done;
   }
 }}}

 and in this case, {{{usable_consensus_flavor()}}} checks
 {{{we_use_microdescriptors_for_circuits()}}} which decides
 {{{
     /* If we are configured to use bridges and none of our bridges
      * know what a microdescriptor is, the answer is no. */
     if (options->UseBridges && !any_bridge_supports_microdescriptors())
       return 0;
 }}}

 That is, if you have bridges but you haven't marked any of them up yet,
 then you default to using the old-flavor consensus, so when you read your
 microdesc-consensus from disk, you quietly discard it. This bug results in
 bridge users always fetching a new consensus at start, even when they
 don't need to.

 (Bug reported by [a person who was helpful at first but now seems to be
 trying to distract me and prevent me from fixing Tor bugs].)

--

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