Re: [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" <blackhole@xxxxxxxxxxxxxx>]

#24977: Non-fatal assertion !(tor_mem_is_zero((const
char*)node->hsdir_index->fetch, DIGEST256_LEN))
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  asn
     Type:  defect                               |         Status:
                                                 |  needs_review
 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 asn):

 * status:  assigned => needs_review


Comment:

 OK, I pushed a branch called `bug24977_dev` in my repo with a fix to this
 issue!

 Seems like the general issue is not just about hsv3 and it's a general
 logic bug, where Tor does not recompute consensus information after clock
 skew gets fixed. Basically, we call
 `networkstatus_set_current_consensus()` with a skewed clock, and we never
 call it when the clock gets fixed. The bug is mainly visible for v3
 because that's the main subsystem that uses the current time and consensus
 information, but effects of this bug could potentially ripple elsewhere
 too.

 You can reproduce the original bug by doing `date --set='4 days ago'`,
 launching tor, letting it get stuck bootstrapping and then setting the
 right date again. The patch above should fix the asserts.

 My fix above only does the bare minimum to fix the bug for HSv3; it does
 not attempt to recompute all possible consensus information that could
 dpeend on the current time, since that would require a much bigger
 refactor since `networkstatus_set_current_consensus()` is quite
 complicated. In the future we might want to call some more functions after
 detecting a clock skew, like `reschedule_dirvote()` and
 `update_consensus_networkstatus_fetch_time()`.

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