commit 8171d9f50f985de743a415ae5bf61b97e91ce8c8 Author: David Goulet dgoulet@torproject.org Date: Tue Nov 7 11:08:12 2017 -0500

Recalculate voting schedule first when getting a new consensus

Because the HS and SR subsystems can use the voting schedule early (with the changes in #23623 making the SR subsystem using the static voting schedule object), we need to recalculate the schedule very early when setting the new consensus.

Fixes #24161

Signed-off-by: David Goulet dgoulet@torproject.org --- src/or/networkstatus.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c index 93bb8643d..2660e6a32 100644 --- a/src/or/networkstatus.c +++ b/src/or/networkstatus.c @@ -1939,13 +1939,17 @@ networkstatus_set_current_consensus(const char *consensus, }

if (is_usable_flavor) { + /* The "current" consensus has just been set and it is a usable flavor so + * the first thing we need to do is recalculate the voting schedule static + * object so we can use the timings in there needed by some subsystems + * such as hidden service and shared random. */ + dirvote_recalculate_timing(options, now); + nodelist_set_consensus(c);

/* XXXXNM Microdescs: needs a non-ns variant. ???? NM*/ update_consensus_networkstatus_fetch_time(now);

- dirvote_recalculate_timing(options, now); - /* Update ewma and adjust policy if needed; first cache the old value */ old_ewma_enabled = cell_ewma_enabled(); /* Change the cell EWMA settings */