| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| |
|
|
| |
The singleton variation here is almost never what we want.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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".
|
| | |
|
| |\
| |
| |
| |
| | |
serde support for PtTarget
See merge request tpo/core/arti!780
|
| | |
| |
| |
| | |
This will let us remember bridges that use pluggable transports.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `PtTarget` type and its contents (`TransportName`,
`PtTargetAddr`, `PtSettings`) are now unconditionally compiled and
exposed. This will allow us to serialize and deserialize them in
our guard-state files even when we have been built without explicit
PT support.
The `pt-client` feature controls whether `TransportName` is a
variant of `TransportId`, and whether `PtTarget` is a variant of
`ChanMethod`: this in turn means that we'll still have simpler
binary code and smaller structures when we're building without PT
support (which is what we wanted when we initially made these types
conditional).
|
| |\ \
| |/
|/|
| |
| | |
Use BridgeConfig to identify bridges in two places
See merge request tpo/core/arti!781
|
| | |
| |
| |
| |
| |
| | |
This lets us write functions which can either take an existing
owned OwnedChanTarget, or copy out of some other kind of ChanTarget
passed by reference.
|
| | | |
|
| |/
|
|
| |
Eg, a PT bridge may not have an address.
|
| | |
|
| |
|
|
|
| |
We need a function to remove an entry if it appears with _exactly_
the same relay Ids, but not otherwise. This method will do that.
|
| |
|
|
|
|
|
| |
Also, add a few tests for this and the other accessors.
We'll need this accessor to find whether we have any channels to
_any_ of the identities that we're trying to connect to.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
We need to handle String, not just str, since some deserializers
have to handle escapes and generate new strings.
Found while writing tests; fixes #605.
|
| | |
|
| |
|
|
|
|
| |
In addition to the usual "You named that method wrong!" errors, we
have a new rustdoc error that complains about bogus "HTML tags" that
are actually unquoted usage of types like `Result<Foo>`.
|
| |\
| |
| |
| |
| | |
chanmgr: Build and use chanmgr factory APIs
See merge request tpo/core/arti!769
|
| | |
| |
| |
| |
| |
| | |
* Get `TransportId`
* Get the target address (of any type)
* Ask, "is this a direct connection"?
|
| | |
| |
| |
| |
| |
| |
| | |
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
|
| |
|
|
|
| |
It looks like this got fixed, but my branch for !759 reintroduced it
by refactoring.
|
| |
|
|
|
|
|
| |
Now each `ChanTarget` has at most one `ChannelMethod`, and only
`Direct` `ChannelMethods` can have multiple addresses.
Closes #600.
|
| | |
|
| | |
|
| |
|
|
| |
All the other users of HasAddrs are correct.
|
| |
|
|
| |
These are now builders.
|
| | |
|
| |
|
|
|
| |
This will become the preferred way to make one of these objects, and
insulate us against future API changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This is based on the type generated with n_key_set, with a
couple of extra methods to take advantage of RelayId and RelayIdRef.
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
| |
This is going to appear in config files etc. We don't want the user
to have to type "<none>" in a bridge line.
|
| | |
|
| |
|
|
| |
I wanted this for testing. I think it's reasonable to promise this.
|
| |
|
|
|
|
|
|
| |
Make PtTargetSettings be Default.
No longer wrap it in Arc. We want to be able to update it here during
construction. If we want to save memory with copies of the same
bridge line, we should do this for the whole Bridge I think.
|
| |
|
|
|
|
| |
Also, document the features.
Closes #588.
|
| |
|
|
| |
https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/91
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This seems a minimal API for such a thing.
|
| |
|
|
| |
This repetition was getting repetitive.
|