| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| |
| |
| | |
Convert to the latest versions of dalek-cryptography
Closes #808
See merge request tpo/core/arti!1767
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This code was needed with the old version of dalek-cryptography,
which wasn't compatible with up-to-date versions of the `rand`
crate(s). But now that we've upgraded, we can drop this.
(We could have left it around and deprecated it, but we are already
making a breaking change to tor-llcrypto by upgrading
dalek-cryptography.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
This makes it possible to see the wood for the trees.
This may be controversial, but I think it's an improvement.
|
| |/
|
|
|
| |
These messages are very verbose and I doubt anyone will want them,
usually, even when debugging.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| | |
This is in keeping with the behavior of C tor, and of
torspec!179.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
While looking for differences, we found that C tor always
omits the flags and the hostname from a BEGIN message sent on an
onion service circuit. In torspec!179, we specified that behavior.
This patch brings arti into conformance.
Closes #1077.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Use consistent phrasing when describing the two key fields to make it
clear they're referring to the same relay.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously it was possible for `handler` to be None only when
`msg` was also None, which would make SendMsgAndInstallHandler into
a no-op. Now, if `msg` is present but `handler` is absent, we
use the previously installed handler, which I think was our
intention.
Without this patch, `Conversation::send_message` simply won't work.
Fixes #1085.
|
| | |
| |
| |
| |
| |
| | |
(We already require that it is Send when the client gives it to us
in circuit.rs, but we had previously forgotten that when we stored
it in the Reactor.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Peraonally I would prefer
| #![cfg_attr(not(all(feature = "full", feature = "experimental")),
| allow(dead_code))]
but I think that is almost certainly controversial.
See tpo/core/arti#704.
|
| | |
| |
| |
| |
| | |
As per this comment, and preceding discussion
https://gitlab.torproject.org/tpo/core/arti/-/issues/1060#note_2959187
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Refactor the stream-closing logic in tor-proto
Closes #1065
See merge request tpo/core/arti!1681
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Because dropping a `StreamTarget` causes the circuit reactor to send
an End, the previous do-nothing implementation of `discard()` wasn't
sufficient to cause the request to be ignored without sending an
End.
This commit modifies our "close pending stream" behavior to only
optionally send an End message. To avoid confusion, I'm using a new
`CloseStreamBehavior` enum rather than an `Option<End>`, since we
had previously used `None` in some cases to indicate a default
(misc) end message.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Now that every state-change function consumes the IncomingStream,
there is no longer any reason to keep track of an internal state
enum.
|
| | | |
|
| | |
| |
| |
| |
| | |
Now that IncomingStream doesn't implement Drop, we can just
destructure it.
|
| | |
| |
| |
| |
| | |
Since dropping a StreamTarget will send an End, we don't need
to call reject_internal in this case.
|
| | |
| |
| |
| |
| |
| |
| | |
Now that `StreamMap::terminate` no longer panics, and now that it
permits the kind of double-call that we allow, we can close #1065.
Closes #1065.
|
| | |
| |
| |
| |
| | |
The rule is that we allow up to one explicit `close_pending`,
followed by exactly one final `mpsc::Sender` drop.
|
| | |
| |
| |
| |
| | |
We will use this to enforce correct ordering on "close" vs "drop"
APIs.
|
| |\ \
| |/
|/|
| |
| | |
Upgrade several dependencies.
See merge request tpo/core/arti!1680
|
| | | |
|
| | |
| |
| |
| | |
See #1065 for more information here.
|
| |/
|
|
|
|
|
|
|
| |
It turns out that we can make `IncomingStream::reject()` consume
self, thus making it impossible to hit the double-close error
from outside the `tor-proto` crate.
Also, we rename `StreamTarget::close()` to `close_pending()` to
better reflect its limited applicability.
|