| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |/
|
|
| |
And explain what this all means.
|
| |\
| |
| |
| |
| | |
Allow GuardMgr to expose bridges as guards (part 1)
See merge request tpo/core/arti!785
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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".
|
| | |
| |
| |
| | |
This resolves an old TODO, and will simplify our work a little.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| | |
Use BridgeConfig to identify bridges in two places
See merge request tpo/core/arti!781
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Abolish maint/readme and use doc include
Closes #603
See merge request tpo/core/arti!768
|
| | |
| |
| |
| |
| |
| |
| | |
Apparently cargo fmt doesn't like these, which my perl rune didn't
delete.
This commit is precisely the result of `cargo fmt`.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| | |
Fixes #599
|
| |/ |
|
| |
|
|
|
| |
Callers could `use` it as `tor_guardmgr::config::BridgeParseError` but
it seems unecessary to force them to.
|
| |
|
|
|
|
|
| |
This lint exists for perf reasons, and this is rarely relevant in
tests.
Using double quoted str is generally cognitively less burdensome.
|
| |
|
|
|
|
|
| |
Now each `ChanTarget` has at most one `ChannelMethod`, and only
`Direct` `ChannelMethods` can have multiple addresses.
Closes #600.
|
| | |
|
| |
|
|
| |
These are now builders.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
Start implementing more data structures to hold Bridge descriptors.
See merge request tpo/core/arti!755
|
| | | |
|
| | |
| |
| |
| | |
See comment for an explanation of the next issue here.
|
| | |
| |
| |
| |
| |
| | |
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.
|
| |\
| |
| |
| |
| | |
Parse (and format) bridge lines
See merge request tpo/core/arti!745
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
This is not perfect but it at least ensures that our own parsing and
printing code works correctly with all the values we accept.
|
| | |
| |
| |
| |
| |
| | |
It has its own error type PtTargetInvalidSetting.
In check_doc_features, adjust suppression to new code.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
guardmgr needs to know how to parse Bridge lines into Bridge structs
so it needs to know about PTs specifically
|
| | |
| |
| |
| | |
I wanted this for testing. I think it's reasonable to promise this.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
(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.)
|
| |/ |
|
| |
|
|
|
|
| |
Also, document the features.
Closes #588.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
This type goes in tor-guardmgr, since that's where decisions about
circuits' first hops are made.
There are a lot of "todo"s here for us to resolve.
|
| | |
|