We now have support for a pool of pre-build circuits that we can use
for HS-related purposes, and we take circuits from this pool as
needed.
Nothing populates or cleans the circuit pool yet.
Abolish CircMgr::get_or_launch_onion_client and everything to support
it. We have decided that `.onion` diversion ccan't/shouldn't occur in
tor-circmgr. Probably, it should occur much higher up - arti-client
maybe - since it will sometimes need ambient authority (KS_hsc_*).
Now all knowledge of HS connections is in tor-hsclient. This
gets rid of a layering inversion and the trait needed for tor-circmgr
to do the upcall to tor-hsclient.
*If* we're going to retain any HS knowledge in circmgr, it definitely
doesn't need to know about per-operation client secrets.
(Maybe there might be ambient secrets, used for .onion diversion, but
they don't need to be in this API.)
Otherwise there has to be a state entry in the circmgr *and* a state
entry in the hs connector, for every HS. This division of
responsibilit will be confusing.
The HS code will then be more completely just a layer on top of circmgr.
These crates have had small code changes, but no API additions:
tor-config
tor-socksproto
tor-cert
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
arti
tor-hsservice
tor-congestion
These crates have had API extensions:
fs-mistrust
tor-llcrypto
tor-bytes
tor-checkable
tor-linkspec
tor-netdoc
tor-persist
arti-client
These are API breaks, but the crates themselves are currently
100% experimental, so there's no need to bump the minor versions
according to our semver rules.
These changes influence behavior, but not effect compatibility.
(If I messed up, and any crate except for `arti` has non-breaking
API changes, that's still fine, since they are all version
0.x.)
Clippy now complains about `let _ = (expr_producing_a_future);`,
which is probably smart, since maybe you wanted to await that future
and ignore the result. So it seems that the right way to get rid of
an unwanted Receiver is now to drop it explicitly.
Closes#749
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes#748.
This
1. Makes the errors smaller
2. Redacts (currently, scrubs) the chantarget when safe logging is enabled
The other error variants in tor-circmgr::Error don't seem to contain
information that should become sensitive as part of bridge support.
This commit replaces the
`impl From<&T> for OwnedChanTarget where T:ChanTarget`
with a new `IntoOwnedChanTarget` trait. This lets us be explicit
that we're constructing an owned object, and not just converting
something.
No semver change needed, since these APIs haven't been released.
----------- (new description)
Nick Mathewson
trinity-1686a
Ian Jackson
eta
Emil Engler