| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
We want to require that whenever we generate a key that's persistent
(stored in KeyMgr), it's going to be made from a stronger-than-usual
Rng. This trait helps us enforce that.
We also add a FakeEntropicRng struct to use for testing.
Note that this turned up a case that we'd missed, which required
an internal change in tor-hsservice.
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| |
|
|
| |
rustfmt.
|
| |
|
|
|
|
|
|
|
|
| |
We're going to distinguish top-level runtime entry, from *re*-entry to
an existing executor. It is most convenient to rename this trait
first. Documentation of the distinction will come later.
(We're going to retain the function name `block_on`, but we want the trait
to be more obviously a top-level only thing, though, so we give it a
name that will hopefully avoid it peroulating throughout the codebase..)
|
| |
|
|
|
| |
These helpers seem potentially broadly useful, and only really
discoverable if they're here.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a big change across multiple crates since there isn't a good way
to break it up.
This changes the signature of `CfgPath::path` to:
```
pub fn path(&self, path_resolver: &CfgPathResolver) -> Result<PathBuf, CfgPathError> {
```
Making this change means that our global `CfgPathResolver` needs to be
stored in the 'arti-client' library instead of `tor-config-path`, and
must be passed through to anything that calls `path` to expand the
variables.
|
| | |
|
| |
|
|
|
| |
Also updated other packages to get `CfgPath` directly from
`tor-config-path' instead of 'tor-config'.
|
| |
|
|
|
| |
These are the call sites where using this fucntion is correct.
(Outside tor-rtmock, which we'll do separately.)
|
| |
|
|
| |
As mentioned in #727, this is not supported yet.
|
| |\
| |
| |
| |
| |
| |
| | |
Bug 1613: Add support for inserting externally generated and removing arbitrary service discovery keys
Closes #1613
See merge request tpo/core/arti!2396
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
tor-hsservice: Improve descriptor publisher status reporting
Closes #1216 and #1572
See merge request tpo/core/arti!2397
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We will need to return a list of descriptor upload errors.
We can't return a `Vec<RetryError<DescUploadError>>` here because
`DescUploadError` is a lower-level error type that can't express that
e.g. the upload timed out.
|
| | | |
|
| | |
| |
| |
| |
| | |
We never return `UploadError::Timeout` (timeouts are represented as
`BackoffError::Timeout`).
|
| | |
| |
| |
| | |
This type is a `Result`, renaming for clarity.
|
| | |
| |
| |
| | |
Closes #1216
|
| | |
| |
| |
| |
| | |
This makes it clearer that some of these functions are essentially
infallible.
|
| | | |
|
| | |
| |
| |
| |
| | |
This enables us to report a "broken" service status if restricted
discovery is enabled but the authorized_clients list is empty.
|
| | |
| |
| |
| | |
Closes #1572
|
| | |
| |
| |
| |
| |
| | |
This will allows us determine the ComponentStatus of the publisher
(it'll be either `Running` or `Degraded`, depending on whether the
upload failed).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After uploading the descriptor, the publisher transitions into the
`Idle` state. This transition happens even if the upload was
unsuccessful, so it shouldn't cause the onion service status to become
`Running` (because `Running` implies the service is fully reachable, and
if the publisher failed to upload the descriptor to some or all HsDirs,
that won't necessarily be the case).
A future commit will set the publisher's onion svc `State` to
`Running`/`Recovering`/`Broken` according to the upload status.
|
| | | |
|
| | |
| |
| |
| | |
This resolves a TODO.
|
| | |
| |
| |
| |
| |
| | |
Previously, these were stored in the immutable state behind a mutex, but
since they're not really immutable (we update them if the config
changes), it makes more sense to put them in `State`.
|
| | |
| |
| |
| |
| |
| | |
This TODO was added in !2353 and was supposed to be about reporting a
broken/degraded onion service status if the restricted discovery config
watcher fails.
|
| |/
|
|
|
|
|
|
|
|
| |
There are three places where we query the KeyMgr for an `HsIdKeypair` but all
we really need is the public part. This commit changes those three callsites
to instead use `get::<HsIdKey>`.
This relies on the previous commit, which makes sure that a request for an
`HsIdKey` will always succeed if the keystore has a `HsIdKeypair` with the
same service nickname.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| |
|
|
|
|
|
| |
This ensures that if a directory used as a `key_dir` is moved (e.g.
renamed), and then moved back to its original location (the one
specified in `key_dirs`), our watcher continues watching the `key_dirs`
contents.
|
| |
|
|
| |
`FileWatcher::watch_file` can be used with arbitrary paths.
|
| |
|
|
|
| |
This ensures that if a `key_dir` is created after we start watching it
(or if it's moved), we are still able to detect changes.
|
| |
|
|
|
|
| |
While this means we will be recreating the watcher slightly more often
than necessary, this new approach is less error-prone than what we had
before.
|
| | |
|
| |
|
|
|
| |
This is a general issue with the publisher that will need to be
addressed soon.
|
| |
|
|
| |
changes.
|
| |
|
|
|
| |
This `FileWatcher` is watching the `restricted_discovery.key_dirs`
directories for changes.
|
| |
|
|
| |
contents change.
|
| |
|
|
|
| |
This will soon be used in the `key_dirs` change handler, which will
re-read the authorized_clients list.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, the publisher would always publish a new descriptor if the
config changed. Now, it only republishes if the parts of the config that
changed are relevant (i.e. if they are part of
`OnionServiceConfigPublisherView`).
A future change will make it so that we trigger a republish task
whenever the restricted discovery mode authorized clients change. This
will involve looking at the contents of the configured `key_dirs`, as
well as the `OnionServiceConfigPublisherView`.
|
| |
|
|
| |
This resolves a clippy warning.
|
| |
|
|
|
| |
Resolves the TODO prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1603#note_2944902
|
| |
|
|
| |
Knowing the nicknames can be useful when debugging.
|
| | |
|