| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
`VanguardParams` already contains the `vanguards_enabled` and
`vanguards_hs_service` `VanguardMode` params.
We still intend to abolish `VanguardConfig` in favour of deriving the
`VanguardMode` from the consensus params (#1382), but this is not the
right place for such a TODO.
|
| |
|
|
| |
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).
|
| |
|
|
|
|
|
| |
By default, HS clients should be using lite vanguards, and HS services
full vanguards.
See https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/258#note_3011734
|
| | |
|
| |
|
|
| |
It was addressed in !2083
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
We have two vanguard modes, one for when arti is running as a client,
and a separate one for when it's running as a service.
Both modes are extracted from the `NetParameters`, so they belong in
`VanguardParams`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
| |
If the [min, max] lifetime interval for a vanguard layer is the empty
set (i.e. min > max), we return the default lifetime.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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`.
|
| | |
|
| | |
|
