GitLab

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,