| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If we have a bridge guard that is using Direct connection and it
knows multiple addresses, our code to match it with a BridgeConfig
is wrong, because the BridgeConfig has only one address, and our
code looks for an exact match.
Fixes #642.
|
| | | | |
|
| |\ \ \
| |/ /
|/| /
| |/
| | |
arti cfg test: Add more documentation
See merge request tpo/core/arti!856
|
| | | |
|
| | |
| |
| |
| | |
Giving this a name will allow us to refer to it docs in a moment.
|
| | |
| |
| |
| |
| | |
This allow is also present in the standard lint block at the start of
the test inline module.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
netdoc: Allow empty lines at the end of router descriptors
Closes #637
See merge request tpo/core/arti!857
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Empty lines were previously reported as BadKeyword, which is
confusing.
|
| |/ /
| |
| |
| |
| |
| | |
Without this fix, any attempt to actually use a circuit for a
`DirSpecificTarget` will fail, since supports() will say false, and
`restrict_mut()` will say `NotSupported`.
|
| | | |
|
| |/
|
|
| |
Fixes #636.
|
| | |
|
| |
|
|
| |
rustfmt only.
|
| |
|
|
| |
We'll need this shortly.
|
| |
|
|
| |
We'll need this shortly.
|
| |\
| |
| |
| |
| | |
Bugfix: preserve active_set when loading guards
See merge request tpo/core/arti!848
|
| | | |
|
| |\|
| |
| |
| |
| |
| |
| | |
GuardMgr: Update desired bridge descs from 'update' function.
Closes #622
See merge request tpo/core/arti!847
|
| | |
| |
| |
| |
| | |
There are some new TODOs here for us to think about, but I think
this will give us something to test.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Move guardmgr creation to arti-client, rather than within circmgr
See merge request tpo/core/arti!850
|
| | | |
| | |
| | |
| | | |
rustfmt only, broken out to ease review.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Having this done within circmgr was irregular - most of our other key
buildup functions are done in TorClient::create_inner.
It is also inconvenient, as it buries the guardmgr within the circmgr.
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
dirmgr: Expopse DirMgrStore
See merge request tpo/core/arti!851
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now the Store is constructed by arti_client, solving the problem
described here
https://gitlab.torproject.org/tpo/core/arti/-/issues/631#note_2853665
but in a different way.
|
| | | | |
| | | |
| | | |
| | | | |
rustfmt only, broken out to ease review.
|
| | | | |
| | | |
| | | |
| | | | |
We are going to change DirMgr's constructors to also take a DirMgrStore.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
This will allow us to get rid of a needless trait impl.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This seems tidier to me.
(It saved a lot of typing when I was trying to make some complicated
pub supertrait with sealed private supertrait, but apparently not
now.)
|
| |\| |
| | |
| | |
| | |
| | | |
bridge descriptor dormancy: Define an enum and semantics
See merge request tpo/core/arti!845
|
| | | |
| | |
| | |
| | | |
But right now, don't do anything with it. That will come in a future MR.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This is part of #630.
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Temporarily disable it_cancels_delayed_firings.
See merge request tpo/core/arti!846
|
| | |/
| |
| |
| |
| | |
This test is timing-dependent in a way that seems to fail on heavily
loaded CI machines. See #545.
|
| |\ \
| | |
| | |
| | |
| | | |
Resolve most "TODO pt-client" comments in GuardMgr
See merge request tpo/core/arti!840
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is the only way I could find in which parameter interpretation
differs between bridge guards and relay guards; with it documented,
I can remove a TODO about identifying such ways.
|
| | | |
| | |
| | |
| | |
| | | |
Have the check only apply to non-bridge universes, and explain why
in a bunch more comments.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously we would call extend_sample_as_needed in only two places,
one of which called the other unconditionally. That's obviously not
necessary.
I've selected just one of them (`update_guardset_internal`) since it
fits better with the theme if that function. I've added comments
explaining what is going on.
This commit also introduces a yes/no enum for "were any guards added
while extending this set". Formerly we had a boolean, but it got
passed around so many times that I think its intent became obscure.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
What this function actually does is return the number of primary
guards whose presence (by identity) is ambiguous in a current
universe. The new name and documentation should help avoid
confusion.
The method's old name had led me astray when identifying whether it
should apply to bridges in one case. This commit also removes the
corresponding `TODO pt-client`.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
The code seems happy enough here for now.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also, add a bunch of reminders around these implementations that
`HasAddrs` returns all the address associated with you for GeoIp or
family purposes, even if they are _not_ ones that we should actually
contact you at.
|