| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
We only need Eq and PartialEq but given those we should have Hash too.
(We're going to want to be able to compare parameters for equality.)
|
| |
|
|
|
|
|
| |
We never actually constructed these before, but now we enforce it at
the API level.
Part of #1269.
|
| |
|
|
|
|
|
|
|
|
|
| |
If we don't reject these, they are a way to inject an undetected
traffic signal. (This is LOW severity, since we only accept DATA
when a stream is open, since DATA messages are rate-limited,
and since using length==1 is nearly as effective.)
Closes #1269.
This is TROVE-2024-001.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since Rust 1.66, std's default works properly for enums, provided that
the default variant is a unit.
Review all uses of `#[educe(default)]` on enums and replace them with
std where possible, which is most of them.
In 1.66 and later, std's `#[derive(Default)]` doesn't infer any
generic bounds on the derived impl, where it's an enum - since the
unit variant can always be constructed. So this change doesn't add
any generic bounds and is not API-visible.
|
| | |
|
| |
|
|
|
|
|
| |
When using the `arti-client` crate in other contexes, the Rust compiler
sometimes has difficulties with determining the current type in this
particular case, due to a collision with the popular serde json crate,
which also provides an implementation for converting u8.
|
| | |
|
| |
|
|
|
| |
We should remove these once we do our final renaming here,
but for now we may as well avoid a breaking change.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is pure renaming, done automatically with rust-analyzer.
Comment fixes and other cleanups will be in the subsequent commits.
We're doing this renaming because we need a name for
the combination of a `RelayMsg` and an `Option<StreamId>`
that we use when we have a `RelayMsg`
we intend to route to a given stream or circuit internally.
Previously we called this a `RelayCell`,
but that name was already somewhat inaccurate,
and will become _very_ inaccurate with the arrival of prop340,
which breaksthe 1:1 relationship between relay cells
and relay messages.
(If we didn't do this renaming now, we'd soon be making
the relationship between `UnparsedRelayCell`and `RelayCell`
many-to-many, which would be ridiculous and confusing.)
The `RelayMsgOuter` name is a placeholder:
We expect that we'll want to rename this type,
and may also want to rename `RelayMsg`,
and unify our vocabulary in other areas too.
But such a renaming will have to wait
for a larger discussion affecting the specifications,
so that we can use the same vocabulary everywhere.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
An encoded set of extensions in the ntorv3 handshake includes a header
with the number of extensions. This change adds that header.
It also changes `write_many_onto` to take a slice instead of an
iterator, since we need to know the number of extensions up-front. In
principle we could take a clonable iterator instead and use
Iterator::count, but it's probably not worth the extra complexity.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main changes that we have to adjust for are as follows:
* In x25519-dalek:
* `StaticSecret` is now behind a feature.
* `StaticSecret::new` is deprecated in favor of
`StaticSecret::random_from_rng`.
* StaticSecret no longer does its own clamping.
* In ed25519-dalek:
* `SecretKey` has (in effect) been renamed to `SigningKey`. The name
`SecretKey` is now an alias for `[u8; 32]`.
* `SigningKey` is effectively a keypair, since it contains a
public key as well.
* `PublicKey` has been renamed to `VerifyingKey`.
* The functions to extract a signing key and verifying key have
been renamed as you might expect.
* `ExpandedSecretKey` has been moved to `hasmat` and no longer
implements `sign`.
* `ExpanededSecretKey` now has as its elements a scalar and a hash
prefix.
* Various functions that took `&[u8]` now take `&[u8; N]`.
* We no longer need a wrapper for older versions of rand.
There is a single test in tor-keymgr that does not pass. I've
marked it as ignore for now, in hopes that @gabi-250 can help me
figure it out.
This closes #808. There are several changes I want to make before
we merge, however. They are marked with TODO DALEK.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It does not help that C tor has a set of parameters and a set of
configuration options with exactly the same names which configure
the same thing in two slightly different ways.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This changes the internal representation to be `NonZeroU32` instead of
just `u32`.
Various places where a circuit ID is optional now use `Option<CircId>`.
Fixes a bug in `CircIdRange::sample` that would previously return a
circuit ID of 0, when the rng returned 0x8000_0000 for a low range.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Write more of IptEstablisher.
See merge request tpo/core/arti!1510
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
doc: fix malformatted comment in SliceWriterError
See merge request tpo/core/arti!1503
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
| |
This allows us to allow passing in opaque HsMacKey objects,
rather than untyped byte slices.
Additionally, we now check both MAC and signature unconditionally,
to avoid the large timing side-channel. The small timing
side-channel of combining booleans with `&` is considered safe.
Part of #993.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #950.
|
| | |
|
| | |
|
| |
|
|
|
| |
rustdoc insisted on misindenting this before, and now it insists on
un-mis-indenting it.
|
| |
|
|
|
| |
Remove this todo as per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1246#note_2912104
|
| |
|
|
| |
IntroduceAckStatus
|
| | |
|
| |\
| |
| |
| |
| | |
Resolve most TODO HS comments in tor-cell
See merge request tpo/core/arti!1245
|
| | | |
|
| | |
| |
| |
| |
| | |
This module didn't have anything in it; nonetheless, removing it
does count as an API break since it was public.
|
| | |
| |
| |
| |
| | |
Yes, we still will need more accessors for onion services, but we
can add them as we find the need.
|
| | | |
|
| |/
|
|
|
|
| |
The type is a bit odd but this is a result of the underlying protocol.
I don't feel like inventing `IntroduceAckSuccess` that contains only
the extensions.
|
| |
|
|
| |
Closes #887.
|
| | |
|