| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
See #2060.
|
| |
|
|
|
|
| |
This is the preferred type for choosing a relay,
since unlike a RelayExclusion, it lets us add multiple restrictions,
and a relay usage.
|
| | |
|
| |
|
|
|
| |
Now that our MSRV is 1.83, clippy is happy to make more
recommendations for us.
|
| | |
|
| |
|
|
| |
- The Rng::gen() functions have been renamed to Rng::random().
|
| |
|
|
| |
- Several methods have been moved out of SliceRandom.
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| |
|
|
|
| |
This will affect some details of path selection as we provide more
info about families.
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
|
|
| |
Now
cargo check --workspace --no-default-features --all-targets
cargo build -p arti --no-default-features --features=memquota,tokio,native-tls
are both clean.
|
| |
|
|
|
|
| |
The `derive_more` crate broke backward compatibility with this version,
so this change involved quite a few manual fixups.
With luck, they'll keep compatibility for some while in the future.
|
| |
|
|
|
|
|
|
|
| |
This behavior is OK, so this doesn't need to be a TODO.
See the discussion at
https://gitlab.torproject.org/tpo/core/arti/-/issues/1352#note_3015217
Closes #1352
|
| |
|
|
|
| |
This allows us to set SRVs for example (needed because by default, the
test `NetDir` is built from a consensus that doesn't contain any SRVs).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
We will soon need these helpers outside of `tor-guardmgr` too.
This commit is mainly code motion.
|
| |
|
|
| |
This checks that we can read `vanguards.json` state files.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This is a safeguard to prevent users from using ExplicitOrAuto with
types that serialize to the same value as ExplicitOrAuto::Auto.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2146#note_3030692
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We want to export the `VanguardConfig` even if the `vanguards` feature
is disabled (we will need to unconditionally include it in the arti
config).
Note that if `vanguards` are disabled, the `VanguardMode` from the
`VanguardConfig` can only be `Dsiabled`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Previously, `select_vanguard` returned a `NoSuitableRelay` error if
it was unable to select a relay to use as a vanguard.
We now distunguish the "there are no suitable relays in the vanguard
sets" (`NoSuitableRelays`) error case from the "our vanguard sets are
empty" (`BootstrapRequired`) one.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is about to grow another variant, so I'm moving it to a dedicated
`err` module.
|
| |
|
|
|
|
| |
The `match` below it is fine, there's no need to rewrite it.
(I think this TODO is actually dupe of the the TODO above it).
|
| |
|
|
|
| |
I think it's alright to keep it: it gives us the flexibility to extend
it later on, if needed.
|
| | |
|
| |
|
|
|
|
| |
This TODO doesn't really need to be implemented: we can test the
`VanguardMgr` just the same without it (`GuardMgrInner` is similar, in
that it doesn't mock the rng).
|
| | |
|
| |
|
|
| |
This commit is automatically generated.
|
| |
|
|
|
| |
(In most cases, by writing the documentation;
in tests, by permitting the documentation to be missing.)
|
| |
|
|
| |
For symmetry with remove_expired.
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2109#note_3024672
|
| |
|
|
|
| |
`rotate_expired()` now only logs that it is rotating the vanguards if
some existing vanguards have actually expired.
|
| |
|
|
|
| |
We flush every time the vanguards may have changed, but we don't know
for sure if they did.
|
| | |
|
| |
|
|
|
| |
The tests need to be updated now that the `VanguardMode` is read from
the config rather than the consensus.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed on #tor-dev, I'm reintroducing `VanguardConfig` for now.
The `VanguardConfig` specifies what mode (full/lite/disabled) the
`VanguardMgr` should run in. We currently don't have a separate modes
for HS clients and HS services.
We shouldn't actually *need* a `VanguardConfig` at all, so this is just
a (hopefully!) short- or medium-term fix until we sort out #1382 (which
might involve making breaking changes to our `reconfigure()` APIs).
Closes #1272
|