#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs