[tor-bugs] #24815 [Core Tor/Tor]: Validate shared random state dates before each voting period

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Jan 8 17:14:04 UTC 2018


#24815: Validate shared random state dates before each voting period
------------------------------+------------------------------------
 Reporter:  teor              |          Owner:  (none)
     Type:  defect            |         Status:  needs_information
 Priority:  Medium            |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor      |        Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal            |     Resolution:
 Keywords:  tor-sr, tor-ddos  |  Actual Points:
Parent ID:                    |         Points:  1
 Reviewer:                    |        Sponsor:
------------------------------+------------------------------------
Changes (by dgoulet):

 * status:  new => needs_information


Comment:

 I suppose you are talking about the log on Jan 7th but the upcoming round
 on Jan 6th:

 {{{
 Jan 07 09:48:14.984 [info] sr_state_update: SR: State prepared for
 upcoming voting period (2018-01-06 23:00:00). Upcoming phase is reveal
 (counters: 0 commit & 1 reveal rounds).
 }}}

 That time (`2018-01-06 23:00:00`) is the `valid_after` from the consensus
 and the SR subsystem only uses the time from the consensus to take every
 timing decision. It updates the state when loading from disk (at bootup)
 or when a new consensus has just been computed.

 In this case, it is when booting up (`sr_init()`) I presume? So it takes
 the consensus from disk (very old), and tries to vote with that
 information. Ultimately it will fail but then once your dirauth gets the
 latest consensus, it should sync up again with the whole dance at the next
 voting round.

 Do you see that or I'm misunderstanding the issue or ?

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


More information about the tor-bugs mailing list