| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This is the preferred type for choosing a relay,
since unlike a RelayExclusion, it lets us add multiple restrictions,
and a relay usage.
|
| |
|
|
| |
- Several methods have been moved out of SliceRandom.
|
| |
|
|
| |
- `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
|
| |
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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).
|
| |
|
|
| |
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.
|
| |
|
|
| |
None of these should be unused anymore.
|
| |
|
|
|
|
|
|
| |
The VanguardMgr now unconditionally flushes the vanguard sets to disk
each time there's a consensus change, and every time a vanguard
expires.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2090#note_3021013
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2090#note_3021016
|
| |
|
|
|
| |
Our log messages begin with an uppercase letter in the rest of the code
base.
|
| | |
|
| |
|
|
| |
This will be useful for testing.
|
| |
|
|
|
|
| |
This doesn't need to be `pub(super)` anymore, `VanguardMgr` now
manipulates the `VanguardSets` exclusively through
`VanguardSetsTrackedMut`.
|
| |
|
|
|
|
| |
A lot of this is code motion: the code added to `VanguardSetsTrackedMut`
was copied from the `VanguardMgr` impl, so I recommend reviewing this
with `git diff --color-moved=zebra`.
|
| |
|
|
|
|
|
|
|
| |
This enables us to track when `VanguardMgr`'s `VanguardSets` is
*actually* mutated.
This will soon be useful because we only want to flush the
`VanguardSets` to storage if we actually added or removed some relays
from the set.
|
| |
|
|
|
| |
These will be useful later, when we place the `l2_vanguards` and
`l3_vanguards` from `VanguardMgr` with a `VanguardSets`.
|
| |
|
|
|
|
|
|
|
| |
changed.
The two removal functions now return whether any values were removed
from the `VanguardSet`. Their return values are currently ignored, but
will soon be used for deciding whether to flush the `VanguardSet`s to
disk (if full vanguards are enabled).
|
| |
|
|
|
|
|
| |
`VanguardSets` (not to be confused with `VanguardSet`) will soon be used
as:
* a helper for serializing the L2 and L3 `VanguardSet`s
* an abstraction over the two vanguard sets
|
| |
|
|
|
|
|
|
|
|
| |
We will soon replace `VanguardSet::new` with `VanguardSet::default`:
`new()` currently expects a set of `VanguardParams` (from which the
target size of the set is derived), but we don't have a `VanguardParams`
until we obtain a `NetDir`. Moreover, it doesn't make sense to attempt
to set the target size of the `VanguardSet` before obtaining a `NetDir`,
because we can't actually populate the set without a `NetDir` (we can't
select relays).
|
| | |
|
| |
|
|
|
| |
This is no longer true because of !2082. The `VanguardSet` *does* own
its `TimeBoundVanguards`.
|
| |
|
|
| |
These are not used anymore as of !2082, so we can remove them now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2075#note_3016306
using a heap isn't the best way to manage the vanguards:
* in the default case, which will apply to most users, the L2 and L3 set
sizes are 4 and 8 respectively. Using a heap doesn't make sense for
such small sets
* the use of `Weak<TimeBoundVanguard>`s will be an inconvenience later
on, when we implement vanguard set persistence, since `Weak` isn't
serializable or deserializable
This switches to a simpler apporach, where the `VanguardMgr` computes
the soonest expiration timestamp of its `VanguardSet`s by iterating
over all the vanguards in each set.
Closes #1366
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #1340
|
| | |
|
| | |
|
| |
|
|
|
| |
The target is the number of vanguards the `VanguardMgr`s will try to
maintain in the `VanguardSet`.
|
| |
|
|
|
| |
This function will need to randomly select a vanguard, so it needs an
`Rng`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This enables us to prevent the same relay from being picked in
consecutive positions in a path.
Part of #1340
|
| | |
|
| | |
|
| | |
|
|
|
Part of #1275
|
