| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| | |
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2370#note_3066621
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements the `TorClientThatIsntRunning` mentioned in !2314 (see also
`doc/dev/notes/keymgr-porcelain.md`), except `TorClientThatIsntRunning`
is called `InertTorClient`.
This commit is mostly code motion: I've moved the `create_keymgr`
function and the impls of `generate_service_discovery_key` and
`get_service_discovery_key` from `TorClient` to `InertTorClient`.
The `InertTorClient` advertises itself as a handle for accessing the
keystores and other persistent state, but it currently only has 2
functions (`generate_service_discovery_key` and
`get_service_discovery_key`). I expect it will grow additional
functionality in the future.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Name chosen to match the error kind that we're detecting.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a parameter to TorClientBuilder that control how long
we should retry constructing a TorClient if we get a
LocalResourceInUse error. When this parameter is not set, we
default to 500 milliseconds for async entry points and 0
milliseconds for sync entry points.
(`LocalResourceInUse` usually means that a lockfile is held by
somebody else; but when the resource is some other type, we
typically want the same behavior anyway.)
(I really don't want to introduce delays by default for the
create_unbootstrapped case, since it previously had no delay at
all.)
There is now also an async entry point to create an unbootstrapped
TorClient.
Closes #1464.
|
| |
|
|
|
| |
There is no actual reason to consume this type, and taking it by
reference allows us to retry.
|
| |
|
|
| |
Apply deferred clippy churn.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Doing this causes TorClientBuilder to become Send. I also add a
test to ensure that TorClientBuilder remains Send in the future.
This isn't a semver break, but only because DirProviderBuilder is
marked with `experimental-api`.
Closes #924
|
| |
|
|
|
|
|
| |
Now the Store is constructed by arti_client, solving the problem
described here
https://gitlab.torproject.org/tpo/core/arti/-/issues/631#note_2853665
but in a different way.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This logic can now be adjusted via the config object so that it does
its own overriding by looking at the environment as appropriate.
Removing these methods helps simplify the code a bit.
Enabled by #483.
|
| |
|
|
|
|
|
| |
The variable is now handled when building the configuration, and no
longer needs to be special-cased.
Closes #483.
|
| | |
|
| |
|
|
|
|
| |
This change requires a little refactoring of TorClientBuilder: now,
instead of enabling or disabling mistrust, it enables or disables
the decision to _override_ the mistrust in the config.
|
| |
|
|
|
| |
This is an approximately minimal revision to get Builder in place;
subsequent commits will clean up the API.
|
| |
|
|
|
|
|
|
|
|
| |
I'm doing this per discussion, so that we can have it be part of the
TorConfig later on, and not break stuff as we change the Mistrust
API to have a builder.
This change, unfortunately, results in a little more internal
complexity and duplicated code in arti and arti-client. I've marked
those points with TODOs.
|
| | |
|
| |
|
|
|
|
| |
This is derived from the environment, not the configuration file: We
might not want to trust the configuration file until we've decided
whether we like its permissions.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There are two reasons why the DynFilter newtype might be needed:
1. To impl Default. But we don't need it to impl Default since we can
have an accessor which does the defaulting.
2. To hide the API. But this is usrely an unstable API.
Just writing Arc<dyn> gets rid of a lot of unnecessary boilerplate and
conversion code.
|
| |
|
|
|
| |
Abolish the handwritten Debug impl for DynFilter, which is no longer
needed.
|
| |
|
|
|
| |
This will make it possible to implement a directory-munging
mechanism in arti-testing for #397.
|
| | |
|
| | |
|
| |
|
|
| |
Put it behind experimental_api.
|
| | |
|
|
|
This is a defensive API choice to protect against the possibility
that we'll want to add a bunch of other non-config options in
the future.
Closes #350
|
