| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fortunately, the type is crate-internal, so this is not a breaking
change.
The key insight with this change is that, from the _caller's_ POV,
the set of cells that are allowed to have StreamIDs has not changed.
The only difference is that the V1 relay cell code needs to
distinguish unrecognized commands from the SENDME case.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This will let us actually _send_ messages in the right format.
This approach is not ideal for packed/fragmented messages;
they will need a separate RelayCellEncoder.
part of #1944.
|
| |/ / /
| | |
| | |
| | | |
(Also note a couple of other CGO-related issues)
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
proto: Avoid panic on non-existent hop number
Closes #1950
See merge request tpo/core/arti!2938
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In `send_relay_cell()` in `tunnel/reactor/circuit.rs`,
replace an unconditional array access (which would cause a panic if
`hop_num` were out-of-range) with a checked `get_mut()` call.
It's not totally clear whether this can happen in practice,
but in either case, an error is probably better than a panic.
All of our other lookups in this vector are either checked,
or more obviously infallible.
Closes #1950.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
arti-client: Add ErrorDetail::OnionServiceSetup
See merge request tpo/core/arti!2923
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Forbid fork, except very carefully before exec
Closes #1897
See merge request tpo/core/arti!2925
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We're going to want to make many xrefs to this.
This trick with the <div> has worked well for us in derive-deftly.
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Relax bounds on BlockOn::reenter_block_on
Closes #1933
See merge request tpo/core/arti!2934
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This doesn't seem to happen with my local compiler. Anyway, suppress
it. I don't think we want to split up this function.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This gets rid of a clippy complaint about subthread_block_on_future
being too complicated.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The future no longer needs to be `Send + 'static`.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This test demonstrates that the intended use pattern compiles and
works.
It couldn't exist until now because we couldn't conveniently make a
`Send + 'static` future out of `rx.next()`.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously we put the future into the data structure, had the exeuctor
poll it there, and only woke up the subthread when the future was
ready.
Now, instead, we put a new TaskFutureInfo variant into the data
structure, and the executor context switches to the subthread every
time. Then we poll the future on the subthread.
Moving the future into the data structure meant we had to do use a
proxy future to store the return value. Now that's not needed any
more.
Now the future doesn't need to be Send + 'static.
Fixes #1933.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Eliminate the data_ variable and instead use a block scope.
This seems a bit nicer, and will align slightly better with
forthcoming changes.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
We're going to introduce a new call site for this.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Be clearer that `fut` is only `None` during the main loop.
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | | |
SubthreadFuture was a type in some early version of this branch, that
it's not in-tree now. subthread_spawn returns impl Future and the
concrete type is a channel receiver.
|
| |\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | |
| | | | | |
Remove hsc quiet and force flags in favor of batch
See merge request tpo/core/arti!2903
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
dev doc: Replace outdated references to `KeystoreSweeper` in state-management-cli.md
See merge request tpo/core/arti!2936
|
| | |\ \ \ \
| |/ / / /
|/| | | | |
|
| |\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | | |
Fix warnings with OSX and 1.86
See merge request tpo/core/arti!2933
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Clippy is complaining that these can be simplified,
so I took its recommendations.
|
| |/ / / /
| | | |
| | | |
| | | |
| | | | |
This comes up on OSX; I hadn't seen it before, so I assume it is new
with Rust 1.86.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
arti-ureq: New library which integrates with ureq
See merge request tpo/core/arti!2724
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Fixes #1519
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Update crossbeam-channel to 0.5.15 to fix TROVE-2025-013
See merge request tpo/core/arti!2931
|
| | |/ / / /
| | | | |
| | | | |
| | | | | |
0.5.14 is yanked. I am trying to find out why...
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
tor-cell: Minor tweaks for conflux
See merge request tpo/core/arti!2928
|
| | | | | |
| | | | |
| | | | |
| | | | | |
We will soon need to construct `V1Nonce`s.
|
| |/ / / /
| | | |
| | | |
| | | | |
`u32` is `Copy`, so the getter doesn't need to return a ref.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Initial metrics framework
See merge request tpo/core/arti!2918
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
beta clippy pointed out that it shouldn't be exhaustive.
but `#[strum_discriminants(non_exhaustive)]` is rejected.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185872
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185871
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185869
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2918#note_3185869
|