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.
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.
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`.
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.
This explanation is slightly complicated by the fact that I think
that one of the calls to update_guardset_internal() is possibly
unnecessary, and that one of the calls that it makes is potentially
ill-advised.
I'm not going to make those changes right now, however, because they
are potentially a little destabilizing.
Now it is an Option, and is set to None if bridges aren't enabled.
This simplifies `replace_bridge_config` a bit, and forces us to
check for `None` in a few more places.
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).
The `GuardMgr` code has functionality to tell the DirMgr "Hey,
don't switch to the new NetDir yet: we still need more guard
information!" But we never want to do that if we're selecting
bridges, since they don't come from the NetDir.
Instead of duplicating the logic about which guard sample uses which
universe, we explicitly ask it, and then use that universe. This
will avoid trouble if/when we introduce more samples.
I'm using an Arc<[]> here though I think that there's a chance
that a simple Vec<> would suffice. Since it's an internal type,
nothing will break if we change it later.
Also, we now switch into and out of the Bridges guard sample
as needed. However, that selection is not (yet) built from the
list of bridges. That will come soon.
The first part changes which guard set is active based on based on
the parameters, which always come from a NetDir; the second changes
the contents of the active guard set, based on a Universe.
These arguments were used only for legacy (testing) purposes; the
tests now use `TestNetDirProvider`. This lets us simplify our
internal logic for passing a `NetDir` to our samples, and prepare
for having a `BridgeSet` to pass there instead.
This is a breaking change to `guardmgr` and `circmgr`.
0.99.[012] have a bug https://github.com/JelteF/derive_more/issues/114
which makes the Deref derive for bridgedesc::StateGuard not work
and therefore breaks minimal-versions CI.
It seems simpler to require the newer version everywhere.
Previously we always set `dir_info_missing` to `false` for new
guards, since new guards could only be taken from ones that were
present in the NetDir. But for bridges, we don't download their
info until _after_ we have chosen them as guards.
In this and the upcoming commits I'll be changing how guards related
to `NetDir` and to `Relay`. Previously, a guard could only come
from (or be updated from) a `Relay` in a `NetDir`. Soon it will be
able to be built from a bridge as well.
To do this, I'm defining a `Universe` trait (name negotiable) that
represents a set of things that may be guards. I'm going to
continue extending its functionality until there are no more
methods in guard.rs or sample.rs that take `NetDir`.
This commit removes most of the usage of `NetDir` and `Relay` in
`guard.rs`.
This is necessary for the (somewhat undesirable) lookup_ids function
to return an ID that the dirmgr can actually use to report successes
and failures.
As noted, lookup_ids will create problems down the road when we
implement relays. We should refactor it out before then.
This required a number of changes, which I've tried to document.
I've taken a conservative approach to modification, and I'm not
using any of the by_*_mut() functions (yet). For cases which
potentially modify the whole set, I'm using into_values() and
collect() to ensure that it's re-indexed correctly, even though the
identities don't change.
I introduce some "TODO pt-client" comments here which I will resolve
in the next commit(s).
Now it contains either an `OwnedChanTarget` or an `OwnedCircTarget`,
which will let `GuardMgr` return bridges that can be used to make
circuits.
As part of this change, it was necessary to revise some
address-modification functions that applied to filters and
`OwnedChanTarget`. Now they do the smart thing, and remove only the
address that are in the `ChanMethod`. This means that the addresses
from HasAddrs are still accurate about which addresses the relay
"has".
The most important part of this commit is to make sure that each
`FirstHopId` includes the `GuardSetSelector` from which the guard
was selected. Doing this lets us be certain that when we report
that a guard has succeeded or failed, we're reporting it in the
right context.
Additionally, this commit uses strum to make an iterator over the
samples, so that we can make sure that our "for each sample" code is
robust against future changes, and we don't miss the bridge sample.
Now keyed by Arc<BridgeConfig>, and the values can be errors.
Currently there is no implementation so there can't be any errors,
but the error enum will become nonempty.
The feature we want is `#[doc = include_str!("README.md")]`, which is
stable since 1.54 and our MSRV is now 1.56.
This commit is precisely the result of the following Perl rune:
perl -i~ -0777 -pe 's{(^//!(?!.*\@\@).*\n)+}{#![doc = include_str!("../README.md")]\n}m' crates/*/src/lib.rs
HasAddr used to mean "Here are addresses that I have, at which I can
be contacted." But "Where (and how) can I be contacted?" is now a
question for HasChannelMethod to answer.
(We still need to have "HasAddr", though, so we can answer things
like "what country is this relay in" and "are these relays in the
same /8?")
So this commit introduces:
* A new trait for adding an implementation of HasChannelMethod in
terms of HasAddr.
* A requirement on ChanTarget that it needs to implement
HasChannelMethod.
There is some temporary breakage here, marked with "TODO pt-client",
that I'll fix later in this branch.
Also add a BridgeRelayWithDesc type (name tbd) to guarantee that
a bridge relay really does have a known descriptor before you
try to build a circuit with it.
This is the one we'll actually use to connect to bridges. It
has a `Bridge` line, and an optional `BridgeDesc`.
Maybe this will turn into a `BridgeRelay<'a>` by analogy to `Relay`
some time; I'm not sure.
BridgeDesc is a separate type to make sure that we do not confuse
bridges' descriptors with the descriptors from other routers down
the road. (Bridges' descriptors need to be used differently, and
treated as more private.)
With this code, BridgerDescList is now just an alias for
`ByRelayIds<BridgeDesc>`, which is pretty keen.
Nightly rust gives a warning about this "pub use", but the warning
is a false positive. Since it doesn't seem to be going away in a
hurry, let's suppress it for now.
Include the offending word in all the applicable errors.
Always print it with {word:?}.
As a consequence, there are no From impls any more and error
generation/conversion is by hand in all cases.
Clarify InvalidPtOrAddr vs InvalidIAddrorPt, and don't make the
attempted parse be a source error for those.
Where we still have source errors, don't print them in Display.
(Since the APIs for the `Schedule::sleep*` functions changed, this
is a breaking change in tor-rtcompat. Therefore, the Runtime trait
in tor-rtcompat is now a different trait. Therefore, anything that
uses the Runtime trait in its APIs has also broken.)
This covers only the most basic notions of working with bridges:
that we need a separate set of guards, and that they have to
come from the list of known bridges.
Because we want to work more on ensuring that our semver stability
story is solid, we are _not_ bumping arti-client to 1.0.0 right now.
Here are the bumps we _are_ doing. Crates with "minor" bumps have
had API breaks; crates with "patch" bumps have had new APIs added.
Note that `tor-congestion` is not bumped here: it's a new crate, and
hasn't been published before.
```
tor-basic-utils minor
fs-mistrust minor
tor-config minor
tor-rtcompat minor
tor-rtmock minor
tor-llcrypto patch
tor-bytes patch
tor-linkspec minor
tor-cell minor
tor-proto minor
tor-netdoc patch
tor-netdir minor
tor-persist patch
tor-chanmgr minor
tor-guardmgr minor
tor-circmgr minor
tor-dirmgr minor
arti-client minor
arti-hyper minor
arti major
arti-bench minor
arti-testing minor
```
With this change, each individual identity type becomes optional.
The functions that expose them unconditionally are now in a "legacy"
trait that only some downstream types are expected to implement.
There are new convenience APIs in HasRelayIds:
* to return Option<&keytype>,
* to see if one identity-set contains another.
This commit will break several downstream crates! For the
reviewer's convenience, I will put the fixes for those crates into a
series of squash! commits on this one.
tor-netdir
----------
Revise tor-netdir to accept optional identities. This required some
caveats and workarounds about the cases where we have to deal with a
key type that the tor-netdir code does not currently recognize at
all. If we start to add more identity types in the future, we may
well want more internal indices in this code.
tor-proto
---------
In order to make tor-proto support optional identities, there were
fewer changes than I thought. Some "check" functions needed to start
looking at "all the ids we want" rather than at "the two known IDs";
they also needed to accommodate that case where we don't have an ID
that we demand.
This change will also help with bridges, since we want to be able to
connect to a bridge without knowing all of its IDs up front.
The protocol currently _requires_ the two current ID types in some
places. To deal with that, I added a new `MissingId` error.
I also removed a couple of unconditional identity accessors for
chanmgr; code should use `target().identity(...)` instead.
tor-chanmgr
-----------
This is an incomplete conversion: it does not at all handle channel
targets without Ed25519 identities yet. It still uses those
identities to index its internal map from identity to channel; but
it gives a new `MissingId` error type if it's given a channel target
that doesn't have one.
We'll want to revise the map type again down the road when we
implement bridges, but I'd rather not step on the channel-padding
work in progress right now.
tor-guardmgr
------------
This change is mostly a matter of constructing owned identity types
more sensibly, rather than unwrapping them directly.
There are some places marked with TODOs where we still depend on
particular identity types, because of how the directory protocol
works. This will need revisiting when we add bridge support here.
tor-circmgr
-----------
These changes are just relatively simple API changes in the tests.