| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
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]>
|
| |\
| |
| |
| |
| | |
proto: Fix typo in ResolveCmdChecker docs
See merge request tpo/core/arti!4035
|
| | |
| |
| |
| | |
This returns a boxed `ResolveCmdChecker`, not a `DataCmdChecker`.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Done using:
```
for crate in $(./maint/list-crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.43.0
done
```
|
| |\ \
| | |
| | |
| | |
| | | |
proto: Replace outdated references to RawCellStream
See merge request tpo/core/arti!4036
|
| | |/
| |
| |
| |
| | |
`RawCellStream` was removed long ago, in
c559754116678866eabe525f5b189b50cc78b5cc.
|
| |/
|
|
|
|
| |
`/channel/handler.rs`
Closes #1690.
|
| |\
| |
| |
| |
| | |
proto: Add tests for DESTROY and TRUNCATE handling
See merge request tpo/core/arti!4008
|
| | |
| |
| |
| |
| |
| | |
We decided the reactor is the wrong place to handle this.
See discussion in #2490
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds an extra assertion that ensures the relay reactor does in fact
send an EXTENDED2 on its towards-the-client channel after receiving the
CREATED2 response from the fake hop.
This check is nice to have in general, but the main reason I'm doing
this now is because for the DESTROY tests I'm about to add, I need the
inbound MPSC queue (towards the client) drained of these handshake
messages in order to check that the "next" cell we've sent is a destroy.
I could've added some custom code to drain it just for the purposes of
that test, but I think it's better to have `do_create2_handshake()` take
care of it.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The new name is (hopefully) a bit more descriptive.
I'm planning on extending this function soon to support checking if a
DESTROY has been sent on the outbound channel too, so I'm tweaking the
docs a bit in preparation for that.
|
| | |
| |
| |
| | |
I'll soon need this for a DESTROY test.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This changes a debug log to have the same format as the corresponding
DESTROY-related log from the forward reactor.
Part of #2490
|
| | | |
|
| | |
| |
| |
| | |
Part of #2490
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Set socket buffer sizes (`SO_SNDBUF` and `SO_RCVBUF`) for proxy sockets
Closes #2500
See merge request tpo/core/arti!3957
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This better matches nearby code.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously when initializing a stream, we constructed most of the
stream-related queues outside of the reactor and passed the relevant
halves of the queues (senders or receivers) into the reactor.
A downside of the above approach is that the reactor may be better
informed about what queues to construct, and how to construct them. For
example the reactor knows what type of flow control that the hop is
using, so it knows whether we need queues for passing rate limits and
drain rates for XON/XOFF flow control.
This commit moves the construction of these queues into the reactor and
passes the relevant halves out of the reactor. In the future we can make
better decisions about which queues are needed depending on the flow
control method used instead of always constructing them (see arti#2068).
Reviewing with `--color-moved` might be helpful as a few lines have been
moved.
|