| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | |/
| |/|
| | |
| | |
| | |
| | | |
The error message from `#[serde(untagged)]` would otherwise start to
appear when we try to deserialise unsupported PT configurations, when
compiled with bridge but not PT support.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Fix and resolve TODO pt-client comments in guardmgr, linkspec.
See merge request tpo/core/arti!896
|
| | | | |
| | | |
| | | |
| | | | |
We've revised this a few times; now it seems plausible.
|
| | | | | |
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
More post-merge cleanups for ptmgr
See merge request tpo/core/arti!895
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Post-merge cleanups for PtMgr
Closes #667 and #659
See merge request tpo/core/arti!893
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Per convention, have a `full` feature.
Also, downgrade the 'TODO pt-client' entries in README::limitations,
since they are not blockers for 1.1.0.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Dependency upgrades and updates in preparation for upcoming release
See merge request tpo/core/arti!892
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
reproducible builds without shm
Closes #614
See merge request tpo/core/arti!818
|
| | | |/
| |/| |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Define a "redactable" trait, and use it when logging guard info
Closes #648 and #627
See merge request tpo/core/arti!882
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This machinery is a bit inelegant, but it is all confined to
be within the GuardMgr crate, so IMO it should be fine for now.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Closes #627, again.
Closes #648.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This is super helpful for cases where we want to write two nearly
identical implementations to format a type.
|
| | | | | |
|
| | |/ /
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
tor-netdoc: More tests for routerdesc accessors and parsing.
See merge request tpo/core/arti!870
|
| | | | |
|
| | | |
| | |
| | |
| | | |
These required hex-editing identity certificates :P
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This is from Akka, which ahf runs.
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Pluggable transport manager
See merge request tpo/core/arti!886
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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`.
|
| |\ \
| | |
| | |
| | |
| | | |
Make ChannelMethod non-exhaustive
See merge request tpo/core/arti!891
|