| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
These aren't interesting to the user.
|
| | |
|
| |\
| |
| |
| | |
# Conflicts:
# crates/tor-netdir/semver.md
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | | |
Rename `.inc` and other included files to end in `.rs`
Closes #381
See merge request tpo/core/arti!645
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In order to mitigate syntax highlighting issues and a rust-analyzer bug
(https://github.com/rust-analyzer/rust-analyzer/issues/10178), rename
files that are included with the `include!` macro to have a `.rs`
extension.
Make sure the included files are outside `src/`, in order to not confuse
humans and automated editing tools that might mistake them for valid
Rust modules.
fixes arti#381
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
There are some downstream changes required for this to work, but
they are all just unit tests that could no longer infer the type of
an Ed25519 key.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | | |
This makes lookups a little more efficient. I do with that HashSet
just supported this use-case, but for now this seems our best option.
|
| | | |
| | |
| | |
| | |
| | | |
This implementation is (sadly) too copy-heavy or now, because
HashSet<RelayId> can't be indexed with RelayIdRef.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
(It's safe to require these specific keys, since we constructed the
objects for testing, and we know for certain that they contain given
keys.)
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This method tells if two HasRelayIds contain exactly the same set of
Relay identities, and is generally useful for debugging.
|
| | | |
| | |
| | |
| | | |
These are the other inspiration for #428.
|
| | | |
| | |
| | |
| | | |
I believe that this was the original motivation behind #428.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We want the set of identities supported by a relay to be extensible
in the future with minimal fuss; we'd also like to make working
with these ID sets more convenient. To handle that, this commit
adds a new trait for "Something that has the same IDs as a relay"
and a new object for "an owned representation of a relay's IDs."
This commit introduces a similar trait for "Something with a list of
SocketAddr, like a relay has." There's no owned equivelent for
that, since Vec<SocketAddr> is already a thing.
Closes #428.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
This uses similar techniques to the commit I just did for Fallbacks.
|
| |
|
|
| |
Also re-order the filters to be a little more logical.
|
| | |
|
| |
|
|
|
|
| |
Found these by disabling the nightly dbg macro special case. Now, we
have a mechanism for globally adding suppressions to tests, we can use
that instead.
|
| |
|
|
| |
Update all lint blocks
|
| |\
| |
| |
| |
| |
| |
| | |
Implement support for reachable_addrs
Closes #491 and #93
See merge request tpo/core/arti!583
|
| | |
| |
| |
| | |
Also, improve its documentation.
|
| | |
| |
| |
| |
| |
| | |
Now the primary exposed function is `pick_guard` again.
This commit is just function renaming.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
At the site of modify_hop, we now have a comment explaining the
internal-error issue.
To make the internal error less likely, we lower the modify_hop call
in lib.rs into GuardSet, where it can make sure it's looking at the
same filter as was used to select the guard.
The function name "pick_guard_ext" is not permanent; I'm going to
rename it in the next commit.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the API said "you need to call this in a loop till it
returns false". We did that in one place, but not another.
With the introduction of filters, forgetting to loop here becomes a
bug: so instead, change the behavior of extend_sample_as_needed so
it handles looping itself.
|
| | |
| |
| |
| |
| | |
These all say, in one form or another, "there is no guard filtering;
there is only one selection". That's now false.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The fake network we construct for these tests is small in ways that
can sometimes cause weird behavior with guard filters. We fix this
by adjusting the parameters of the guard selection algorithm
accordingly in the tests.
With these new parameters, #491 no longer occurs.
This commit also adds comments to explain why the parameters are set
as they are.
Closes #491.
|
| | |
| |
| |
| |
| |
| |
| | |
guard-spec.txt specifies that we have multiple separate samples of
guards that we can use depending on whether the filter is
restrictive or not. Here we implement the rules for switching
between samples.
|
| | |
| |
| |
| |
| | |
Convert its argument type to Option<&NetDir> to better match the
rest of the API.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
When we're filtering guards, we have to check whether the filter is
"restrictive": if it forbids most of the guards (by bandwidth), we
keep its guards separated from the main set. If it is
super-restrictive, we also warn.
This functionality is specified in guard-spec.txt.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Since a guard can have a bunch of addresses, and the guard is
permitted if any one of those addresses is permitted, then we might
decide to use a guard with some non-permitted addresses. Thus, we
need to filter those addresses before returning the view of the
guard as a FirstHop.
|
| | |
| |
| |
| |
| | |
We don't need to restrict based on bits in the key id any longer,
since we have a real filter.
|
| | | |
|
| | |
| |
| |
| |
| | |
The guard filter is now a set of restrictions that can be placed on
allowable guards.
|
| |\ \
| |/
|/|
| |
| | |
Use impl_standard_builder more and remove manual Default/builder impls
See merge request tpo/core/arti!594
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
Fix several clippy issues, most with nightly
See merge request tpo/core/arti!588
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This is apparently a new warning from clippy nightly, documented in
https://rust-lang.github.io/rust-clippy/master/index.html#significant_drop_in_scrutinee .
I'm not in love with the temporary variables that this warning wants
me to introduce, but it does seem like a decent way to avoid some
kinds of deadlock.
|
| | |
| |
| |
| |
| | |
Run rustfmt. Separate commit to make review of the substantive commit
easier.
|
| |/
|
|
|
| |
This is a *lot* of unwraps. The function takes no parameters and
is used only for testing. It ought to be infallible.
|
| |\ |
|
| | |
| |
| |
| |
| | |
The trouble was that one of the helper functions they used
did not take a PRNG as an argument.
|
| | |
| |
| |
| |
| |
| | |
This only affects uses of thread_rng(), and affects them all more or
less indiscriminately. One test does not work with
ARTI_TEST_PRNG=deterministic; the next commit will fix it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some of our existing code optionally takes a netdir from the
caller. When it doesn't give us one, use the netdir from the
installed NetDirProvider.
(Possibly someday we should remove the NetDir arguments
entirely. I'm deferring that because there are only two APIs
affected, and because making this change would force us to rewrite a
pretty large mess of unit tests.)
|