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:
                                                 |  merge_ready
 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 dgoulet):

 Replying to [comment:24 asn]:
 > Hm, I guess the HS-client example above is indeed a plausible (but
 unlikely) edge-case. It's worth noting that the example you cited above
 applies only to the HS client case, whereas I think we covered it for HS
 services since services basically function based on those callbacks. Of
 course, there might be other cases around the codebase, which we are not
 aware of right now ("if a tree falls in a forest and no one is around to
 hear it...").

 Yes my worry is mostly about other possible issues this affect. And making
 it a special case for the hs service callback to recalculate seems the
 wrong approach...

 > a) Fix all the cases by recomputing data immediately when a clock jump
 is noticed (as per my first branch). This has the negative effect of
 giving variable time duration to the callback as Nick pointed out.
 > b) Fix the HS client edge-case dgoulet pointed out, by calling
 `recalculate_consensus_data_callback()` when an HS client tries to connect
 to an HS.
 > c) Merge Nick's branch and leave the edge-cases open. In the future, we
 can fix those too as we understand more things about this problem.
 > d) Do more research, try to understand the problem more, and figure out
 an even better solution if possible...

 Not the easiest call here but I think (a) is what needs to be done even
 though I don't like much doing extra work in the update time
 callback.......

 The reason is that (b) is *one* possible issue among possibly other.
 Special cases where we directly call the callback makes me think we are
 piling up on the house of cards. The problem with (c) now is that this
 issue is something that took us quite a bit of time to finally find and I
 bet if something outside of the HS subsystem is affected by this, it will
 be hard as well to find out. And (d), I doubt it is needed, we have a good
 grasp on the problem imo.

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