We could in the future provide a version of abs_retry_time which took
an &dyn closure if that turns out to be wanted.
I think this isn't a semver break because trait implementors are
allowed to relax bounds.
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.
This commit changes the way how a vector with a known sized gets
allocated, by using Vec::with_capacity() instead of Vec::new().
It will eventually avoid an allocation of more memory than required.
This commit renames the for_client and for_relay functions to
from_client and from_relay respectively, in order to indicate their
origin, as the term "for" is more likely to indicate a destination,
which is not true in that situation.
This commit renames the fixed_len! macro to fixed_len_handshake!, in
order to indicate, that this macro is only suited for cells with
commands related to handshaking.
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).
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.
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.
This is a compromise between C tor (never escapes = signs) and the
spec (calls for escaping all = signs). In C tor there is no way to
actually construct a key with an = sign in it, so this difference
should be undetectable.
This code is _not_ conditional, since we want to support running
with a proxy even if we don't support pluggable transports.
We may eventually want to refactor this into a new create.
Now, instead of duplicate checks in various cases, we simply go
through the loop one last time.
This allows us to simplify some of our other logic around here.
This is necessary so that we can look up channels (open and pending)
by all of the Ids that we know about them.
The operations needed here are pretty complex: to get them right,
I've replaced most of the accessors on the inner `ChannelMap` with a
function that holds the lock while another `FnOnce` is called. This
still gets us the invariant that we can't accidentally await while
holding the lock on the `ChannelMap`.
I've removed the tests for the accessors that are no longer there.
There are some subtleties here. Now that we have more than one kind
of Id, it's possible to have a partial match. I've tried to explain
all these cases in the comments.
}
Even though channels are practically changeable, they use locks
internally so that you don't need a `&mut Channel` to send or
receive traffic. It makes sense for reparameterizing the channel to
also use a &self reference.
I'll need this so that I can store channels in an `ByRelayIds<>`
set, and still invoke their reparameterize methods.
This is mostly a testing only change for now too, but soon I'll use
it to deal with the fact that we need to know the IDs to actually
build a channel at all.
The `ByRelayIds` type doesn't have a type equivalent to
`hash_map::Entry`, since it's a set type rather than a map
type. Therefore, the only plausible way to do entry mutation will
be to remove the old entry and insert a new one. And so, we no
longer need a "poisoned" state.
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>`.
This lets us build channels using different TransportHelpers,
including the (new) default TransportHelper, which just uses the old
connect_to_one() code.
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
The traits that launch connections need to be async; the traits that
don't, shouldn't be async.
Additionally, we need a few more "Sync" annotations here for the
futures to work.
This is an internal type (distinct from factory::ChannelFactory)
that we use to make the code in `tor_chanmgr::mgr` agnostic about
what a channel actually is, and how it is actually launched.
Therefore, I'm renaming it and giving better documentation in a
couple of places, to prevent confusion.
Add ,ignore to ignore three examples that don't actually compile.
cargo readme would add these annotations to lib.rs, but the doc
include doesn't do stuff like that. pandoc seems to still render the
result just fine.
This demonstrates that:
* !bridge-client: uncommenting nondefault bridge config generates
urecognized config key warnings (but the config is still accepted)(
* bridge-client, !pt-client: uncommenting nondefault bridges generates
error due to attempting to use a PT. If that's filtered out,
everything is fine.
* pt-client: Everything is good (as before).
* Introduce filter_examples and resolve_examples helpers,
which will become more complex in a moment.
* Move the API test into a { } block to minimise subsequent diff.
It's going to become conditional.
* In subsequent comparisons, use the parsed version, since
the API built one might not exist.
No overall functional change.
We're going to want something that has the standard list builder
methods at the Rust API, but which has different serialisation.
Sadly the implementation is annoying, because macro_rules makes it
hard to parse a nice input syntax.
This is precisely the text from the original version of !744.
There is no implementation yet, so we must add a entry to the
exception list in the tests.
Section headings appear uncommented in the file, so if we have a
whole section which is completely unrecognized (ie, an entry with no
`.`, it will be spotted when we parse the not-uncommented file too.
Right now there aren't any but there will be in a moment.
This test depends on `Duration` having a granularity of 1
nanosecond, which is not the case on OSX, and is probably not the
case on other places too.
We can re-enable this once we have a set of test vectors that use
more realistic RTTs, and a set of testing code that tolerates some
divergence.
Temporary solution for #574.
I think this is quite an inconvenient way to be carrying on.
Maybe we should disable all dead code warnings unless all features are
also enabled, and just let the compiler get rid of unused stuff later.
`${PROGRAM_DIR}` expands to the equivalent of
`std::env::current_exe().parent()`, with appropriate unwrapping and
conversions.
It is expected to be useful for finding the locations of pluggable
transports in some kinds of bundles.
Closes#586.
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.
To implement a reasonable RsaIdentity accessor, we have to
store the RsaIdentity in the RouterDesc, or else we'd have to
recalculate it using SHA1 and DER every time.
The Ed25519 identity is hidden inside the identity cert, but it's
safe to get a reference to it.
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.
Using Option<T> as an alias for T was too clever indeed, and it
meant that our HashMaps were declared with the wrong types.
Putting flags here instead gives us an extension point that we can
use in the future.
Every element in the set has up to N keys, each of which may have differnt
types. No value for any key may correspond to more than one element in
the set.
These properties can be provided, via a macro, for values of N between 1
and $BIG_ENOUGH.
We'll use this to implement a type that holds HasRelayIds.
These tests include a few reference cases, as well as a little
framework to make sure that the client and the proxy implementation
will handshake with one another successfully.
(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.)
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.
The warning `clippy::bool_to_int_with_if` is meant to shout at you
when you say `if x { 1 } else { 0 }` and instead suggest that you
say `inttype::from(x)`.
I agreed with this for the case in tor-cert, where we are literally
converting a boolean into a flag.
I don't agree with this in tor-netdoc, where we are using a boolean
to decide how many fields to skip in a given document format. So
for this case, I decided to clean up the code a little by renaming
"skip" to "n_skip", and changing the boolean to use an enum instead.
Retain "SocksHandshake" as a deprecated synonym.
Also, make an (on-by-default) feature for SocksProxyHandshake.
(There is about to be a SocksClientHandshake as well.)
Previously we always assumed that the console was ephemeral, and so
we disabled safe logging. But the console can be piped to journald.
And even if we enforce isatty there's no guarantee that the user
isn't using some kind of terminal that logs to disk or something.
Best just to enable SafeLogging unconditionally. I've added a note
about where and how we might re-enable this.
Closes#553.
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.
Ian Jackson
Nick Mathewson
Emil Engler
Ian Jackson
trinity-1686a
eta
EliTheCoder
Reylaba