As near as I can tell, the rust-crypto SHA1 crate was called `sha-1`
for a while because of a conflict with a different SHA1 crate. Now
they apparently have the `sha1` name back and have deprecated the
`sha-1` name.
This makes a `pt_state` directory inside .local/share/arti (or the
local equivalent), right next to our existing `state` dir.
Ideally we would use a separate directory for each PT, but we have a
very fuzzy "what is a specific PT" notion.
Closes#667
If support is available at compile-time, then we construct a PtMgr
and register it with the ChanMgr. We keep a handle to it ourself so
that we can reconfigure it as needed.
Closes#659.
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`.
A "redactable" object is one that can be _partially_ scrubbed in
sensitive contexts. This can be very helpful for UX, but is not
risk-free: see comments.
Nick Mathewson
Ian Jackson
eta
trinity-1686a