| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1071/diffs?commit_id=580fe1118dbbbfa086d11b28e3e26d7c91afe21c#fbd7ab2d6d0a5b515697d4f9f99a42ebd508aa4b_153_165
|
| | | |
| | |
| | |
| | | |
I think this is uncontroversial; we already have it for Sensitive.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This avoids some dead code warnings when building without send-control-msg.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Here I use the name I propose in !1039.
|
| | | |
| | |
| | |
| | |
| | | |
Obviously this still doesn't work because the actual impl in hsclient
is just a todo!().
|
| | | | |
|
| | | |
| | |
| | |
| | | |
We want this part for HS too.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We're going to want to reuse this.
Also: rename StreamPrefs::isolation and update the docs, to better
reflect its rather limited functionality. The new
TorClient::isolation is the only call site.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This seems more consistent with the way it's done elsewhere.
|
| |/ / |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This uncovered a bug: NoUsage wasn't correct for Hs circuits because
of its behavior with channel_usage().
|
| | | |
|
| | |
| |
| |
| | |
(Still, only expose it when experimental-api is enabled.)
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The prediction and scheduling logic here is quite primitive;
we should probably refactor it considerably. This should be good
enough for now, though.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We now have support for a pool of pre-build circuits that we can use
for HS-related purposes, and we take circuits from this pool as
needed.
Nothing populates or cleans the circuit pool yet.
|
| | |
| |
| |
| |
| | |
This is now enough to launch circuits on demand. It still needs to
pre-build the first three hops, and to retry on failure.
|
| | | |
|
| | |
| |
| |
| |
| | |
This only builds the first 3 hops. It can be extended to a fourth
hop later -- or not, depending on the circuit kind.
|
| |/
|
|
| |
We'll use this to implement the circuits used by onion circuits.
|
| |
|
|
| |
TODO HS is blocking for HS release, but not for CI.
|
| | |
|
| |
|
|
| |
I don't think these are that bad in testing code.
|
| | |
|
| |\
| |
| |
| |
| | |
tor-ptmgr: Fix fuzzer compilation.
See merge request tpo/core/arti!1063
|
| | |
| |
| |
| |
| |
| | |
Since we made the internals of the ptmgr protocol parser
conditionally private, we need to tell Cargo to build the fuzzer
with the `experimental-api` feature so that it can access them.
|
| |/
|
|
|
| |
This version of bitflags now requires us to explicitly list the
traits that we want to derive for our bit-flags structs.
|
| |\
| |
| |
| |
| | |
Resolve a couple of new lints with Rust 1.68
See merge request tpo/core/arti!1062
|
| | |
| |
| |
| |
| | |
Apparently 1.68 now warns when you call into_iter() on something
that's already an iterator. Fair enough. Let's stop doing that.
|
| | |
| |
| |
| |
| |
| |
| | |
The derive_hash_xor_eq lint was renamed in 1.68, but we can't use
it under its new name, since we still need to support back to 1.60.
Instead, we suppress the warning about the lint being renamed.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We have a theory about how this ought to work, so it's noit an API
usage error - it's an unimplemented feature.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1060#note_2884757
|
| | |
| |
| |
| |
| |
| | |
Reject them both for .onion and for "exit" hostnames
This prevents a `Host` from having an invalid hostname in it.
|
| | |
| |
| |
| |
| | |
Reported in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1060#note_2884755
|
| | |
| |
| |
| |
| | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1060#note_2884754
|
| | |
| |
| |
| | |
And add some clarity and todos about address errors.
|
| | |
| |
| |
| | |
Provide an explicit From impl isntead.
|
| | |
| |
| |
| | |
This error is not great.
|
| | |
| |
| |
| |
| |
| |
| | |
Now, a Host has a separate variant for `.onion` which is always used,
even when HS is disabled.
Currently it ends in a todo!.
|
| | |
| |
| |
| | |
This is more comprehensible, and will be more convenient.
|
| |/
|
|
|
| |
write! is less good because the `{}` overwrites stuff like "did the
caller ask for padding".
|
| |\
| |
| |
| |
| | |
tor-proto: send an outbound meta/control-message and expect similar messages in return.
See merge request tpo/core/arti!1051
|