| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \
| |/
|/|
| |
| | |
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.
|
| |\
| |
| |
| |
| | |
Parse (and format) bridge lines
See merge request tpo/core/arti!745
|
| | | |
|
| | |
| |
| |
| |
| | |
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.
|
| |
|
|
|
| |
The config parsing wants this. Also there are some anomalies in the
types here that ought to be tidied up.
|
| | |
|
| | |
|
| |
|
|
|
| |
This clarifies that the types apply to pluggable transports only,
and not (typically) to the default plain-old-TCP transport.
|
| | |
|