| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
pt-spec says:
```
If the encoded argument list is less than 255 bytes in
length, the "PLEN" field must be set to "1" and the "PASSWD"
field must contain a single NUL character.
```
This is a very silly thing to say, but some PTs enforce it.
Fixes #676.
|
| | |
| |
| |
| |
| |
| |
| | |
Our previous code would make a TCP connection to the proxy, then
wait forever for it to say something. Whoops!
Part of a fix for #676.
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| | |
chanmgr: resolve several remaining "TODO pt-client" issues
See merge request tpo/core/arti!897
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
Allow GuardMgr to expose bridges as guards (part 1)
See merge request tpo/core/arti!785
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now it contains either an `OwnedChanTarget` or an `OwnedCircTarget`,
which will let `GuardMgr` return bridges that can be used to make
circuits.
As part of this change, it was necessary to revise some
address-modification functions that applied to filters and
`OwnedChanTarget`. Now they do the smart thing, and remove only the
address that are in the `ChanMethod`. This means that the addresses
from HasAddrs are still accurate about which addresses the relay
"has".
|
| |/
|
|
|
| |
If pt-client is disabled, there are in fact no tests, so the module is
empty. But we would always want `use super::*` here.
|
| |
|
|
| |
This causes CI problems, and is entirely my fault.
|
| |
|
|
|
|
|
| |
This is a compromise between C tor (never escapes = signs) and the
spec (calls for escaping all = signs). In C tor there is no way to
actually construct a key with an = sign in it, so this difference
should be undetectable.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is mostly a matter of encoding parameters in the format used
for socks authentication.
|
| |
|
|
|
|
|
| |
This code is _not_ conditional, since we want to support running
with a proxy even if we don't support pluggable transports.
We may eventually want to refactor this into a new create.
|
|
|
There is no actual code change here: just movement.
|
