| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
proto: Replace circuit-scoped `CircSyncView` with per-hop alternative
Closes #2351
See merge request tpo/core/arti!3680
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The `CircHopSyncView` is now the view of a hop, not of the whole
circuit.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
And update the docs
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Now that CircSyncView no longer needs to know the total number of
streams, we can use it in the new per-hop stream reactor design.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`IncomingStreamRequestFilter`s, and `CircSyncView`s, by extension, are used
both by old relay implementation and the new one for implementing an
out-of-reactor way of deciding how to handle an incoming stream.
In the new circuit reactor design, we have a separate stream reactor for
each hop. Upon receiving an incoming stream, the stream reactor will
need to build one of these `CircSyncView` objects, and then pass it to
an externally-provided `IncomingStreamRequestFilter`. Before this
change, `CircSyncView::n_open_streams()` returned the total number of
open streams, which wouldn't have worked with the new reactor design,
because the per-hop stream reactor doesn't have a global view of all the
hops, so its `CircSyncView` can't return the total number of streams (at
least not without message passing, or sharing state with the other
stream reactors).
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Note: this commit only contains the removal of the old `CircSyncView`,
and it of course doens't compile. A future commit will replace the
removed file with the `syncview.rs` from the client module.
This change is split over two commits because it makes reviewing easier
(`git mv`ing the new file over the old results in a confusing diff,
because `git` refuses to show it as a move).
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is in preparation for replacing the top-level `CircSyncView` with
it.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This file will be moved to the top-level `circuit` module soon.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will soon replace `CircSyncView` wholesale. The preliminary
renaming will make the future diffs easier to review.
|
| | | |/ /
| |/| |
| | | |
| | | | |
This will soon be needed for building a `CircSyncView`.
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Bump MSRV to 1.89
See merge request tpo/core/arti!3684
|
| | | | |
| | | |
| | | |
| | | | |
As suggested by clippy
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I'm applying the clippy suggestion, even though in this case, using
`is_multiple_of()` instead of `%` is a bit questionable IMO, because the
`% 3` operation can never panic.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As agreed at our last team meeting.
See
https://gitlab.torproject.org/tpo/core/arti/#minimum-supported-rust-version
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
This enables us to un-ignore RUSTSEC-2026-0009.
See #2341 for analysis of impact.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
relay: Pass our TLS cert to the responder verify process
See merge request tpo/core/arti!3665
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
For the responder to build the authentication data, it needs its own
certificate of the TLS handshake that it is responding to (as a TLS
server).
This resolves an important TODO(relay) in the code.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | | |
tor-chanmgr: Add additional `get_or_launch()` tests and update doc comment
Closes #2344
See merge request tpo/core/arti!3676
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
When there are two channel requests with the same identities and
different socket addresses, we return the same channel.
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
tor-llcrypto: Add `Ed25519Identity::from_base64()`
See merge request tpo/core/arti!3667
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is intended to be analogous to `RsaIdentity::from_hex()`.
I've found myself wanting this a few times, and it makes it easy to grab
a `master-key-ed25519` from the consensus and paste it into the code
without needing to do extra conversions.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
RPC: Replace backend with nonblocking IO
See merge request tpo/core/arti!3644
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
(We don't need as many of these to be public as I had originally
thought.)
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
All the tests still pass!
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
There are two levels here. At the lower level, the caller is
responsible for providing their own select/poll wrapper. At the
higher level, we use mio to provide our own.
Before the end of this branch, this new module will replace llconn.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This will be necessary since, in order to make the RPC stuff
nonblocking, we'll need a better API than just `Box<dyn Read>` etc.
|
| |\ \ \ \ \ \
| |_|_|_|/ /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
proto: Pass *all* cells to handle_forward_cell()
Closes #2339
See merge request tpo/core/arti!3674
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This reverts commit 04ab3cd848d7977baf58dd64ebfcad6aa54ecb17.
Reverted because we no longer need to "peek" into the opaque
`CircChanMsg` of a circuit reactor: now the implementation-dependent
part of the reactor is in charge of handling the channel messages,
and extracting `Relay` objects out of RELAY/RELAY_EARLY cells,
which then get processed in the base reactor.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This doesn't need to be part of the `ForwardHandler` trait anymore,
because the base reactor no longer calls it directly (instead
implementations are supposed to handle it internally).
No functional changes here, just code motion.
|