| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently clippy nightly is better (or worse?) about detecting
complex functions than before, so I'm suppressing these warnings
where they occur.
I have mixed feelings about these warnings: On the plus side,
they really do help to detect functions that are twistier than they
need to be. On the minus side, they get confused by tracing macros,
and the "allows" do pile up. But on the plus side, those "allows"
do provide a way to find functions that need to be refactored,
and they are never uglier than the functions they decorate.
|
| |
|
|
| |
We have a ticket for this. But the ticket number was wrong, so fix that.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Code that's related to managed transports has been moved to a new
'managed' module. This includes the PT reactor since it's not needed for
unmanaged transports.
|
| |
|
|
| |
See: tpo/core/arti#1488.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the PT STATUS handler to not require the presence of
the `TRANSPORT` field in the K/V line. This matches current behaviour of
C Tor and was requested by the Anti-censorship Team at an earlier point
to enable STATUS messages to work for situation where it's not transport
specific messages.
To avoid future issues, we simply ignore any required keys right now
even though TYPE is to be expected.
See: tpo/core/torspec#267
See: tpo/core/torspec!63
See: tpo/core/arti#1488
|
| |\
| |
| |
| |
| | |
Encapsulate usage of config-rs inside tor-config.
See merge request tpo/core/arti!2040
|
| | |
| |
| |
| | |
Previously it used tor_config::Itertools, which is silly.
|
| |/ |
|
| |
|
|
|
| |
Change Path::display to this new function, in call sites where it's
being used for a diagnostic.
|
| |\
| |
| |
| |
| | |
Remove an "HSS" from a "TODO HSS" comment in ptmgr
See merge request tpo/core/arti!1676
|
| | |
| |
| |
| | |
This isn't actually onion service related, AFAICT.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Note: this isn't perfect, though it moves both match arms to
try_match_common_messages, it does end up resolving them separately
using a helper function, and also necessitated creating another
function in the PluggableTransportPrivate trait
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This commit adds a unit test that checks if an empty value is parsed
properly.
It fixes the coverage in `crates/tor-ptmgr/src/ipc.rs:120`.
|
| |
|
|
|
| |
This commit adds a test which checks for a missing value in an SMETHOD
argument.
|
| |
|
|
|
| |
This commit adds a unit test to the `tor-ptmgr` crate, which checks for
forbidden `=` signs while reading a value.
|
| |
|
|
|
| |
This commit adds a unit test to the `tor-ptmgr` crate, which checks if
arguments are terminated with a backslash, which is forbidden.
|
| |
|
|
|
| |
This commit adds a unit test that checks if all octal escape sequences
are treated as an unsupported error.
|
| |
|
|
|
| |
This commit adds a test to the `tor-ptmgr` crate, which increases the
test coverage by checking for escape sequences in values.
|
| |
|
|
| |
I have no idea why these became necessary.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I identified the cases to replace by searching for the string
`.report()`. There are a few that I didn't change:
* A couple of cases that used anyhow::Error,
* One case that reported two Errors.
* Two cases in `tor_hsclient::err` that just did
`error!("Bug: {}")`.
I have also not audited the cases in `tor-hsclient` where we're using
`tor_error::Report` manually.
Nonetheless, closes #949.
|
| |
|
|
| |
Split off for ease of review and possible rebase.
|
| | |
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
|
|
| |
This is based on logs that I added locally while I was trying to
debug some startup issues. Hopefully they'll make things easier the
next time there's something to debug.
Part of #677.
|
| |
|
|
|
| |
(I think this may be impossible now, since we check in ipc.rs, but
IMO it's best to check.)
|
| |
|
|
| |
This lets us avoid logging the user's path.
|
| | |
|
| |\
| |
| |
| |
| | |
Resolved several conflicts while doing so; mostly with !893 and
!895.
|
| | |
| |
| |
| |
| |
| | |
This fleshes out the PtReactor that was previously a stub, making it
actually do reactor-ey things. Note that this is entirely untested, and
might not work at all. Hopefully it does, though.
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
| |
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 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`.
|
| |
|
|
| |
This lets us use `chars()` rather than `char_indices()`.
|
|
|
The new `ipc` module inside `tor-ptmgr` implements the Pluggable
Transport Specification version 1 (`pt-spec.txt`,
https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/pt-spec.txt).
This enables module users to spawn pluggable transport binaries inside a
child process asynchronously, and receive structured information about
how to connect to the transports provided by said binaries.
Internally, this is structured as a pure set of serialisers and
deserialisers for the protocol in the specification (in the form of
environment variables, and the PT's stdout), a wrapper to run the PT
binary and enable accessing its output asynchronously, and a user-facing
wrapper that handles ensuring all the requested transports launched
properly.
The included `run-pt` example is an exceedingly minimal wrapper program
that was useful in testing. More tests can and should be added in a
further MR.
closes arti#394; part of arti#69
|