Previously, the Arti key store would store x25519 secret keys as ed25519
OpenSSH keys, which it would convert to x25519 upon loading (using the
conversion function added in !1297 (merged)). This approach isn't good
enough though: most people will probably want to bring their existing
x25519 keys, and in order to store those in OpenSSH format, we'd need
convert them to ed25519, which is impossible (because the secret part of
an x25519 key contains a SHA512'd secret, whereas the corresponding,
"un-expanded", ed25519 secret key contains the secret itself rather than
the SHA).
Now that `ssh-key` has support for ssh keys with [custom algorithm
names], we can store x25519 in OpenSSH format directly. This commit
changes the storage format used by the keymgr for x25519 client auth
keys (from ed25519-ssh to our own custom key type with an algorithm name
of `"x25519@torproject.org"`).
Closes#936
[custom algorithm names]: https://github.com/RustCrypto/SSH/pull/136
Previously we were using backtrace 0.3.39, which has a [bug] that causes
it to segault in some circumstances. I experienced this bug while trying
to fix the minimal-versions build in !1508.
[bug]: https://github.com/rust-lang/backtrace-rs/issues/267
This is the API deficiency in ed25519-dalek v1 that allows you to
mismatch public and private keys, leading to a (fatal)
double-signing attack. We have worked around this in our current
design, so it's appropriate to suppress this warning for now.
This should be enough now to establish real introduction points,
though there is still a lot of work to do. Part of #976.
This has been rebased and edited to incorporate discussions from
!1465.
These values are computed as part of the circuit extension
handshake, and are used as MAC keys to bind `ESTABLISH_INTRO`
messages to a particular circuit so that they can't be replayed.
Part of #993.
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.
This will be useful in preference to the regular Mac trait for the
places where we need to pass a Mac key around, but we don't need to
support incremental operation.
Part of arti#993, where we want to expose a MAC object without
exposing sensitive data.
This was added in 9357a8fd6b "ci: add shebang to the GitLab CI" as
part of !990 to the `maint-checks` job; but the actual additional
check was added to the `doc-features` job (by mistake, fixed in
!1490); and, that shebang check script doesn't need git anyway.
Currently, the `maint/coverage` script does not inform about the
dependencies required for generating the HTML output, those are, the
Python packages `bs4` and `lxml`.
This commit fixes that, by updating the help section accordingly.
This commit introduces an `IncomingStreamState` enum, which indicates
whether the stream was accepted, discarded, or rejected, or if it is
still pending. The `is_rejected`/`is_accepted` boolean flags are no
longer needed.
Without this change, we'd need to introduce yet another boolean flag
when we implement `discard()` (for the "discarded" state).
This commit removes a list we provide for the supported grcov formats.
In my opinion, this is a practice of bad software engineering, as we would then
have to maintain this list by ourselves.
Therefore, this commit removes this list from the `maint/with_coverage` script
and replaces it with a references to the accompanying grcov command.
Instead of having 2 version of `StreamTarget::close` (a blocking one and
a nonblocking one), we can just return the `oneshot::Receiver` for
receiving the reactor's response and let the caller of
`StreamTarget::close` decide whether to block.
This allows us to reduce some code duplication in the `IncomingStream`
implementation.
Gabriela Moldovan
Nick Mathewson
Ian Jackson
Ian Jackson
Emil Engler