| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The `KeypairData` type from [ssh-key] at some point leaked into the
keymgr API (via the `EncodableKey` trait). Instead of re-exporting just
`KeypairData`, let's re-export the entire `ssh_key` crate
(`EncodableKey` implementors would need additional types from `ssh_key`
to construct a `KeypairData` object anyway).
[ssh-key]: https://crates.io/crates/ssh-key
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This helper is no longer needed (the logic from
`parse_ssh_format_erased` changed).
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 `"[email protected]"`).
Closes #936
[custom algorithm names]: https://github.com/RustCrypto/SSH/pull/136
|
| | | |
| | |
| | |
| | | |
This brings in the changes from #936.
|
| | |/
|/|
| |
| |
| |
| |
| |
| | |
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 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.
|
| | | |
|
| | |
| |
| |
| | |
Closes #993
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| |\
| |
| |
| |
| | |
tor-proto: Implement IncomingStream::discard()
See merge request tpo/core/arti!1484
|
| | |
| |
| |
| | |
These functions only ever return `Bug` errors.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| |\ \
| | |
| | |
| | |
| | | |
tor-error: Remove KeystoreFsPermissions variant.
See merge request tpo/core/arti!1487
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
According to the `ErrorKind` lumping guidelines, `KeystoreFsPermissions`
should be lumped with `FsPermissions`: they represent the same type
of error, and their "location" is the same ("Host").
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1315#note_2916455
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
As demanded by rustfmt
|
| | |
| |
| |
| | |
This complements the new `check_bridge_pt` test.
|
| |/
|
|
| |
This is a bugfix. Perhaps it is a security fix?
|
| |\
| |
| |
| |
| | |
tor-proto: Replace IncomingStreamMsg with IncomingStreamRequest.
See merge request tpo/core/arti!1477
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The two enums essentially serve the same purpose, so we don't
need both of them.
This also addresses the TODO that says we should return an error if
`accept_data` is called for a RESOLVE stream.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-proto: Implement `Drop` for `IncomingStream`.
See merge request tpo/core/arti!1476
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
blocking.
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.
|
| | |/ |
|
| | | |
|
| | |
| |
| |
| |
| | |
The behaviour of `IncomingStream::drop` is going to depend on whether
the stream was accepted or not.
|
| | |
| |
| |
| |
| |
| |
| | |
reactor to respond.
This will be used for implementing `Drop` for `IncomingStream` (it
needs to "reject" the stream on drop).
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This will allow us to proceed if
* the default config file locations can't be established
(eg due to failure of the `directories` crate), but
* configuration files are explicitly specified,
so the defaults wouldn't be used
|
| | |
| |
| |
| | |
We'll use this in crates/arti in a moment.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Improves the error mesage in #989 somewhat.
Before:
target/debug/arti: error: Can't construct project directories to resolve a path element
After:
target/debug/arti: error: identify default config file locations: Can't construct project directories to resolve a path element
|
| |
|
|
|
|
|
|
| |
This is a follow-up from !1451.
This commit solves a `TODO HSS` introduced when `DataCmdChecker` got an
additional constructor (`new_connected`) for creating "pre-connected"
streams. See f6745d31 for more details.
|
| |\
| |
| |
| |
| |
| |
| | |
tor-proto: allow_stream_requests now waits until the control message is received.
Closes #994
See merge request tpo/core/arti!1474
|
| | |
| |
| |
| |
| |
| |
| |
| | |
init/close.
Propagating the error means will cause the reactor to shut down (there's
not much the control message sender can do about it, so there's no point
in sending it the error).
|
| | |
| |
| |
| |
| |
| |
| |
| | |
As a result, by the time the `reject` future resolves, the stream has
been removed from the reactor's stream map and the corresponding END
cell has been sent.
Fixes #998.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
received.
`ClientCirc::allow_stream_requests` is now `async` and waits until the
`AwaitIncomingStream` control message is processed by the reactor.
This guarantees that by the time the `allow_stream_requests` future
resolves, the reactor is ready to process BEGIN/BEGIN_DIR/RESOLVE cells.
Previously, the client tasks from allow_stream_requests tests had to
sleep before sending the BEGIN cell to give the reactor time to process
the `AwaitIncomingStream` control message (which tells the reactor to
expect incoming BEGIN/BEGIN_DIR/RESOLVE cells on the circuit).
Fixes #994
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation here is perhaps excessively simple: we put
a `oneshot::Sender` in the `Reactor` object, and a
`Shared<oneshot::Receiver>` in the circuit or channel. When
the reactor is dropped, any copy of the `Shared<Receiver>` will
yield `Err(Cancelled)`.
I'm marking these methods as experimental because I'm not sure I've
thought of all the implications here, and we might want to change
things around.
Down the road, these methods might want to yield a `Result<>`
indicating why the reactor was shut down.
This feature was inspired by a request from Saksham Mittal, and a
felt need while working on !1472.
|