| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| | |
This is a direct translation of C Tor's `conflux_should_multiplex()`.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
The leg removal reason will be shared with the initiator of the conflux
handshake (i.e. the sender of the `CtrlMsg` initiating the handshake),
if the tunnel is a multi-path tunnel with conflux handshakes in
progress.
|
| | |
| |
| |
| |
| |
| |
| | |
The reactor will need to notify the conflux handshake initiator (the
sender of the `CtrlMsg` that triggered the handshake) of conflux set
readiness, so it needs to keep track of the status of the circuits it
was asked to link.
|
| | |
| |
| |
| |
| | |
These will be used for sending the conflux handshake outcome to the
reactor user.
|
| | |
| |
| |
| |
| | |
We will need this to implement conflux handshake timeouts,
and to get the current time for RTT calculations.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This will be soon needed in the `ConfluxSet` implementation too.
|
| | |
| |
| |
| |
| | |
This will be shared by all circuits in the set, and will be used during
the conflux handshake.
|
| | |
| |
| |
| | |
It doesn't actually need to be `pub(super)`.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.30.0
done
```
|
| |\ \
| | |
| | |
| | |
| | | |
maint: Update semver.md files from semver-checks
See merge request tpo/core/arti!2977
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
cargo run -p fixup-features -- --exclude examples/ --exclude maint/ Cargo.toml
The following features in arti-ureq were manually added to full or
marked non-additive:
* rustls
* native-tls
* tokio
* async-std
|
| | |
| |
| |
| |
| | |
(This is going to be a _requirement_,
since rand 0.9.1 has a behavioral change from 0.9.0)
|
| | |
| |
| |
| |
| | |
I updated everything except rand, because the new version of rand
interacts with #1903, thus requiring more care.
|
| | |
| |
| |
| | |
(The u8 code was written before RelayCellFormat::V1 was introduced.)
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
See discussion at torspec#328: it's important that our
SENDME authentication tag always be taken based on the
_encrypted_ cell.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This provides all the operations from proposal 359,
along with the necessary integration and unit tests to make sure
that they are behaving properly.
Closes #1943
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
These are a tweakable block cipher, and a pseudorandom byte stream.
This commit includes test vectors, which were generated from the
Python reference implementation and confirmed with a less optimized
Rust implementation.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
(We'll need these tags both to implement authenticated SENDMES
at the relay side, and also to make sure that cgo is generating them
correctly.)
|
| | |
| |
| |
| |
| |
| | |
CGO will need this argument so that it can authenticate
the command as part of its crypto operations.
(Trying to meddle with RELAY vs RELAY_EARLY will no longer work!)
|
| | |
| |
| |
| |
| |
| | |
It seems very likely that, as with client crypto,
we'll want relay crypto to separable into "forward" and "reverse"
objects, so that the two can be used more or less independently.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes the behavior of "originate" match the behavior of
OutboundClientLayer::originate_for, which creates the message
_and_ encrypts it. This will be necessary for CGO, where
"originate" and "encrypt" are not easily separated operations.
(Nothing uses this trait yet, since relay circuits aren't yet a thing,
so it's a good time to get it right.)
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Since we're about to have a second kind of relay cell crypto,
it makes sense to move this module.
This change is pure code movement.
|
| |/ |
|
| |
|
|
|
|
|
|
| |
This was missed in commits ccb65961 and eeda643f. While
`params.ccontrol.is_enabled()` should always be false because of those
earlier commits which ensure we don't enable congestion control, we were
missing the defense-in-depth conditions here that would alert us if we
accidentally did enable congestion control.
|
| |
|
|
|
| |
This means that even with the "flowctl-cc" feature enabled, we shouldn't
try to negotiate congestion control.
|
| |
|
|
|
|
|
| |
Congestion control is not completely working correctly, and is not fully
implemented (XON/XOFF). This commit adds a new experimental "flowctl-cc"
feature to enable the congestion control extension during the ntor-v3
handshake.
|
| | |
|
| | |
|
| |
|
|
|
| |
We use this method to decide whether to allow receiving stream SENDMEs,
and also whether we should send stream SENDMEs.
|
| |
|
|
|
|
|
| |
`OpenStreamEnt::put_for_incoming_sendme()` calls
`StreamSendFlowControl::put_for_incoming_sendme()`, which returns an
error if the `StreamSendFlowControl` is in XON/XOFF mode. So we don't
need this extra check.
|
| |
|
|
|
| |
Congestion control tells us whether we should use stream or XON/XOFF
flow control.
|
| |
|
|
|
|
|
|
| |
Previously new stream entries required a `StreamSendWindow`, but to
support other flow control algorithms, we want new stream entries to
take a `StreamSendFlowControl` instead.
This also deduplicates the `StreamSendWindow` creation code.
|
