| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| |
|
|
| |
Hiding the underlying type makes the code less readable.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is messy, because `ClientCirc::{path_ref, n_hops, ..}` become
fallible (we can't unwrap the result, because when a circuit is closed,
its state gets removed from the `TunnelSharedState`, but its
`ClientCirc` handle continues to exist, so any attempt to retrieve the
state will result in an `Err`).
|
| |
|
|
|
|
|
|
|
|
| |
We now have a new `TunnelSharedState` type for storing the shared state
of a tunnel. It consists of the `MutableState`s of all the circuits in
the tunnel, which are shared between it and `Circuit` (the circuit
subcomponent of the reactor). The `TunnelSharedState` itself is shared
between `ConfluxSet` (which manages the `Circuits`), and `ClientCirc`
(the reactor handle used to access information about circuits, such as
their `Path`).
|
| |
|
|
| |
This will simplify some callsites.
|
| |
|
|
|
| |
Not locking the `MutableState` mutex outside of this impl makes it
easier to see it's currently impossible deadlock.
|
| |
|
|
|
|
| |
This renaming is in preparation for the addition of a newtype wrapper
for what used to be `Mutex<MutableState>`. That newtype wrapper will be
called `MutableState`.
|
| | |
|
| |
|
|
|
|
| |
These functions have been deprecated for a while, and are now
complicating the `MutableState` changes we need to do for #1840, so it
seems like a good time to remove them.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
See torspec#332.
|
| |
|
|
| |
Implements part of proposal 358.
|
| |
|
|
| |
This required some renaming, so that the types and their codes matched.
|
| |
|
|
|
|
|
| |
This type will, because of prop358, be shared by ntorv3,
hs-ntor, and probably other future handshakes.
There will also be a CircResponseExt type.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now instead of using CryptState for everything, we have specific
types for each role and direction of crypto.
This turned up a harmless-so-far bug in our onion service code: as
an onion service, we were using _client_ crypto layers to respond to
a client request. That's not correct, and wouldn't have worked
with CGO. Instead, we need to use relay crypto layers, wrapped
as client layers.
Closes #1975.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of the trait was to parameterize the tor1 cell crypto
on the different possible relay cell layouts.
It made sense to have this trait when we thought we would implement
the new cell layout for prop340 (packed-and-fragmented) well before
we implemented CGO.
But it now appears all but certain that CGO will land long before
we make any more headway on prop340. Therefore,
it doesn't make sense to carry the ability to customize `tor1`
for other relay cell layouts.
Removing this trait saves a fair bit of complexity.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the code to copy a SendmeTag rather than returning a
slice. This isn't actually a big change: sending a slice already
required 16 bytes (on 64-bit platforms), so sending a SendmeTag
around isn't a big deal.
We rely extensively on the compiler's ability to optimize away
all the checking in code like this:
```
let slice: &[u8];
let a: [u8;N] = slice[0..N].try_into().expect("Nope");
```
I've spot-checked it somewhat with "cargo-show-asm", but
it could use more thorough checking.
Closes #1956.
|
| | |
|
| |
|
|
|
| |
This doesn't make much change yet, but does save us an allocation
when handling SENDMEs.
|
| |
|
|
|
|
| |
This lets us use `Aes128Dec` and `Aes128Enc` in place of plain old
`Aes128`, which can be less space-efficient depending on the
back-end.
|
| |\
| |
| |
| |
| |
| |
| | |
tor-proto: New extend() and create_firsthop() to pick between ntor and ntor3
Closes #1970
See merge request tpo/core/arti!2967
|
| | |
| |
| |
| |
| |
| | |
Since we have create_firsthop() and extend(),
we should recommend them in our documentation,
instead of recommending the no-longer-best methods.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
In the future, when we add more circuit handshakes (PQ anyone?)
we'll want to have the logic for choosing which to use be unified.
Almost nobody calling tor-proto should need to care which circuit
handshake is going to be used.
Closes #1970.
|
| | |
| |
| |
| | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2946#note_3192334
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
We don't use it outside this branch, so might as well move it there.
|
| | |
| |
| |
| | |
We already do this, using `note_conflux_handshake_result`.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Prompted by opara's suggestion in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2946#note_3192319
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|