| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/904#note_2858480
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/904#note_2858479
|
| |
|
|
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/issues/668#note_2858220
This commit is difficult to split up.
The innards of BridgeAddr and PtTargetAddr are still a bit entangled.
|
| |\
| |
| |
| |
| | |
Add tests for a bunch of code in tor-linkspec
See merge request tpo/core/arti!867
|
| | | |
|
| | |
| |
| |
| | |
We've revised this a few times; now it seems plausible.
|
| |/
|
|
|
| |
This machinery is a bit inelegant, but it is all confined to
be within the GuardMgr crate, so IMO it should be fine for now.
|
| |\
| |
| |
| |
| | |
Make ChannelMethod non-exhaustive
See merge request tpo/core/arti!891
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Enums with variants conditional on cargo features must be
non-exhaustive, because cargo features are supposed to be additive,
meaning that enabling a feature (which might happen due to some random
distant thing) ought not to break things using that enum.
There were surprisingly few places to fix this.
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Require state ownership when using bridges
Closes #612
See merge request tpo/core/arti!889
|
| | |
| |
| |
| | |
Left unsquashed for ease of review
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
From Unsupported. Following one of the suggestions here
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/889#note_2856873
This was added in 2c3711614908d0c9cf1663b20b67a3fc233301f4 which was
not yet in a release so this isn't a semver break. I have added
the semver note that was omitted in that MR.
|
| | |
| |
| |
| | |
BridgeConfig is itself an Arc now, so these are redundant.
|
| | |
| |
| |
| |
| | |
This leaves the external API of this type unchanged, but now it's much
smaller and quite cheap to clone.
|
| |/
|
|
| |
This was done by !874 and #604 closed accordingly.
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #653
|
| |
|
|
| |
This will make the next commit textually smaller.
|
| |
|
|
|
| |
This type now does all the things people expect of it: you can (try
to) deserialize it, parse it from a string, and call build on it.
|
| |
|
|
|
|
|
| |
This leaves this enum empty of actual errors, when bridge-client is
disabled.
We're going to add the not supported variant in a moment.
|
| |
|
|
|
|
|
|
| |
The dummy module is going to need an error type just like this but
with only the disabled variant. To avoid that dummy enum getting out
of step with the nontrivial one, we're going to make them the same.
So as a first step, break this out into its own file.
|
| |
|
|
| |
And use it in bridge configuration parsing.
|
| | |
|
| |
|
|
|
| |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/874/diffs?commit_id=12d13428d8fcc68b7b0f231bac9fc130b3eeb18b#d53209cbcd12771c549f3a130379ecb65dd60145_100_193
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/874/diffs?commit_id=620cc90f6dcdad20f49a001a9e04d191a323e904#d53209cbcd12771c549f3a130379ecb65dd60145_100_124
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/874/diffs?commit_id=620cc90f6dcdad20f49a001a9e04d191a323e904#d53209cbcd12771c549f3a130379ecb65dd60145_100_121
|
| |
|
|
|
|
| |
That the *de*serialisation works as expected will be tested properly
in just a moment, because when we plumb this all the way through, it
will be what parses the bridge lines in the example config file.
|
| | |
|
| |
|
|
| |
And test cases for it, and its errors.
|
| |
|
|
|
|
|
|
|
|
|
| |
This struct is going to be the principal "dictionary-style" serde
representation for a bridge, and the builder, making this all in
keeping with our usual approach.
In this commit:
* Introduce the struct (defining the serialisation)
* Provide the setters (defining the Rust API)
* Add success test cases (not all of the data in which is used yet)
|
| |
|
|
|
| |
Here is where my motivation is and I'm working on this code now, so do
this renaming cleanup now.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
There are some new TODOs here for us to think about, but I think
this will give us something to test.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
The BridgeSet type does not necessarily need further changes... and
if it gets them, it won't be because of this comment.
|
| |\
| |
| |
| |
| |
| |
| | |
Persistently cache bridge descriptors
Closes #619
See merge request tpo/core/arti!831
|
| | |
| |
| |
| |
| |
| | |
This is more consistent with our naming elsewhere.
Suggested-by: Nick Mathewson <[email protected]>
|
| | |
| |
| |
| |
| | |
Also remove a bunch of now-unnecessary `allow(dead_code)`
annotations.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
We do this by checking the FirstHops we're about to return, and when
they correspond to bridges, looking up an appropriate BridgeRelay
in the current BridgeSet (if we can).
|
| | |
| |
| |
| |
| |
| | |
We already _have_ these Arc<>s whenever we construct a UniverseRef,
so there's no real point in using &refs and making these so
hard to construct.
|
| | |
| |
| |
| |
| |
| |
| | |
This will match our needs better and help avoid some `Arc<>`s.
It will be especially helpful for avoiding `Arc`s we don't
actually have.
|