| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If we poll the ready streams on the join point more than once per
reactor loop, we risk sending more than one DATA cell (which is not
good, because cc might block after the first cell is sent).
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This removes our usage of `FuturesUnordered` in
`ConfluxSet::next_circ_action()` to address two issues:
* a fairness issue, where the futures driven by `FuturesUnordered`
could be starved under some circumstances (#2180)
* a logic error, where we'd explicitly avoid reading from the input
channel if the outgoing `chan_sender` channel was blocked (#2179)
Note that the fixing the latter will cause the reactor to buffer more
into the unbounded `chan_sender` sink, but that *should* be okay,
because no input message should be able cause us to queue cells
excessively.
Closes #2179, #2180
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We will soon need to access this directly (rather than via a method on
`Circuit`) to work around borrow checker limitations.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Part of #2180
Note: the code is intentionaly left misindented to make reviewing a
bit easier. A future commit will fix the indentation.
|
| | | | | |
|
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | |
| | | |
This simplifies the calling code, which will, in turn, make it easier
for us to simplify the logic in ConfluxSet::next_circ_action() and
abolish the questionable use of FuturesUnordered.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
proto: Remove half-streams when they expire.
Closes #264
See merge request tpo/core/arti!3267
|
| | | | |
| | | |
| | | |
| | | | |
I want to tackle this separately, as part of #2003
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3267#note_3261239
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3267#note_3259820
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Half-streams are periodically removed from each hop's stream map by the
reactor main loop, but we still need to ensure we reject any messages
arriving on expired half-streams in between these cleanup cycles.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This tests that the half-stream expiry works as expected.
Note: it doesn't! This test currently fails, because there's a bug in
the way half-streams are expired. Because we don't do it on a timer, and
instead garbage-collect the half-streams on each reactor iteration, if
the reactor is stuck long enough `.await`ing a message on one of its
channels (for example, the `input` one), there is a chance it will
accept a cell on a half-stream that should've been expired.
A future commit will fix this bug.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This should look at length of the circuit up until the hop where the
half-stream is (because the half-stream might be on an intermediate hop,
and not necessarily on the final one).
|
| | | | |
| | | |
| | | |
| | | | |
Closes #264
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This enables us to read the CBT estimates from the circuit reactor (we
need these to compute the half-stream timeouts for #264).
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This will enable us to pass the timeout estimator to the circuit reactor
in tor-proto.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The move of `self` into the closure was getting in the way, as I will
need to reference `self` again below.
|
| | | | |
| | | |
| | | |
| | | | |
We will need this to calculate the END ack timeout.
|
| | | | |
| | | |
| | | |
| | | | |
We need this to calculate the half-stream timeouts for #264.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
tor-llcrypto/tor-hscrypto: constant time PartialEq for tor-hscrypto types
Closes #2021
See merge request tpo/core/arti!3268
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I don't know why this was breaking rust-recent-async-std-rustls, but oh
well.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The macros to deftly derive `ConstantTimeEq` and `PartialEq` (for
`ConstantTimeEq`) are now only defined in `tor-llcrypto` and exported.
The macro to deftly derive `ConstantTimeEq` is now struct only and uses
`subtle::Choice::from(1)` for improved clarity.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I didn't even realize I was still conditionally using it on a feature.
That's what I get for always testing with all-features.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I forgot to make derive_deftly a required dependency. Oops.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is my initial attempt at deriving ConstantTimeEq and PartialEq.
This includes the previously missed HsSvcNtorKeypair and
HsClientDescEncKeypair types.
In tor-llcrypto, a few implementations still had to be done by hand, and
some types which previously derived normal PartialEq now derive it with
ConstantTimeEq.
I could not figure out how to properly set up the macros such that they
could be used both in the current crate and in others, so for the moment
they are duplicated. Just so I can get feedback. Ideally, this will be
replaced with a better solution before merge.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Implemented `subtle::ConstantTimeEq` for all of the following types:
- `pk::HsIdKey`
- `pk::HsIdKeypair`
- `pk::HsBlindIdKey`
- `pk::HsBlindIdKeypair`
- `pk::HsDescSigningKey`
- `pk::HsDescSigningKeypair`
- `pk::HsIntroPtSessionIdKey`
- `pk::HsIntroPtSessionIdKeypair`
- `pk::HsSvcNtorKey`
- `pk::HsSvcNtorSecretKey`
- `pk::hs_client_intro_auth::HsClientIntroAuthKey`
- `pk::hs_client_intro_auth::HsClientIntroAuthKeypair`
- `pk::HsClientDescEncKey`
- `pk::HsClientDescEncSecretKey`
- `pk::HsSvcDescEncKey`
- `pk::HsSvcDescEncSecretKey`
- `pk::HsSvcDescEncKeypair`
`PartialEq` has also been implemented for all listed types, using the
constant time comparison under the hood.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Exposed `as_bytes` on `curve25519::StaticSecret`, allowing a shared
reference to the secret bytes rather than needing to copy them.
Signed-off-by: hashcatHitman <[email protected]>
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
circmgr: Replace BoundedVecDeque with a much smaller wrapper
Closes #2174
See merge request tpo/core/arti!3281
|
| | |/ / / /
| | | | |
| | | | |
| | | | | |
Closes #2174. See that ticket for rationale.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Migrate to waker noop
See merge request tpo/core/arti!3250
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
tor-proto: Small improvements to XON/XOFF code
See merge request tpo/core/arti!3273
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This should be `cc_xoff_exit` if we're an exit.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
XON/XOFF flow control doesn't have the idea of taking "capacity". But it
does need to know the messages we're about to send so that it can count
the number of stream bytes that we've sent.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Streams at the same circuit hop will now share a single
`Arc<FlowCtrlParameters>`.
|