torproject / tor Public
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hs-v3: Don't assert if we don't have the intro point descriptor #362
Conversation
When sending the INTRODUCE1 cell, we build the needed data for the cell and there might be issues with the rendezvous point node_t that makes us not able to do so. In that case, close the rendezvous circuit and return a transient error meaning that Tor can recover by selecting a new rendezvous point. If we are unable to build the INTRODUCE1 cell, we'll also close the rendezvous circuit betting on the fact that some data wasn't encodable. It is practically impossible in theory. Fixes #27774 Signed-off-by: David Goulet <dgoulet@torproject.org>
| * this is a permanent error. */ | ||
| tor_assert_nonfatal(TO_CIRCUIT(intro_circ)->marked_for_close); | ||
| goto perm_err; | ||
| if (TO_CIRCUIT(intro_circ)->marked_for_close) { |
Why not do this in hs_circ_send_introduce1() instead of clobbering this function with this info, and trying to infer what hs_circ_send_introduce1() has done?
Good question. The reason is that I wanted that to be a "client action" and not part of the "HS circuit" layer. The client there decides to note down the intro point client cache failure, not the circuit layer.
In other word, I wanted to not have hs_circuit to callback into hs_client.
src/feature/hs/hs_client.c
Outdated
| * get reused. */ | ||
| hs_cache_client_intro_state_note(service_identity_pk, | ||
| &intro_circ->hs_ident->intro_auth_pk, | ||
| INTRO_POINT_FAILURE_UNREACHABLE); |
Good catch. Fixup commit to make it GENERIC: b5d938b
src/feature/hs/hs_circuit.c
Outdated
|
|
||
| /* We should never select an invalid rendezvous point in theory but if we | ||
| * do, this function will fail to populate the introduce data. */ | ||
| if (BUG(setup_introduce1_data(ip, exit_node, subcredential, |
Hm, why are we wrapping this into a BUG()? If it's a BUG, why do we introduce whole new behavior just for a buggy possibility? Instead we should fix the bug.
Or is this an edge-case that can happen normally? In this case we should not call BUG.
|
This has been squashed and merged to master. |
When sending the INTRODUCE1 cell, we build the needed data for the cell and
there might be issues with the rendezvous point node_t that makes us not able
to do so. In that case, close the rendezvous circuit and return a transient
error meaning that Tor can recover by selecting a new rendezvous point.
If we are unable to build the INTRODUCE1 cell, we'll also close the rendezvous
circuit betting on the fact that some data wasn't encodable. It is practically
impossible in theory.
Fixes #27774
Signed-off-by: David Goulet dgoulet@torproject.org
The text was updated successfully, but these errors were encountered: