| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
|
| |
|
|
|
| |
If we have made bootstrapping manual, and not launched a bootstrap,
we now reflect this as the reason that bootstrapping is blocked.
|
| |
|
| |
Co-authored-by: gabi-250 <[email protected]>
|
| |
|
|
|
|
| |
Otherwise we either lose the property that you can call
launch_onion_service before bootstrapping has begun,
or we have to make launch_onion_service async.
|
| |
|
|
|
| |
(This is a separate commit in order make the code movement in the
previous commit clearer.)
|
| |
|
|
|
| |
This will ensure that the TorClient takes its file locks immediately
on construction.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This will let us be more confident in the inertness of a
not-bootstrapping TorClient, _and_ make it easier to reconfigure
things before the client is started.
|
| |
|
|
|
| |
Now that we have a type called "inner", and will soon have a
function to create it, we really don't want to retain this name.
|
| |
|
|
|
| |
We want this look to cover the whole function, to avoid weird
duplicate behavior while creating our bridge desc manager.
|
| |
|
|
|
|
| |
We'll use this to distinguish "not running" from "running",
in order to make it easier to be sure that non-bootstrapping clients
will definitely not try to connect to the network.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Previously the [channel] outbound_proxy setting was applied to Arti's
own direct connections but was not forwarded to managed PT processes.
https://spec.torproject.org/pt-spec/configuration-environment.html
|
| |
|
|
|
|
|
|
| |
Discussion on #1960 suggests that this option is not a good idea:
it encourages developers to work around deliberate signals that the
software they're shipping won't work on the network.
Closes #1960.
|
| | |
|
| | |
|
| |
|
|
| |
These were only Arc<> so that TorClient could implement Clone.
|
| |
|
|
|
|
|
|
|
| |
The `set_stream_prefs` method was the only one that took a TorClient
as `&mut self`. But we only expose Arc<TorClient<R>>, that isn't a
reasonable API.
The `clone_with_prefs` method has been renamed, since it no longer
"clones" anything meaningfully.
|
| | |
|
| |
|
|
|
|
| |
This is part of rationalizing the structure of TorClient so we can
refactor startup logic, and so that RPC code can reason about object
identity. See #2469.
|
| | |
|
| |
|
|
|
|
|
|
| |
The replacement (TestingStateMgr) is not correct, but it will
compile until we have a supported state manager.
(This made cargo-sort have me move a section around. Not sure why it
cares.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This requires the `TlsKeyAndCert` so be passed on the TLS acceptor
settings. We assume that `RelayIdentities` has this information.
The ChanBuilder::new() was getting a bit too convoluted and feature
gated to instead we introduce new_client() and new_relay() and remove
the need for `with_identities()`.
Because of this, the ChanMgr::new() now returns a `Result<>`.
Related to #1597
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This struct is used to pass configuration parameters to the ChanMgr when
building it.
At the moment, it holds the ChannelConfig and RelayIdentities (feature
gated) which will be used in subsequent commits.
Note that relays do require RelayIdentities to build channels.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
We'll rely on a RelayIdentities to pass in the right keys to the ChanMgr
instead of the entire KeyMgr.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Fixes part of #2193.
(Edits from nickm: I selected the cases here that I could verify
were correct from immediate context.)
Edited-by: Nick Mathewson <[email protected]>
|
| |\
| |
| |
| |
| | |
Add `KeyMgr` accessor to `TorClient`
See merge request tpo/core/arti!3442
|
| | | |
|
| | |
| |
| |
| |
| | |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
arti/arti-client/tor-hsservice: Support disabling onion services in the config
Closes #2133
See merge request tpo/core/arti!3253
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There is no longer a hard error anywhere for trying to launch a service
which is disabled in the config. Instead, it always means returning
`Ok(None)`.
The axum and hyper examples were updated again as a consequence.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a service is disabled in the config, `arti::onion_proxy::Proxy`
handles it gracefully, and
`arti_client::client::TorClient::launch_onion_service_with_hsid` and
`arti_client::client::TorClient::launch_onion_service` both hard error.
The axum and hyper examples were updated again as a consequence.
Signed-off-by: hashcatHitman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Hidden services disabled in the config are now handled more gracefully
by arti/arti-client, before the hard error occurs.
The axum and hyper examples were updated as a consequence.
Signed-off-by: hashcatHitman <[email protected]>
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
`arti-client`: Move `create_onion_service()` to `InertTorClient`
See merge request tpo/core/arti!3435
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | |/
| |/|
| | |
| | | |
Part of #2118.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Run maint/add_warning
|
| | | | |
|
| |/ / |
|
| |/ |
|
| |
|
|
|
| |
I've added these in places that are useful for the debugging that I've
been doing.
|
| | |
|
| |
|
|
|
|
| |
changes in !2506
Signed-off-by: Aiden McClelland <[email protected]>
|