| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Do _not_ bump the dependency versions on crates that have had no
changes since arti 0.0.5, since those crates do not depend on the
new APIs.
```
cargo set-version -p tor-basic-utils --bump patch
cargo set-version -p tor-llcrypto --bump patch
git restore crates/tor-checkable
git restore crates/tor-consdiff
git restore crates/tor-rtmock
```
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This performs the transitive closure of the last operation:
everything that depends on a crate with a breaking change gets the
version which it depends on bumped.
```
cargo set-version -p tor-proto --bump minor
cargo set-version -p tor-netdoc --bump minor
cargo set-version -p arti-hyper --bump minor
cargo set-version -p arti-bench --bump minor
cargo set-version -p arti-testing --bump minor
cargo set-version -p tor-config --bump minor
```
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Done with these commands:
```
cargo set-version -p fs-mistrust --bump minor
cargo set-version -p tor-bytes --bump minor
cargo set-version -p tor-socksproto --bump minor
cargo set-version -p tor-cert --bump minor
cargo set-version -p tor-linkspec --bump minor
cargo set-version -p tor-cell --bump minor
cargo set-version -p tor-netdir --bump minor
cargo set-version -p tor-persist --bump minor
cargo set-version -p tor-chanmgr --bump minor
cargo set-version -p tor-guardmgr --bump minor
cargo set-version -p tor-circmgr --bump minor
cargo set-version -p tor-dirclient --bump minor
cargo set-version -p tor-dirmgr --bump minor
cargo set-version -p arti-client --bump minor
cargo set-version -p arti --bump minor
```
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This uses similar techniques to the commit I just did for Fallbacks.
|
| |
|
|
| |
Also re-order the filters to be a little more logical.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were done with the following commands:
```
cargo set-version -p tor-basic-utils --bump patch
cargo set-version -p fs-mistrust --bump minor
cargo set-version -p tor-error --bump patch
cargo set-version -p tor-config --bump patch
cargo set-version -p tor-units --bump patch
cargo set-version -p tor-rtcompat --bump minor
cargo set-version -p tor-llcrypto --bump patch
cargo set-version -p tor-bytes --bump minor
cargo set-version -p tor-socksproto --bump minor
cargo set-version -p tor-cert --bump minor
cargo set-version -p tor-cell --bump minor
cargo set-version -p tor-proto --bump minor
cargo set-version -p tor-netdoc --bump patch
cargo set-version -p tor-netdir --bump minor
cargo set-version -p tor-persist --bump patch
cargo set-version -p tor-chanmgr --bump minor
cargo set-version -p tor-guardmgr --bump minor
cargo set-version -p tor-circmgr --bump patch
cargo set-version -p tor-dirclient --bump patch
cargo set-version -p tor-dirmgr --bump minor
cargo set-version -p arti-client --bump patch
cargo set-version -p arti --bump minor
cargo set-version -p arti-bench --bump minor
cargo set-version -p arti-testing --bump minor
```
|
| |\
| |
| |
| |
| | |
Fix clippy nightly again
See merge request tpo/core/arti!603
|
| | |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Use NetDirProvider in GuardMgr
Closes #93
See merge request tpo/core/arti!568
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously it was the job of a task in CircMgr to do this; but we're
going to want to give GuardMgr full access to the latest NetDir for
this, and for other code-simplification reasons.
With this change I'm deprecating a couple of functions in
tor-circmgr. It's no longer necessary for us to have an artificial
external way for you to feed new NetDirs to a circmgr. (I could
just remove them, but I want practice deprecating.)
|
| |/ / |
|