#24977: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN)) -------------------------------------------------+------------------------- Reporter: asn | Owner: asn Type: defect | Status: | needs_revision Priority: Medium | Milestone: Tor: | 0.3.4.x-final Component: Core Tor/Tor | Version: Tor: | 0.3.2.1-alpha Severity: Normal | Resolution: Keywords: tor-hs, prop224, | Actual Points: 034-triage-20180328, 034-removed-20180502 | Parent ID: | Points: 1 Reviewer: dgoulet | Sponsor: -------------------------------------------------+-------------------------
Comment (by asn): Replying to [comment:15 dgoulet]: > I think ideally we would like to do this if those two conditions are met: > > 1. Clock has jumped (at least the discrepancy from the code of 2+ sec) > 2. If we transition from "not live" to "live" > > Recomputing the voting timings and HSDir index only makes sense if we had a consensus before that we didn't think it was live and after the clock jump, it became live. > > I'm not sure how easily we can achieve (2) here. Probably something like two flags where one says "previous consensus was not live" and second says "the whole recalculation of a new live consensus needs to happen"... Becomes a bit non-trivial to correctly set those with our code flow... > Yeah the code flow is not very welcoming to this flag approach, because no particular event happens when we move from non-live to live, and we would probably have to check every second for the transition; otherwise if we miss the transition even for a second this bug can occur again I think. I wonder how to do this cleanly... > The other option is to possibly keep the `valid_after` time of the consensus that was used for the HSDir index computation. If that time is 0 (unset) or smaller than the one we have in our *live* consensus and we detect the clock jump, we should readjust. > Hmm, I kinda get the idea here, but it seems a bit dirty to rely on whether HSDir index is set, to also readjust voting schedule etc. I wonder what else we could rely on here... > The whole point of the above I think is to avoid only recomputing with the >= 100 seconds clock jump since edge cases appear if for instance we correct for only 10 seconds. Hmm, I get the theoretical issue here, but it seems ultra unlikely we will miss the transition for 10 seconds skew, given the way consensus documents are propagated on the network. Because this can only happen if Alice fetches a consensus with `valid-after 12:00` at 12:00:05, but her system time is skewed at 11:59:56. It's very unlikely that Alice will fetch the consensus so early in its lifetime and also have so tiny skewed clock, but I guess the theoretical issue is there. Need to think of how to do this cleanly and without too much overhead. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24977#comment:16> 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