mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.5.0 2026-06-29T13:52:57Z 2026-06-29T13:52:57Z Gabriela Moldovan gabi@torproject.org 2026-06-25T17:06:59Z urn:sha1:452009fdf4b997262a6e42d1df1b1235aabd7918 2026-06-29T13:52:57Z Gabriela Moldovan gabi@torproject.org 2026-06-25T16:31:19Z urn:sha1:1f66ce82758a58e7fb72d8354be03983c3cf3c03 2026-06-29T13:52:57Z Gabriela Moldovan gabi@torproject.org 2026-06-25T15:02:12Z urn:sha1:cbb40a00d0d13175e5dbf69529e684f2da618d7f 2026-06-29T13:52:56Z Gabriela Moldovan gabi@torproject.org 2026-06-12T11:06:31Z urn:sha1:6b1881af1785c61022a320c40399406e0682d37a This implements what we discussed in `doc/dev/notes/relay-streams.md` (lines 218-234): > Currently, to allow incoming stream requests on a circuit, > you first need to call `RelayCirc::allow_stream_requests()` > to install a `CmdChecker` and `IncomingStreamRequestFilter`. > This is not ideal, because `allow_stream_requests()` will need to be > called unconditionally, on each `RelayCirc`, > right after it's created in the `CreateHandler` impl > (which in turn, would mean making `handle_create()` async too, > because `allow_stream_requests()` is async, which wouldn't be great). > > So, the first step here is to rework the `RelayCirc` API to make relay circuits > be constructable with a list of allowed `RelayCmd`s and `IncomingStreamRequestFilter` > from the get-go ([#2582]), and to get rid of `allow_stream_requests()`, > which will enable the `CREATE*` handler to remain non-`async`. > > In any case, the `CREATE*` handler will still require some changes, > because it needs to be initialized with an `IncomingStreamRequestFilter`, I am not sure using an `IncomingStreamRequestFilter` "factory" is necessarily the right approach here, but the circuit `Reactor`'s constructor needs to take an `IncomingStreamRequestFilter`, and `IncomingStreamRequestFilter` is not `Clone` (and FWIW, I think it's better if we don't make it `Clone`). One obvious limitation is that the `IncomingStreamRequestFilter` of the circuit reactor is fixed for the entire lifetime of the circuit. In practice, I don't think this is going to be a problem, because the arti-relay `IncomingStreamRequestFilter` is only going be used for * preventing single-hop exit streams * per-circuit rate-limiting. Both of these checks will require the filter to have access to a recent `NetDir`, which is straightforward if the filter has an Arc<dyn NetDirProvider> (as mentioned in doc/dev/notes/relay-streams.md, `NetDirProvider` has a handy non-async `timely_netdir()` function we can use). And since these checks are based on consensus params, we don't really need to ever update an already-built circuit with a new `IncomingStreamRequestFilter` (because all `IncomingStreamRequestFilter` will have the ability to obtain a fresh `NetDir` as needed). Nevertheless, I left a TODO about this, because I expect this type to change once we figure out all the other pieces needed for #1448. 2026-06-29T13:50:49Z Gabriela Moldovan gabi@torproject.org 2026-06-24T09:44:46Z urn:sha1:5770784a8aece87dafe07585af237e2b496b421e 2026-06-29T13:50:49Z Gabriela Moldovan gabi@torproject.org 2026-06-15T15:37:26Z urn:sha1:07755fcbd11311e155375927825de8b26fbe7824 Part of #2582 2026-06-29T13:50:49Z Gabriela Moldovan gabi@torproject.org 2026-06-12T10:03:02Z urn:sha1:60306abe64f00e5053c2728e4c884a6e3ff714b4 Relay circuits always need a filter, so it's best to set it via the constructor. Part of #2582 Closes #2577 2026-06-25T18:36:07Z Steven Engler opara@torproject.org 2026-06-25T18:36:07Z urn:sha1:d72bcbca51bf5ff1286f9d7aa9c6326534432f8e 2026-06-25T02:46:15Z Steven Engler opara@torproject.org 2026-06-25T02:32:33Z urn:sha1:a38f27fd334cfea3cfa68f78802ee91eda825f23 2026-06-25T02:27:55Z Steven Engler opara@torproject.org 2026-06-25T02:27:55Z urn:sha1:1a8bc55df7d1441762bfcfd307df0997646262bf