The IptEstablisher needs to continuously maintain the IPT even as the
netdir is updated. Whereas, the IPT manager just wants to select the
relay from the netdir once and then only think about the relay
identity.
So it makes sense for the establisher to do necessary lookups of the
relay's ids in the netdir.
This was introduced in c82cda85d6
tor-basic-utils: DropNotifyWatchSender: use DropNotifyEofSignallable
and already, then, the is_eof() method is redundant.
At the very least, I need FatalError to be distinct:
IptEstablisher::new ought not to fail unless everything is terrible.
Add a the Spawn variant to FatalError (that we'll need soon) and the
Bug variant (which it seems likely we might need).
This also gets rid of the crate-level Result alias.
This code has most of what we need to go from an INTRODUCE2 message
we've just received to the point where we've connected to the
rendezvous point and we're waiting for a stream of BEGIN messages.
Unfinished pieces are marked with TODO HSS.
Most of #980.
We want to change the error return types of many methods, so we need a
way to name `std::result::Result`.
We could use `StdResult`, but, actually, properly distinguishing the
kinds of errors that can occur in various contexts means we don't
actually want a single Error type for the whole crate, so
`crate::Result` is going to go away.
This commit deprecates the `EncodeError::always_bug` function with a
`From<EncodeError> for Bug` trait, which is a more semantically correct
way to perform this action.
The IPT manager is going to want to separate the IptEstablisher
struct (which contains the Drop signal) from the watch receiver.
We could add an accessor to clone the watch, but the copy in the
IptEstablisher would be redundant.
This makes new()'s signature a bit funky but it's an internal method
so I think that's fine.
This implements the part of the spec that says a node that has already
been selected for a lowered-numbered replica, shouldn't be considered
when choosing `spread` nodes for any other higher-numbered replicas.
Note: previously, the test added in this commit wouldn't have passed
(because `NetDir::hs_dirs` used to return duplicate relays under some
circumstances).
Part of #960
This makes `ring_items_at()` take an extra parameter which specifies
whether an item is acceptable or not. The newly added filtering
capabilities will be used to implement the part of the spec that says
that if a node was selected for a replica, then it shouldn't be
considered when choosing `spread` nodes for any other higher-numbered
replicas.
Previously, the `Requestable` trait assumed the body of the request
would always be empty (`http::Request<()>`). This change replaces the
hardcoded `()` body type with the `Requestable::Body` associated type
(which will allow implementors to create requests with non-empty
bodies). This will enable us to reuse the `Requestable` trait for
building `POST` requests for uploading descriptors.
`download()` is actually a general-purpose function for sending HTTP
requests on a stream. We will soon repurpose it for `POST`-ing
descriptors, so let's rename it to `send_request`.
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
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
I had planned to make this code accept extensions of unknown type,
but for now I'm backing out of that plan: the set of extensions we
send influences the set that we're willing to receive.
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.
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 commit makes a trait function use another currently unused trait
function, thereby increasing the test coverage, as well as being
potentially more correct from a semantic point of view.
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).
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.
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
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
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.
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.
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.
`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.
This will enable hidden services to send `RENDEZVOUS1` messages to the
`N`th hop of the circuit rather than the `N + 1`th virtual one (which
can only used after the client and service have completed the
introduction handshake).
This also deprecates `start_conversation_last_hop`.
Closes#959
`HopNum` will be used in `ClientCirc`'s public API when we refactor
`ClientCirc::start_conversation_last_hop` to use the provided hop rather
than always using the last one.
This `sleep` is to give the reactor task a chance to process the
`AwaitIncomingStream` message. With an 100ms, this test sometimes fails
because for some reason the reactor doesn't get a chance to process the
`AwaitIncomingStream` control command before the BEGIN cell from the
client task is received. This bumps the sleep time to 200ms for now
(TODO: follow-up with an MR with a less flaky approach).
While trying to repro the issue, I found another corner case for which
I've added a TODO HSS.
This updates the reactor to call the incoming stream handler even for
streams for which we have a stream map entry of `EndSent`. If we've
sent an END message for a stream but have not yet received an END
message back from the other party, but we later receive a BEGIN from
them, it is safe to assume we cam remove the stream from the stream map
and handle the new incoming stream request.
This adds a new `AwaitIncomingStream` control message for registering an
interest in an incoming stream.
This also adds a `ClosePendingStream` control message for explicitly
closing a stream with a given END message (needed for implementing
`IncomingStream::reject`).
This adds a new `add_ent_with_id` function for adding a new entry to the
`StreamMap`. The existing `add_ent` function auto-generates a new stream
ID, which is not good if we're a hidden service, as stream IDs are
supposed to be chosen by the OP (client). When accepting a new stream,
services, exit relays, and dir auths need to use the stream ID received
in the BEGIN cell (instead of generating a new stream ID).
When accepting a new stream, hidden services, exit relays and dirauths
don't wait for a `CONNECTED` cell from the initiator.
This commit adds constructors for building `DataStream`s and
`DataCmdChecker`s that can immediately receive data cells (and don't
expect to receive `CONNECTED` cells at all).
Ian Jackson
Nick Mathewson
gabi-250
Emil Engler
Ian Jackson