| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
| |
We will soon need to construct `V1Nonce`s.
|
| |
|
|
| |
`u32` is `Copy`, so the getter doesn't need to return a ref.
|
| |\
| |
| |
| |
| | |
Wrap x25519-dalek and ed25519-dalek types.
See merge request tpo/core/arti!2868
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With this change, we'll no longer need to expose the types from
dalek-cryptography as part of our API, and we'll have more freedom
to switch ed25519 implementations, or to upgrade to a newer
`rand` ahead of their schedule.
Unlike with x25519-dalek, I had to tweak the API a bit: There's no
way to get a &PublicKey out of a Keypair now, and implementing the
old ed25519-dalek traits seemed unnecessary.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
We will soon need these in the circuit reactor.
|
| |/ |
|
| |
|
|
|
|
|
| |
This adds support for encoding and decoding `RELAY_CONFLUX_LINK`,
`RELAY_CONFLUX_LINKED`, and `RELAY_CONFLUX_SWITCH` cells.
Closes #1852
|
| |
|
|
| |
Part of #1852
|
| |\
| |
| |
| |
| | |
clippy: deny `mod_module_files`
See merge request tpo/core/arti!2689
|
| | |
| |
| |
| |
| |
| | |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |/ |
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the hs-pow, hs-pow-full, hs-pow-v1, pow-v1, and pow-full
features with a single hs-pow-full feature.
It's possible that in the future we will want to split different schemes
into different features, but we can do that when it comes up.
For now, having this as a single flag makes it clearer what's going on,
since the previous thing was not actually expressive enough to capture
some things we care about (like "at least one pow scheme is enabled"
that works in a future-compatible way).
This change is not semver breaking since it's a experimental feature.
Related: #1751
|
| | |
|
| |
|
|
| |
Co-authored-by: Micah Elizabeth Scott <[email protected]>
|
| |
|
|
|
|
| |
Feedback from the hs-pow code review, the internal seed heading member
should be seed_head instead of seed, for consistency. Very low impact
change since the field name is not public.
|