| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Additionally, fix itertools usage in maybenot_padding.rs
The definition of `Position` changed in 0.15.0.
|
| |
|
|
|
|
|
|
|
|
|
| |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| |
|
|
|
|
|
| |
Previously we'd get the time by calling Instant::now, but that would
lead to a mismatch with the runtime if we were mocking.
Part of #2428.
|
| | |
|
| |
|
|
| |
I am about to use this in other places too.
|
| |
|
|
|
|
|
|
|
| |
Fixes part of #2193.
(Edits from nickm: I selected the cases here that I could verify
were correct from immediate context.)
Edited-by: Nick Mathewson <[email protected]>
|
| |
|
|
|
| |
Some of these are relay-specific, so it makes more sense to pull this
into a top-level module.
|
| | |
|
| |
|
|
| |
With this commit we now actually generate padding when we're told to.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When we install a new padder, we should check whether we have become
unblocked, and we should wake up the PaddingEventStream in case
the new padder has something to say.
This has required us to move a couple of fields around, but not in a
very complicated way.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We still have dead code when circ-padding but not
circ-padding-manual is provided.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For now, we're not going to implement hop negotiation: we're still
waiting to find a set of padding machines that will be useful for
Arti. This API will help facilitate experimentation to find such
padding machines.
These APIs are under a separate feature (`circ-padding-manual`)
to avoid confusing them with the rest of the padding code:
we only want them to be exported when the researcher wants to
manually install circuit padding.
|
| | |
|
| |\
| |
| |
| |
| | |
Validate incoming padding, and permit it when it is valid.
See merge request tpo/core/arti!3241
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
FMUL is usually faster than FDIV, so let's give that a try, in case
the compiler doesn't figure it out on its own.
Also, add a comment discussing an approach that might be better,
if we run into a bottleneck here.
|
| | |
| |
| |
| | |
The algorithm is simplistic, but may be useful
|
| | |
| |
| |
| | |
This will help avoid needing to acquire the lock more than once.
|
| | |
| |
| |
| | |
This will let us reject excessive padding.
|
| |\ \
| | |
| | |
| | |
| | | |
Circuit padding: fix a couple of issues with the "replace" flag.
See merge request tpo/core/arti!3246
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously we would replace padding with any cell that was already
in the queue. But that doesn't make sense: If we have a cell queued
for hop 1, then we shouldn't use it as padding for hop 2, since hop
2 will never see it! Instead, we look at the target hops for the
already queued cells.
Ref:
- https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3225/diffs?commit_id=3998e0559fbcc06f8ea88968051cebca71489a52
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we replace padding with an _already queued_ cell,
we should only trigger PaddingSent on the final hop's machine.
Refs:
- https://github.com/maybenot-io/maybenot/commit/35ba39d629d1e64a1346586112837e5015c47242#r164166126
- https://github.com/maybenot-io/maybenot/pull/35/commits/715455b8dcd95a32eafe261ab500cfed9415b7f3
- https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3225/diffs?commit_id=79a3305dc226f9f1136cad034e1a36413d6595f5
|
| |/
|
|
|
|
|
|
| |
The correction: We want to report a block as bypassable only if
_every_ currently blocking hop has bypassable blocking.
The simplification: We don't need to report the first hop that's
blocking any more.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
It cleans up and changes a few things. Changelog at
https://github.com/maybenot-io/maybenot/blob/main/crates/maybenot/CHANGELOG.md
|
| | |
|
| |
|
|
|
| |
This requires some annoying plumbing to make sure that the right
types wind up in the right places.
|
| |
|
|
| |
Also, use it to report that we have queued normal data.
|
| |
|
|
|
|
|
|
| |
We'll need this so that we can tell the right padding machine(s)
which of them just had a queue flush.
This is not yet 100% done; the unfinished parts are marked with
XXXXs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
There are incomplete pieces, marked with "TODO circpad".
There is no integration into the circuit reactor code yet.
Part of #63
|
| |
|
|
|
|
|
|
|
|
|
| |
With rustc 1.85, this `expect(unused)` triggers a "lint expectation
unfulfilled" error, because rust thinks the struct *is* used (because of
the d-d `TryFrom` implementation), despite the fact that it's never
actually constructed. This isn't a problem on newer versions (it's
correctly identified as unused/dead code on 1.89, for example).
Using `allow` instead of `expect` is slightly less nice, but it makes
`clippy` pass on 1.85 too.
|
| |
|
|
|
|
|
| |
This is just code motion (I suggest reviewing with `--color-moved`).
This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
|
| | |
|
| |
|
|
|
| |
This will be used to restrict the types of messages that can be sent on
the relay-specific channels.
|
| |
|
|
|
| |
This enables us to remove the open-coded implementations in favor of the
derived version.
|
| |
|
|
|
|
| |
The code for generating these is repetitive (see `CreateResponse` and
`ClientChanMsg`), and we will soon need a `RelayChanMsg` type too, so
now is a good time to introduce a helper for generating the boilerplate.
|
|
|
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
|
