| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| |
|
|
|
| |
This conditionally compiles most of the code related to managed
transports.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is a little nicer and more type-safe to work with than
`TransportConfig`. It would have been nice to change `TransportConfig`
directly instead, but it would slightly change arti_client's public API,
and would require an extra field in the `[[bridges.transports]]` toml
table.
|
| |
|
|
| |
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
|
| |
|
|
| |
This commit is automatically generated.
|
| |
|
|
| |
(This is !Default, since there is no default TransportConfig.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This will suffice to bypass the reactor when we're dealing with
an unmanaged pluggable transport.
Closes #755.
|
| |
|
|
| |
Now that it's extracted, we can remove a mut and some nesting.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This is based on an original branch by Trinity. Instead of its
original approach, which used an enum in the configuration to
distinguish managed from unmanaged transports, this branch uses
builder validation function to ensure that incompatible options
aren't used together. Doing the lets us generate better error
messages.
Thanks: trinity-1686a <[email protected]>
|
| |
|
|
| |
We're going to start using this type for _every_ kind of transport.
|
| |\
| |
| |
| |
| | |
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.
|
| |/ |
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
It's a bit of a wart that tor-ptmgr calls these "protocols" and
tor-guardmgr calls these "transport names".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Closes #950.
|