#20528: Make sure bridge clients update bridges when options are updated ---------------------------+------------------------------ Reporter: teor | Owner: Type: defect | Status: new Priority: Medium | Milestone: Tor: 0.2.??? Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: bridge-client | Actual Points: Parent ID: | Points: 1 Reviewer: | Sponsor: ---------------------------+------------------------------ Changes (by teor):
* keywords: bridge-client, bridge-bypass => bridge-client Old description: > Currently, we keep our consensus and guards and nodes, even after an > options transition. > > A user reports that this may bypass bridges when bridge fingerprints are > misconfigured, and we switch between bridge client and regular client > mode: > https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html > This bypass is likely timing-related - I suspect it only occurs if tor > tries a connection to the bridge before the new bridges and pluggable > transports are properly configured. > > So we should reload the cached consensus, reset downloads and reconfigure > guards after options transitions. > > Conceptually, we want to do something like: > (it currently doesn't work due to assertions, so we probably want to > conditionalise parts of it on has_reasonably_live_consensus() or > something) > {{{ > diff --git a/src/or/config.c b/src/or/config.c > index fef1208..4ecf0ba 100644 > --- a/src/or/config.c > +++ b/src/or/config.c > @@ -1183,6 +1183,13 @@ consider_adding_dir_servers(const or_options_t > *options, > for (cl = options->FallbackDir; cl; cl = cl->next) > if (parse_dir_fallback_line(cl->value, 0)<0) > return -1; > + > + /* Reset the consensus, because the authorities might have changed */ > + time_t now = time(NULL); > + networkstatus_reset_warnings(); > + router_reload_consensus_networkstatus(); > + routerlist_retry_directory_downloads(now); > + > return 0; > } > > @@ -1889,6 +1896,11 @@ options_act(const or_options_t *old_options) > circuit_mark_all_unused_circs(); > circuit_mark_all_dirty_circs_as_unusable(); > revise_trackexithosts = 1; > + > + /* And reload the consensus, which also updates guards (and > bridges) */ > + time_t now = time(NULL); > + router_reload_consensus_networkstatus(); > + routerlist_retry_directory_downloads(now); > } > > if (!smartlist_strings_eq(old_options->TrackHostExits, > }}} New description: Currently, we keep our consensus and guards and nodes, even after an options transition. ~~A user reports that this may bypass bridges when bridge fingerprints are misconfigured, and we switch between bridge client and regular client mode: https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html This bypass is likely timing-related - I suspect it only occurs if tor tries a connection to the bridge before the new bridges and pluggable transports are properly configured.~~ So we should reload the cached consensus, reset downloads and reconfigure guards after options transitions. Conceptually, we want to do something like: (it currently doesn't work due to assertions, so we probably want to conditionalise parts of it on has_reasonably_live_consensus() or something) {{{ diff --git a/src/or/config.c b/src/or/config.c index fef1208..4ecf0ba 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -1183,6 +1183,13 @@ consider_adding_dir_servers(const or_options_t *options, for (cl = options->FallbackDir; cl; cl = cl->next) if (parse_dir_fallback_line(cl->value, 0)<0) return -1; + + /* Reset the consensus, because the authorities might have changed */ + time_t now = time(NULL); + networkstatus_reset_warnings(); + router_reload_consensus_networkstatus(); + routerlist_retry_directory_downloads(now); + return 0; } @@ -1889,6 +1896,11 @@ options_act(const or_options_t *old_options) circuit_mark_all_unused_circs(); circuit_mark_all_dirty_circs_as_unusable(); revise_trackexithosts = 1; + + /* And reload the consensus, which also updates guards (and bridges) */ + time_t now = time(NULL); + router_reload_consensus_networkstatus(); + routerlist_retry_directory_downloads(now); } if (!smartlist_strings_eq(old_options->TrackHostExits, }}} -- Comment: It might not explain your issue, but it is still a bug. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20528#comment:3> 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