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)
Without this fix, any attempt to actually use a circuit for a
`DirSpecificTarget` will fail, since supports() will say false, and
`restrict_mut()` will say `NotSupported`.
Having this done within circmgr was irregular - most of our other key
buildup functions are done in TorClient::create_inner.
It is also inconvenient, as it buries the guardmgr within the circmgr.
These arguments were used only for legacy (testing) purposes; the
tests now use `TestNetDirProvider`. This lets us simplify our
internal logic for passing a `NetDir` to our samples, and prepare
for having a `BridgeSet` to pass there instead.
This is a breaking change to `guardmgr` and `circmgr`.
Previously we could only use Relay for this case, which won't work
any more: a Bridge is not a `tor_netdir::Relay`. Instead we allow
the GuardMgr to give us something that knows how to convert itself
into an OwnedCircTarget.
This change required a far amount of follow-on revisions and
refactoring, but it should all be internal to the path-building
logic.