[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 at torproject.org
Wed Jan 31 15:55:02 UTC 2018


#24977: Non-fatal assertion !(tor_mem_is_zero((const
char*)node->hsdir_index->fetch, DIGEST256_LEN))
----------------------------+------------------------------------
 Reporter:  asn             |          Owner:  dgoulet
     Type:  defect          |         Status:  accepted
 Priority:  Medium          |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor    |        Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal          |     Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:                  |         Points:  1
 Reviewer:                  |        Sponsor:
----------------------------+------------------------------------

Comment (by dgoulet):

 Hmmm I have not seen that on any of my v3 services for a _while_ now.

 What I can see that makes me wonder. We can have `node_t` without an
 ed25519 known ID that is before we get the descriptor.

 Notice `node_set_hsdir_index()`, it doesn't set anything if the
 `node_get_ed25519_id()` returns NULL. We only set HSDir index if
 `rs->supports_v3_hsdir` meaning when we have a `rs`. But the
 `hs_get_responsible_hsdirs()` looks up the node by `identity_digest` ...

 And `node_supports_v3_hsdir()` can return true with only using the `ri`
 and not the `rs` ... so we have this difference here where we only set the
 indexes if we have a `rs` but then we can also validate HSDir support by
 `ri`.

 Although, in this situation, we loop over the `rs` list so any `node_t` we
 look at from the `rs->identity_digest` should return a node that has a
 valid `rs`....

 Very puzzling!

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


More information about the tor-bugs mailing list