| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed on #tor-dev, I'm reintroducing `VanguardConfig` for now.
The `VanguardConfig` specifies what mode (full/lite/disabled) the
`VanguardMgr` should run in. We currently don't have a separate modes
for HS clients and HS services.
We shouldn't actually *need* a `VanguardConfig` at all, so this is just
a (hopefully!) short- or medium-term fix until we sort out #1382 (which
might involve making breaking changes to our `reconfigure()` APIs).
Closes #1272
|
| | |
|
| |
|
|
|
|
| |
The `VanguardMgr` needs to know whether arti is running as an onion
service or not, in order to figure out which of the `vanguards_enabled`
and `vanguards_hs_service` modes to use.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're not currently using any of the path builders outside of
`tor-circmgr`, so let's make them crate-private for now.
Care must be taken if/when we decide to make them public again. For
instance, the `HsPathBuilder` exposes two path building functions, one
that uses vanguards, and one that doesn't. We want to strongly encourage
the use of the vanguards-aware version of the function whenever the
`vanguards` feature is enabled, without breaking any of its existing
non-vanguard uses.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2046#note_3010217
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1277
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This lets us check long_lived_ports only when we are constructing
a TargetCircUsage, and lets us remember whether or not the circuit
we've built is suitable for non-long-lived ports.
It also lets us decide whether existing circuits are compatible with
new requests.
Closes #1100.
|
| |
|
|
|
| |
These messages are very verbose and I doubt anyone will want them,
usually, even when debugging.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This threads the country codes work through the rest of the codebase:
- `tor-dirmgr` will now enable GeoIP with the embedded database when the
`geoip` future is enabled
- This can be extended later using the `DirMgrConfig` to allow
specifying a custom database; this is not done here, though
- `tor-circmgr`'s `SupportedCircUsage` and `TargetCircUsage` fields gain
new `country_code` members to allow filtering circuits by country
- These are `()` in builds where the `geoip` feature is not enabled --
doing it this way means we don't have to copy and paste huge swathes
of code, since we can't use `#[cfg]` in patterns
- `ExitPathBuilder` gains (hacked-in) support for choosing a relay with
the correct country code
- Due to the lack of conjuction, we just copy and paste a small bit,
pending further refactoring
- `StreamPrefs` now lets you specify a country code, letting embedders
make use of the feature
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Optional tracing support in tor-error for error reporting
See merge request tpo/core/arti!1379
|
| | |
| |
| |
| | |
This simplifies our logging a little, and implements part of
|
| |/
|
|
| |
Closes #950.
|
| |
|
|
|
|
|
|
| |
As per #935.
I called this "circparameters_from_netparameters" not
"circparameters_from_netparams" because the type is "NetParameters"
not "NetParams".
|
| |\
| |
| |
| |
| | |
circmgr: New API to expose estimate-based timeouts.
See merge request tpo/core/arti!1281
|
| | |
| |
| |
| |
| | |
This will help create good timeout values for various onion-service
operations.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Now
nailing-cargo +stable clippy -p tor-hsclient --all-features --all-targets
actually works.
squash! Add some missing imports
|
| |
|
|
| |
(Still, only expose it when experimental-api is enabled.)
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Like the similar thing in tor-guardmgr.
|
| |
|
|
|
|
|
|
| |
*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.)
|
| | |
|
| |
|
|
|
|
|
|
| |
Otherwise there has to be a state entry in the circmgr *and* a state
entry in the hs connector, for every HS. This division of
responsibilit will be confusing.
The HS code will then be more completely just a layer on top of circmgr.
|
| |
|
|
| |
Fixes #756
|
| | |
|
| |
|
|
| |
Split off for ease of review and possible rebase.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Clippy now complains about `let _ = (expr_producing_a_future);`,
which is probably smart, since maybe you wanted to await that future
and ignore the result. So it seems that the right way to get rid of
an unwanted Receiver is now to drop it explicitly.
Closes #749
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
|
|
|
| |
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes #748.
|
| |
|
|
|
| |
Onion services and onion clients need these to make connections to
HsDirs, Introduction points, and Rendezvous points.
|
| | |
|