| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
| |
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 p in `cat ../u`; do cargo set-version --locked --offline -p $p; done
where u contains
tor-basic-utils
tor-async-utils
tor-error
tor-config
tor-units
tor-geoip
tor-rtcompat
tor-rtmock
tor-log-ratelim
tor-rpcbase
tor-memquota
tor-llcrypto
tor-protover
tor-bytes
tor-hscrypto
tor-socksproto
tor-checkable
tor-cert
tor-linkspec
tor-cell
tor-proto
tor-netdoc
tor-consdiff
tor-netdir
tor-relay-selection
tor-persist
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
tor-keymgr
tor-hsclient
tor-hsservice
tor-hsrproxy
arti-client
arti-rpcserver
arti-hyper
|
| |
|
|
| |
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.
|
| |
|
|
| |
This makes the vanguards feature non-experimental.
|
| | |
|
| |
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
`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.
|
| |
|
|
| |
The referenced types are no longer available in `vanguards.rs`.
|
| | |
|
| |
|
|
| |
We will soon use this to test full vanguards.
|
| |
|
|
|
|
| |
This doesn't need to be `pub(super)` anymore, `VanguardMgr` now
manipulates the `VanguardSets` exclusively through
`VanguardSetsTrackedMut`.
|
| |
|
|
|
|
| |
The `VanguardMgr` reads the vanguards from the vanguards state file,
whether full vanguards are enabled or not. It only persists the vanguard
sets to storage if full vanguards are in use.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since `rotate_expired()` (previously `remove_expired()`) now also
replenishes the vanguard sets, we can't use `advance_until_stalled()`
anymore, because `run_once()` is never be stalled in the tests
(`next_to_expire` is never `None`, so `sleep_fut` is never
`future::pending()`:
```
warning: MockRuntime advance_* looped >1000 (next sleep: 877560507ms)
```
Previously, `next_to_expire` was computed *before* replenishing the
vanguard sets, which is why the tests could use
`advance_until_stalled()`.
|
| |
|
|
|
| |
This addresses a TODO about not calling `handle_netdir_update`
unconditionally each time `VanguardMgr::run_once()` runs.
|
| |
|
|
|
|
| |
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
|
