[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