| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |\| | |
| | | |
| | | |
| | | |
| | | | |
Update keccak to 1.6
See merge request tpo/core/arti!3682
|
| | |/ /
| | |
| | |
| | | |
keccak 1.5 was yanked and is causing our `cargo-audit` builds to fail.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
docs: Move deleting semver.md files before unfreezing tree.
See merge request tpo/core/arti!3635
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We frequently have merge conflicts when deleting the semver.md files.
While this isn't the end of the world, it's annoying, so I think it's
worth making a habit of deleting the semver.md files before unfreezing
the tree. This also avoids any problems with inadvertently removing
entries that were added after the release was cut.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
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-basic-utils: Add utility to iterate over error sources
See merge request tpo/core/arti!3653
|
| | | | | | | |
|
| |/ / / / / |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Closes #2339
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Needed because some messages are handled differently depending on the
cell type they originated from (RELAY vs RELAY_EARLY).
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This pushes the RELAY/REALY_EARLY handling inside
`handle_forward_cell()`, which now decodes the relay cells and
* handles them internally, if they are unrecognized
(`handle_unrecognized_cell()`), or
* returns them back to the base reactor if they are recognized
(RELAY and RELAY_EARLY cells are handled the same way by the
base reactor)
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Soon this function will be in charge of decoding the cell too, so it
will need a handle to the `HopMgr` (see `decode_relay_cell()`)
|
| | | |_|/ / /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously, the implementation-dependent `handle_forward_cell()` handled
all forward cells *except* for RELAY cells, which were handled in the
generic base reactor.
This changes the implementation to pass *all* cells, including RELAY
cells, to `handle_forward_cell()` too. This is needed because both
RELAY and RELAY_EARLY cells need to be handled very similarly: both
can be either recognized or unrecognized, with unrecognized cells
being handled by the implementation-dependent code, and the recognized
ones being sent to the base reactor for handling.
A future commit will update `handle_forward_cell()` to extract `Relay`
object out of RELAY/RELAY_EARLY cells, and return it back to the base
reactor for handling.
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
Implement channel canonicity
See merge request tpo/core/arti!3668
|