| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
Closes #1078.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
rustfmt has grown opinions about how let ... else ... ought to be
formatted. They don't always agree with our previous manual
decisions.
I think our policy is to always insist on rustfmt. When that version
of rustfmt hits stable, our CI will start to fail for everyone.
(Right now this discrepancy just causes trouble for contributors who
are using nightly by default.)
|
| | |
|
| |
|
|
| |
Closes #950.
|
| |
|
|
|
| |
Invent a trait a la circmgr config for the hs client connector config.
Plumb a suitable value all the way through to the code that will use it.
|
| |
|
|
|
| |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1290#note_2915679
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1290#note_2915678
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1290#note_2915676
|
| |
|
|
|
|
|
|
|
| |
This is a change to the API docs, but not to the actual code, since
our call site is in arti-client and tied to netdir fetch,
which *doesn't* happen when dormant.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1290#note_2915677
|
| |
|
|
| |
Otherwise we'll fill up our RAM with junk.
|
| | |
|
| |\
| |
| |
| |
| | |
lints: Promote clippy::print_stderr and clippy::print_stdout
See merge request tpo/core/arti!1271
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
The HS `HsClientSpecifier` and `HsClientSecretKeySpecifier` are moved to
`tor-hsclient`. The HS service secret key specifier stubs are moved to
`tor-hsservice`.
|
| |
|
|
|
| |
This gets rid of a lot of repeated `oneshot::<...<Result, ...>>` and
a bit of repeated functional code, etc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This contains code to:
* Iterate over introduction points
* Make multiple attempts to connect
* Apply timeouts to the various phases of each attempt
* Establish a rendezvous point
* Represent errors that occur during the above
It provides places to add:
* Implementation of the INTRODUCE1/INTRODUCE_ACK handshake
* Reception of RENDEZVOUS2 and actual end-to-end circuit establishment
* Recording of the outcome of connection attempts via particular IPTs
* Using previous IPT outcome information for selecting IPTs to try
* Tests of the new code (although more mocking will probably be needed)
Much of this code works with a fixed type ClientCirc rather than going via
the Mockable traits. That is wrong, and it will be fixed later.
|
| |
|
|
|
|
| |
We're going to want to report about rendezvous points in errors.
We'll do this by printing the "number" of the intro point in the descriptor.
|
| |
|
|
|
| |
We're going to want to report about rendezvous points in errors.
We'll be using this. And we'll want to convert it from a Relay.
|
| |
|
|
| |
The dead code warnings are a nuisance while this file is half-written.
|
| |
|
|
| |
It's going to appear in our public errors.
|
| |
|
|
|
| |
The main body of this function is written so that we can later use
it to create a CircTarget from an INTRODUCE2 message.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now ClientCirc is no longer `Clone`, and the things that need it
to be `Clone` instead return and use an Arc<ClientCirc>
We're doing this so that ClientCirc can participate in the RPC
system, and so that its semantics are more obvious.
Closes #846.
Thanks to the type system, this was a much simpler refactoring than
I had feared it would be.
|
| |
|
|
|
|
|
|
| |
There are many TODOs here. Some are questions; some are
straightforward and can be done in followups.
With this code, I am able to reach the eprintln! and todo! with
curl --socks5-hostname localhost:9150 https://duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion/
|
| | |
|
| |
|
|
|
| |
The old name was unwieldy and other crates can just as well name it by
the crate scope.
|
| |
|
|
|
| |
This will be more convenient inside tor-hsclient. In arti-client,
this mirrors the way TorClient::get_or_launch_exit_circ works.
|
| |
|
|
|
| |
We separated this out in the circmgr API. This is what the HS client
needs. It doesn't want to participate in the general circuit pool.
|
| | |
|
| | |
|
| |
|
|
| |
And delete the associated TODO.
|
| |
|
|
|
|
|
|
| |
These Arcs are all "downward", referencing items from layers lower in
the stack. So they don't cause cycles.
There was going to be a cycle involving the `OnionConnector` upcall
trait, but we have just abolished that.
|
| |
|
|
|
|
|
|
|
|
|
| |
Abolish CircMgr::get_or_launch_onion_client and everything to support
it. We have decided that `.onion` diversion ccan't/shouldn't occur in
tor-circmgr. Probably, it should occur much higher up - arti-client
maybe - since it will sometimes need ambient authority (KS_hsc_*).
Now all knowledge of HS connections is in tor-hsclient. This
gets rid of a layering inversion and the trait needed for tor-circmgr
to do the upcall to tor-hsclient.
|
| | |
|
| | |
|
| |
|
|
|
| |
Text largely from
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1034#note_2881638
|
| | |
|
| | |
|
| |
|
|
| |
This will allow us to test state.rs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This compiles, but it cannot work yet. Nor can it conveniently be tested.
|
| | |
|
| |
|
|
|
|
|
|
| |
*If* we're going to retain any HS knowledge in circmgr, it definitely
doesn't need to know about per-operation client secrets.
(Maybe there might be ambient secrets, used for .onion diversion, but
they don't need to be in this API.)
|
| | |
|
| | |
|