[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

#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:
-------------------------------------------------+-------------------------
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 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...

 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.

 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24977#comment:15>
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