| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
tor-llcrypto: Stop deriving Deref in CtByteArray
Closes #2172
See merge request tpo/core/arti!3432
|
| | | |
|
| | |
| |
| |
| | |
Run maint/add_warning
|
| |/
|
|
|
|
|
| |
This seems to depend on cfgs. As I say in #1060, I don't think
precise cfg decoration of imports is sensible.
Also, it shouldn't be my job to fix whatever this is...
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit only adds a struct holding all the authentication data that
needs to be built during the verification process after all handshake
cells needed for authentication have been sent.
It lives in the VerifiedChannel struct so it can be used to build the
AUTHENTICATE cell and be sent before the NETINFO.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
| |
This feature has been removed from nightly, in favor of doc_cfg.
|
| | |
|
| | |
|
| |
|
|
| |
(This was so much easier than reporting on the send side.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The AUTHORIZE cell command is simply reserved but not defined. The tor
specification, at this point in time, is allowing such cell before the
handshake starts but it is very unclear on what ordering is allowed nor
how many can are allowed.
C-tor silents drop them like VPADDING and so clearly unused. Instead of
dealing with it, simply remove its support but keeping its reserved
number.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the ChannelFrame<> for the entirety of the outbound client handshake
that is the ClientInitiator channel type.
With this change, the codec.rs code is not needed anymore along its
CodecError as well which has been normalized onto the crate::Error
instead in order to simplify error handling and avoid duplication of
error types.
Unit tests have been modified to reflect this change of what can be done
with a channel frame. Also renamed to focus on client behavior.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add is_known_cmd() to the restricted_msg!() macro which can be used to
learn if a specific ChanCmd is part of the restricted set or not.
Then add a simple function to get the link protocol version from a
channel codec.
Part of #1597
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
| |
This caps the PoW effort during sorting, rather than at intake.
This allows us to record efforts that are capped in our metrics
histogram while only recording metrics after the PoW solve has actually
been verified.
|
| |
|
|
|
|
| |
This comment isn't correct if the encode() was given a non-empty buffer
(for example if two cells were written to the same buffer, the second
encode() would be given a non-empty buffer, so `pos != 5`).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |\
| |
| |
| |
| | |
Resolve a few issues that had been waiting for an MSRV update.
See merge request tpo/core/arti!3129
|
| | |
| |
| |
| |
| |
| | |
I had been planning to use `[]::is_sorted` here, once we had
MSRV >= 1.82, but it turns out that we wanted strictly ascending
sequence, whereas `is_sorted` checks for a non-descreasing sequence.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It now performs some validation and can return a `Result`.
We perform validation here since different cell formats may have
different maximum data lengths in the future, and `UnparsedRelayMsg`
doesn't expose the cell format so it's difficult to perform this
validation at a higher layer.
|
| |
|
|
|
| |
I don't see any further changes being needed for these types, and it
simplifies a lot of future code in tor-proto that uses these types.
|
| | |
|
| |
|
|
| |
See #2060.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Clippy nightly detects this problem, though earlier clippy verisons
haven't. The common element here is applying unwrap() to the result
from a write!().
|
| | |
|
| | |
|
| |
|
|
|
| |
We need the macro to propagate only certain #[meta] values
to all places where a case is used.
|
| |
|
|
| |
Part of #1945.
|
| |
|
|
|
|
| |
Implements proposal 358.
Closes #1946.
|
| |
|
|
| |
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.
|
| |
|
|
| |
Previously it required the caller to import a whole bunch of stuff.
|
| |
|
|
| |
It is no longer hs only.
|
| |
|
|
| |
We're going to use it for ntorv3 extensions as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 doesn't make much change yet, but does save us an allocation
when handling SENDMEs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a more efficient representation for the tag on an
authenticated SENDME message: it comes in at 21 bytes.
Previously, we used Vec<u8>, which has 24 bytes of overhead
(on a 64 bit system), plus malloc overhead, plus 20 bytes of
allocated tag.
We had a similar type to this as
`tor_proto::congestion::sendme::CircTag`,
but it could only accomodate 20-byte values.
I don't expect that we will have enough of these simultaneously that
the memory savings will matter, but the allocation savings could be
significant.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Instead of having a StreamIdReq that indicates
"None in V1, Any in V0", take an optional RelayCellFormat
as an argument.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since v1 cells have a longer tag, they can fit less data into a
single cell. Ah well, that's the cost of improved security.
The code in data.rs is a little wonky, in that it currently requires
its buffer to be exactly the maximum size for a data cell. We have
a TODO about fixing that in the future, but for now I've moved it to
use a boxed slice rather than a boxed array.
Part of #1944.
|
| | |
|
| |
|
|
| |
This is the main part of #1944, and will be needed for CGO.
|