I prefer that it not take `&mut self`, since PtMgr already has
interior mutability.
I also need it to take `tor_config::Reconfigure` argument, in case
it gains any more smarts about validation in the future.
These are implementation details and we don't want to mark them as
stable.
To do this, I needed to apply some additional options to the example
code's configuration in Cargo.toml.
This commit makes the `ChanBuilder` type in `tor-chanmgr` usable by
consumers outside of that crate, like the doc comment for
`ChannelFactory` says you need to be able to do in order to turn your
`TransportHelper` into something useful.
As part of doing this, the `event_sender` its constructor takes needed
to be dealt with, since it was a crate-internal type that came from
inside the `ChanMgr`.
Enter `BootstrapReporter`: an opaque wrapper around that sender, now
provided as an additional argument to
`ChannelFactory::connect_via_transport`. You can now construct a
`ChanBuilder` outside this crate, and it'll still be able to report its
bootstrap status by unwrapping this new type that's threaded through
from the `ChanMgr`. (This was a fair deal of manually threading the type
through all the layers in this crate!)
Note that you cannot implement bootstrap updating using something that
isn't `ChanBuilder` yet due to the type being entirely opaque (but, of
course, we can figure out exactly what API the reporter should have
later, and add that capability in).
This commit implements `PtMgr`, a pluggable transport manager
responsible for keeping track of spawned PTs and spawning them to
satisfy client requests on demand.
It does this in two parts: the `PtMgr` type exported to the rest of the
code, and the background `PtReactor` that actually does the spawning;
this design ensures that only one attempt to spawn a PT is active at a
time, and will prove useful later for implementing e.g. timeouts.
A few changes were necessary to the rest of the code in order to make
this all work out. Namely:
- `TransportRegistry`'s API didn't make any sense for two reasons:
- It wasn't feasible for implementors to implement `ChannelFactory`,
since that'd require constructing a `ChanBuilder` (which requires a
bootstrap reporting event sender).
- Treating the PT manager as a registry is over-general; it's only
necessary for it to spawn pluggable transports, so saddling it with
other concerns didn't make any sense.
- (It's possible to get extensibility for arbitrary user customization
by just letting the user swap in a new `ChannelFactory`, anyway.)
- Therefore, the `PtMgr` implements the new `AbstractPtMgr` trait, which
is far more narrowly focused; this only exists to solve a dependency
loop, and is documented as such.
- This provides a `TransportHelper` instead of a `ChannelFactory`.
Enums with variants conditional on cargo features must be
non-exhaustive, because cargo features are supposed to be additive,
meaning that enabling a feature (which might happen due to some random
distant thing) ought not to break things using that enum.
There were surprisingly few places to fix this.
Now that they have merged
https://github.com/rust-lang/rust/pull/104416 ,
our CI should pass again with the regular nightly image.
Rather than remove the pinned image entirely, I'm commenting it out,
with a comment explaining how to pin an image the next time we need
to do so.
Closes#633.
SourceInfo primarily appears in errors, here and in (indirectly)
tor-dirmgr.
This
1. Makes the errors smaller
2. Redacts (currently, scrubs) the chantarget when safe logging is enabled
This commit therefore deals with both tor-dirmgr and tor-dirclient
errors, from the pov of error information that should become sensitive
as part of bridge support.
The error pyaloads directly in tor_dirmgr/src/err.rs don't seem to
contain anything in that category.
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
1. Makes the errors smaller (in the case of Io's PtTargetAddr;
ChannelBuild's addresses are already indirected in a Vec).
2. Redacts (currently, scrubs) the PtTargetAddr and SocketAddr
when safe logging is enabled
These are the remaining error variants in tor-chanmgr that contain
information that should become sensitive as part of bridge support.
This
1. Makes the errors smaller
2. Redacts (currently, scrubs) the chantarget when safe logging is enabled
This commit doesn't treat other should-be-sensitive inforemation in
errors just yet. That will come in a moment.
Nick Mathewson
eta
trinity-1686a
Ian Jackson
Ian Jackson