[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24815 [Core Tor/Tor]: Validate shared random state dates before each voting period
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs