| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| | |
These aren't dead code anymore, with the exception of
`PublisherStatusSender::send_recovering`, which isn't used.
|
| | |
| |
| |
| | |
This is already implemented.
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| | |
This commit adds a new method `get_keypair_specifier()` to `KeySpecifier`.
This method is used to indicate when one KeySpecifier (e.g. `KP_hs_id`) is the
public part of another keypair (e.g. `KS_hs_id`). It will return the
containing keypair in this case, and `None` otherwise.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
FooKeypairSpecifier` instances
This adds the following trivial `From` instances:
- tor_hsservice: impl From<&HsIdPublicKeySpecifier> for HsIdKeypairSpecifier
- tor_hsservice: impl From<&BlindIdPublicKeySpecifier> for BlindIdKeypairSpecifier
- tor_hscrypto::pk: impl From<HsBlindIdKeypair> for HsBlindIdKey
- tor_llcrypto::pk::ed25519: impl From<ExpandedKeypair> for PublicKey
- tor_keymgr::mgr: impl From<TestKey> for TestPublicKey
- tor::hscrypto::pk: impl From<HsIdKeypair> for HsIdKey
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Everything copied in the previous commits to tor-keys is now removed and
tor-keys crate is used accross the code.
Minor changes to tor-keys to accomodate this change.
Part of #1137
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
The 1.2.7 release is out so we won't be needing these anymore.
|
| |
|
|
|
|
|
|
|
|
| |
Done using:
```
for crate in $(./maint/list_crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.22.0
done
```
|
| |
|
|
| |
This is the first time we're publishing this, so let's start at 0.1.0.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
Run tests of every crate, with all features disabled
See merge request tpo/core/arti!2350
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We can't do this for every crate.
I looked at what is now matrix-check to see if I wanted to use any of
the code. But it seems too entangled with its particular purpose, and
has a lot of embedded knowledge of our crates' features. I found it
sufficiently far from what I wanted that I decided on a fresh script.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This is now implemented.
|
| | |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
We need to know if `watch_configuration` is set in the descriptor
publisher reactor to know whether we should be watching the
`restricted_discovery.key_dirs` directories.
|
| | | |
|
| | |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| | |
Partially addresses
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1603#note_2944902
|
| | |
| |
| |
| | |
Knowing the nicknames can be useful when debugging.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nightly rust doesn't like it when you have a `match` arm that can
never be reached because of an uninhabited type. As such,
we can't say stuff like:
```
let x: Option<Void> = ...;
match x {
Some(_) => unreachable!(),
None => ...
}
```
|
| | |
|
| |
|
|
|
|
| |
We now create the authorized_clients in the publisher (we don't need the
authorized_clients anywhere else, so it makes little sense to keep them
in `RunningOnionService`).
|
| |
|
|
|
| |
The module is correctly documented as "only available on crate feature
restricted-discovery" without it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Without it, if the `restricted-discovery` feature is compiled out, the
module gets documented as:
```
Non-restricted-discovery (Available on non-crate feature `restricted-discovery`
only)
```
which is inaccurate.
|
| |
|
|
| |
This helped me debug some shadow test failures.
|
| | |
|
| | |
|
| | |
|
| | |
|
