| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| |/ / / |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This finally makes this type suitable for parsing in config files.
|
| | | |
| | |
| | |
| | | |
Display can now choose appropriate units.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
The serde ones are going to need to be conditional.
|
| | | |
| | |
| | |
| | | |
Code motion of byte_qty.rs, and minimal necessary supporting changes.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
We're going to make this into a proper public type.
It's going to move into a different crate, where there's no prelude,
so give it a bespoke set of imports too.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Code motion, part 1.
Also explain in comments at the top of the new module why we are doing
this at all rather than using an existing thing.
|
| | |/
|/|
| |
| |
| |
| | |
This makes more sense than having them alphabetical.
Noticed while I was working on moving other code.
|
| |\ \
| |/
|/|
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
Fixes compilation with
cargo test --no-default-features -p arti --features=tokio,rustls
|
| | |
| |
| |
| | |
Otherwise it doesn't compile when actually used.
|
| | |
| |
| |
| | |
Placates clippy.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Disabling until #1549 is fixed to unblock CI.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
tor-hsservice: Add watcher for restricted_discovery config changes
Closes #1505
See merge request tpo/core/arti!2353
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The watch channel should help prevent flakiness in the tests
(`TestModule` uses `maybe_send` to only send the received config if it's
different from the previously received value. This is supposed to
prevent the tests from failing when duplicate update events are
received).
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Sometimes it's useful to know what files/directories are being watched.
For example, the descriptor publisher needs to know in order to figure
out if it needs to update the watcher in response to changes in the
config.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This also fixes a couple of issues with the previous implementation:
* it enables you to watch for more than just one file/extension per
directory (each directory now has a list of filters. If any of the
filters apply to the path contained in the notify::Event, the
`FilterWatcher` notifies the listeners
* it removes the list watched files from `FileWatcher`. This makes
things a lot simpler to grok: essentially, the file watcher only
ever watches directories, notifying if an "interesting" file was
changed (in our case, the interesting files are files that have a
relevant extension, such as `.auth`, or specific configuration
files, as specified by `ConfigurationSources`).
|
| | | |
| | |
| | |
| | |
| | | |
This will soon grow more complex, so I am preemptively moving it out of
`start_watching`.
|