[tor-bugs] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))

[Tor Bug Tracker & Wiki]

#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