#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs