| 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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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 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.
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We never want to create one of these from its parts except when we
are testing it; we only want to forward an Introduce1 message with a
new command on it.
|
| |
|
|
|
| |
We'll need to store this so that it can later on be used to complete
the hs_ntor handshake.
|
| |
|
|
|
|
|
|
| |
We'll want this because our hs_ntor handshake requires access to an
encoded version of the header independent from the actual encrypted
message.
part of #866.
|
| |
|
|
|
|
|
|
| |
If we didn't do this, we would need to transfrom
`EncodedLinkSpec`s into a `LinkSpec::Unrecognized`, which is not
semantically right. What's more, every user of this API wants to
consume encoded link specifiers, so encoding them early saves a
little effort.
|
| | |
|
| |
|
|
|
|
| |
This change is necessary so that we can build Extend2 messages
that have their LinkSpecs appear in a verbatim order as provided
in an INTRODUCE2 message or in a HS descriptor.
|
| |
|
|
|
| |
This version of bitflags now requires us to explicitly list the
traits that we want to derive for our bit-flags structs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
(This is the encrypted information inside the INTRODUCE2 cell; it's
used by the client to tell the service where to find its rendezvous
point.)
|
| |\
| |
| |
| |
| | |
tor-cell: Rename Rendezvous*::message to handshake_info.
See merge request tpo/core/arti!1045
|
| | |
| |
| |
| | |
Follow-up from !1038
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|