| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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]>
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
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 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |/ |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
(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
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|