[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:
                                                 |  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):

 Hmmmm this new branch adds a call to the recalculate consensus data
 function to the `hs_service` callback... it makes me think that we might
 have the wrong approach. Here is why with the hs service callback example:

 So in the case of not having a live consensus because of a skewed clock,
 having the recalculation in a mainloop event means that the `hs_service`
 callback can be called _before_ it. Which seems to be the reason why this
 was added to the hs service callback:

 {{{
 +  if (need_to_recalculate_consensus_data)
 +    recalculate_consensus_data_callback(NULL, NULL);
 }}}

 Because we recalculate the data in an event loop now, it means other
 events can trigger the assert() on the hsdir indexes because they would
 see the consensus being live but the recalculate consensus callback was
 not yet triggered. For instance, a client request to a .onion will trigger
 the assert() if done before the recalculation happened because it would
 consider the consensus live.

 In other words, there is a time gap between "clock jump, now I have a live
 consensus" and "recalculate conensus data", we'll end up in some desynch
 state imo. HS is just one big example, there might be more.

 The earlier patch from asn did recalculate everything on the spot when a
 clock jump was noticed.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24977#comment:23>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online