mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=main 2026-08-18T16:13:57Z 2026-08-18T16:13:57Z Gabriela Moldovan gabi@torproject.org 2026-08-11T15:51:46Z urn:sha1:43d07736928811fb36fa5e272f1f77b3653ebb28 This change prevents the channel reactor from sending DESTROY cells on already-closed (or non-existent) circuits. Upon receiving a DESTROY cell, the channel reactor removes the corresponding circuit entry, if any, from its circmap. It then passes the DESTROY to the circuit reactor for handling. The circuit reactor handles it by shutting down, and calling `Channel::close_circuit()` on drop. Previously, this would unconditionally send a DESTROY cell, which caused #2648 and #2646. This affects both clients and relays, because both circuit reactors call `Channel::close_circuit()` on drop. Closes #2648, #2646 2026-08-11T09:41:11Z Gabriela Moldovan gabi@torproject.org 2026-08-10T18:18:47Z urn:sha1:2f78e004ce8a83eda5cc6f145a00b3240051d69e If we're a relay, we need to tolerate CREATED* with unrecognized CircIds: for example, if we time out[^1] while trying to extend the circuit by another hop, we will send a DESTROY to the extending hop, which can race with the CREATED* response. In other words, a CREATED* cell arriving on a closed circuit shouldn't be treated as a protocol violation. There are, however, a few cases where a CREATED* with an unknown CircId *is* a protocol violation (and probably *should* cause us to close down the channel): * if the CREATED* is moving in the forward direction (towards the exit), or * if we have not previously sent a CREATE* with that particular CircId As before, distinguishing these from the "closed circuit" case above would involve some tricky logic, and the benefits are unclear, while the downsides of closing a channel when we shouldn't have are significant. It seems better to just drop these cells for now. Closes #2655 [^1]: at the time of writing, we don't have timeouts for the circuit extension logic, so what I've described here cannot actually happen today. However, we *do* have a TODO for it, so the time outs I've described here will be implemented at some point 2026-08-04T12:47:49Z Gabriela Moldovan gabi@torproject.org 2026-08-03T17:13:29Z urn:sha1:f3ba0f52a187b5307cb937c2ad3466d99501a0a0 We now have `add_relay_ent()` for this, so we can remove the TODO. 2026-08-04T12:47:49Z Gabriela Moldovan gabi@torproject.org 2026-08-03T16:16:08Z urn:sha1:51aa7b5eb8dfe8317c364ff37a67f8e87ed88726 I think this might have been c&p from the half-stream code ("hs" = "half-stream"). "hc" ("half-circuit") seems like a better name. 2026-07-28T09:33:30Z ramdoys ramdoys+tor@protonmail.com 2026-07-28T09:33:30Z urn:sha1:4a54ad33c0aaadba7705288fae8280a6b84fc765 2026-06-09T15:36:01Z Clara Engler cve@cve.cx 2026-06-09T15:36:01Z urn:sha1:9f5752a77fb57052c06ead0eeae606831f1e8e97 This commit executes maint/add_warning with the just added change to deny string slices except in tests. I recommend auditing this by checking out the previous commit followed by running the script yourself and then verifying that the diff is identical to this commit. This commit makes cargo clippy fail. We will add exceptions in the next commit. 2026-06-08T14:07:16Z Gabriela Moldovan gabi@torproject.org 2026-05-13T17:47:20Z urn:sha1:d68fede4bcd2d28d4bb6add00193e6170dea97da 2026-04-08T15:29:26Z Steven Engler opara@torproject.org 2026-04-07T15:46:13Z urn:sha1:5fd0ac9461c63e31c168150738c2c5beb3b034d5 2026-04-08T15:29:26Z Steven Engler opara@torproject.org 2026-04-06T15:42:47Z urn:sha1:6ab8b3ce2226ae4ce4e37df2807aa85522d5e316 2026-04-08T15:29:25Z Steven Engler opara@torproject.org 2026-03-31T06:07:07Z urn:sha1:c62397a75a00f9bd7bddb7eb20a83c8d4899e0db