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).
These crates are at version 0.x.y, so we don't need to distinguish
new-feature changes from other changes:
```
tor-basic-utils
fs-mistrust
tor-error
tor-geoip
tor-checkable
tor-linkspec
tor-netdoc
tor-netdir
tor-persist
tor-ptmgr
tor-hsservice
```
This crate has a breaking change, but only when the semver-breaking
feature `experimental-api` is enabled:
```
tor-config
```
This crate is at version 1.x.y, but has no new public APIs, and
therefore does not need a minor version bump:
```
arti
```
These crates had first-order breaking changes:
```
retry-error
tor-keymgr
tor-proto
tor-hsclient
tor-rtmock
```
Additionally, these broke because they re-exposed RetryError:
```
tor-circmgr
```
Additionally, these broke because they may re-expose something from
tor-proto:
```
arti-client
tor-chanmgr
tor-dirclient
tor-dirmgr
tor-guardmgr
```
Additionally, these broke for other fiddly reasons:
`tor-ptmgr` implements traits from tor-chanmgr, which has a breaking
change above.
`arti-hyper` exposes types from arti-client in its API.
I think it's safe to handle `ChanMsg::Create` separately, because
there's nothing for the reactor to do until the first hop of the circuit
is created (so blocking on this _should_ be alright).
This logic from `create_firsthop()` was extracted (copied) from
`Reactor::run_once()`. A future commit will update `Reactor::run_once()`
to use `create_firsthop()`.
Was UninstallHandler. We are going to talk more about conversations
and less about handlers (although, the fact of there being a handler
will still be visible).
Done with the commands below.
The following crates have had various changes, and should get a
patchlevel bump. Since they are pre-1.0, we do not need to
distinguish new APIs from other changes.
```
cargo set-version --bump patch -p arti-client
cargo set-version --bump patch -p safelog
cargo set-version --bump patch -p tor-bytes
cargo set-version --bump patch -p tor-cert
cargo set-version --bump patch -p tor-circmgr
cargo set-version --bump patch -p tor-config
cargo set-version --bump patch -p tor-consdiff
cargo set-version --bump patch -p tor-dirclient
cargo set-version --bump patch -p tor-dirmgr
cargo set-version --bump patch -p tor-error
cargo set-version --bump patch -p tor-hsservice
cargo set-version --bump patch -p tor-linkspec
cargo set-version --bump patch -p tor-llcrypto
cargo set-version --bump patch -p tor-netdir
cargo set-version --bump patch -p tor-netdoc
cargo set-version --bump patch -p tor-proto
cargo set-version --bump patch -p tor-rpcbase
cargo set-version --bump patch -p tor-socksproto
```
This crate has new features, but no new non-experimental Rust APIs.
So even though it is post-1.0, it gets a patchlevel bump.
```
cargo set-version --bump patch -p arti
```
=========================
Notes from nickm:
(This differs from pinkforest's original MR: It removes the
Cargo.lock changes and the version bump on tor-llcrypto.)
Minimal Cargo.lock changes from downgrade.
(These are exactly those changes generated by running "build" and
"test".)
There are several reasons to do this:
* It's best to bump all of our dalek dependencies at once to rc.3
or later, rather than the piecemeal approach we've been stuck
with so far.
* We don't want to do this bump right now, since there are some
tricky questions about clamping we need to figure out (see
#808), and we need to make sure we get them right, and we're in
a distracted this week.
* We _do_ need to move away from 2.0.0-rc.2 right now, since
it was causing a failure in `cargo install arti`, and then it
got yanked.
Thanks to pinkforest for helping us out here and explaining all of
this!
Fixes#926.
Commit-edited-by: Nick Mathewson <nickm@torproject.org>
The new path_ref() method returns an Arc<Path>, which gives a much
better API for reasons discussed in the new documentation of path().
(We could just replace path() if we'd prefer, but IMO having
path_ref() here isn't so bad.)
The new PathEntry struct wraps the old PathEntry enum, which has
been renamed to HopDetail. It's an opaque struct because we want to
be able to put new information in the enum as we think best.
This is mostly code movement; you may want to review it with
`--color-moved`.
I'm doing this so we can also use the function in netdoc for
looking up hsdesc authentication.
Onion service hops (pointlessly) use SHA3-256 for their
authentication, but they truncate it to 20 bytes (assuming I'm
reading the C right.)
See torspec#204 for clarification here.
We want the ability to send the same handshake request in parallel
on multiple introduce circuits. This implies encoding the client
handshake more than once.
(Sadly we can't _actually_ do this in the protocol as it stands,
since the onion service can use a separate KP_hss_ntor for each
introduction point; I'll add a comment to that effect later.)
When we break the 1:1 relationship of message and cell, we'll want
this API to take messages, not cells.
This API is experimental, so we don't need to call it a semver
break.
Closes#881.
Formerly we said that it would not return until the handler
was uninstalled. This is incorrect: it returns as soon as the
message is sent and the handler installed.
Closes#885.
I am hoping we can merge this as a "TODO (Diziet)", even though I
think it may be controversial. Ie merging this doesn't represent a
decision to do as I suggest.
Also, no longer talk about handlers being "installed". That's not
something that's exposed by this API.
And, say that `send_control_message` can be called again only
after *`send_control_message`* returns, not when `handle_msg` has
returned `UinstallHandler`. IMO this makes more sense.
Explain that we can't maintain a continuous watch while holding a
conversation with the peer. (This is surely an API bug.)
Gabriela Moldovan
Nick Mathewson
Ian Jackson
Ian Jackson
Alexander Færøy
pinkforest