| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
| |
| |
| |
| | |
This doesn't need to contain the `CloseStreamBehavior` or
`TerminateReason`, because we always use the same ones.
|
| | |
| |
| |
| |
| |
| |
| | |
I realized the previous naming was ambiguous. Hopefully this makes it
clear that this `StreamEvent` triggers when the MPSC channel connecting
the reactor to the local application stream (for example the local TCP
connection of the stream, in the case of exit streams) is dropped.
|
| | |
| |
| |
| | |
This already returns `()` in the `Ok` case.
|
| | |
| |
| |
| | |
Closes #2590
|
| | | |
|
| | |
| |
| |
| | |
This will soon be reused for implementing `CtrlMsg::ClosePendingStream`.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This will be sent by the FWD reactor.
Essentially, this going to be the final control message in the chain
`IncomingStream::reject()` ->
`RelayCirc::reject()` ->
`forward::CtrlCmd::ClosePendingStream`->
`HopMgr::close_pending()` ->
`stream::CtrlCmd::ClosePendingStream`
-> stream gets removed from the stream map, END sent
Part of #2590
|
| | | |
|
| | |
| |
| |
| | |
Closes #2590
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This replaces the `StreamMsg` `StreamReactor` sender with a new
`CtrlMsg` type. This `CtrlMsg` currently only has a `DeliverStreamMsg`
variant (which is the same as the old `StreamMsg` type), but will soon
grow another variant, for terminating a stream.
|
| | | |
|
| | |
| |
| |
| | |
This is just code motion
|
| | |
| |
| |
| |
| |
| | |
I am about to move this out of the `extend_and_forward()` test, because
I want to reuse it in the new `reject_stream()` test for checking that
the relay wrote an END cell to the stream.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This test currently fails, because `IncomingStream::reject()` calls
`RelayCirc::close_pending()` under the hood, which isn't implemented
yet.
Part of #2590
|
| |/ |
|
| |\
| |
| |
| |
| | |
Bump MSRV to 1.91
See merge request tpo/core/arti!4105
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit bumps the MSRV to 1.91 which was released on 2025-10-30.
The Cargo.toml files were updated as follows:
```sh
git ls-files | \
grep ".*Cargo\.toml$" | \
xargs sed -i '' 's/^rust-version = "1\.89"$/rust-version = "1\.91"/g'
```
The following files were updated manually:
```
modified: .gitlab-ci.yml
modified: README.md
modified: flake.nix
modified: maint/docker-android/Dockerfile
```
|
| | |
| |
| |
| | |
The tests don't compile otherwise.
|
| | | |
|
| | |
| |
| |
| |
| | |
For convenience. This will soon replace a corresponding re-export from
`tor_proto::client::stream`.
|
| | |
| |
| |
| | |
This will soon replace the re-export from `tor_proto::client::stream`.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These will replace the pub re-exports from `tor_proto::client::stream`.
This reorg is needed because currently, the only public export of the
incoming stream types is from `tor_proto::client::stream`, but these
aren't actually client specific: relays will use them too, for
implementing exit, DNS and directory streams. So it makes more sense to
export them from the top-level stream module instead.
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
tor-proto: Add unit test for `XonXoffReader`
See merge request tpo/core/arti!4093
|
| | |
| |
| |
| |
| | |
The 'futures' version bump is needed so that our test can use
`UnboundedSender::try_recv()` in the minimal-versions CI test.
|
| | |
| |
| |
| | |
This will allow us to add a unit test for `XonXoffReader`.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Always use destroy reason NONE in circuit handshake code
Closes #2466
See merge request tpo/core/arti!4088
|
| | |/ |
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Mark "counter-galois-onion" as stable
Closes #2550
See merge request tpo/core/arti!4069
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Lint for clippy::string_slice
See merge request tpo/core/arti!4086
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/ /
| |
| |
| | |
New beta semver policy means we should pin the patchlevel.
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <[email protected]>
|
| |\ \
| | |
| | |
| | |
| | | |
proto: Add a new channel -> circuit queue type
See merge request tpo/core/arti!4025
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is needed for relays as part of #2490.
Note that changing this type affects the client implementation too (i.e.
clients will start prioritizing inbound DESTROY, discarding any queued
data without forwarding it to their local streams). But that's okay,
because it will generally only affect misbehaving clients, and clients
unlucky enough to encounter a hibernating relay.
|
| | | |
| | |
| | |
| | |
| | | |
`CircuitRxSender` is no longer a `Sink`, so we don't need this import
anymore.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds new a `CircuitRxSender`/`CircuitRxReceiver` queue type.
The corresponding (`Sink`-link) sender and `Stream` implementations
prioritize the delivery of `DESTROY` messages, which get delivered
immediately, even if there are other messages queued in the underlying
MPSC message queue.
We are okay with the resulting data loss, because inbound DESTROY can be
indicative of malicious activity on the circuit. We choose to err on the
safe side, and free up the resources associated with such circuits as
soon as possible. DESTROY messages are also sent by relays when they're
about to hibernate, and by clients once they've decided to stop using a
circuit. In the latter case, the lack of an `RELAY_COMMAND_END_ACK`
does mean that this prioritization can cause data loss in cases where
the client closes the circuit immediately after END-ing a stream.
However, this is a deficiency in the protocol, and not something we want
to fix by implementing custom flushing logic in the reactor. See
torspec#196 and the discussion in #2490.
Part of #2490
|
| | |
| |
| |
| |
| | |
This passes now that we can build a `DataStream` without a
`ClientDataStreamCtrl`.
|
| | | |
|
| | |
| |
| |
| | |
Previously this would panic.
|
| |/
|
|
|
|
|
| |
We will reuse `DataStream` for relay exit streams, and those aren't
going to have a `ClientDataStreamCtrl`.
Part of #2557
|
| |
|
|
| |
Closes #2137.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Missed at review and no unit tests at the time catched those. The next
commit has a unit tests to make sure these checks are now valid.
Fixes #2501
Fixes #2502
Special thanks to Moumen Alaoui for reporting this early!
Signed-off-by: David Goulet <[email protected]>
|