summaryrefslogtreecommitdiff
path: root/crates/tor-circmgr/src/path
Commit message (Collapse)AuthorAgeFilesLines
* tor-circmgr: errors: Use autoconversion for BugIan Jackson2022-02-171-2/+2
|
* Add kinds for *most* circmgr errors.Nick Mathewson2022-02-162-11/+16
| | | | There are a couple of tricky ones I'll do separately.
* circmgr: Port InternalError to use Bug.Nick Mathewson2022-02-161-1/+5
|
* Don't create circuits if the consensus is stale by over 72 hoursNeel Chauhan2021-12-121-0/+7
|
* Merge branch 'bug183a_redux' into 'main'eta2021-12-071-6/+5
|\ | | | | | | | | | | | | Squash, refactor, and test !139 (Don't use same family as exit when picking a guard) Closes #183 See merge request tpo/core/arti!173
| * Move the "real families" code into tor-netdir.Nick Mathewson2021-12-061-15/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Just as `in_same_family` is a member of Relay, so the function for getting all the real family members of a relay should belong in the same crate. This change also removes the `family()` accessor: it gives the _claimed_ family rather than the _acknlowedged_ family, and is therefore a bit dangerous. There's still a hole in this logic; I've noted it in the Limitations section. If we get a microdescriptor for a relay in between creating and using the guard restriction, it might be omitted from the family list.
| * Use hashset _inside_ GuardRestriction.Nick Mathewson2021-12-061-6/+4
| | | | | | | | This approach saves us from a linear search when picking guards.
| * Change GuardUsage to have Vec of restrictions.Nick Mathewson2021-12-061-5/+4
| | | | | | | | | | | | | | | | There's not much reason to use a HashSet here, since we're just going over the whole list. This reverts commit 16e8489abbea1581b8e2 and does a little more refactoring.
| * Implement guard family restriction codeNeel Chauhan2021-12-061-4/+16
| |
* | Resolve roughly half of the XXXXs.Nick Mathewson2021-12-061-4/+0
|/ | | | | | | | We want to only use TODO in the codebase for non-blockers, and open tickets for anything that is a bigger blocker than a TODO. These XXXXs seem like definite non-blockers to me. Part of arti#231.
* add semicolons if nothing returnedDaniel Eades2021-11-252-2/+2
|
* Fix a few typos.Nick Mathewson2021-11-241-1/+1
| | | | Also fix some commonwealth spellings that had slipped in.
* Flatten enforce_distance into path_rules.Nick Mathewson2021-11-181-8/+8
| | | | Also use the path_rules name consistently throughout the code.
* Disable a check in exitpathNick Mathewson2021-11-021-1/+2
| | | | | This check relies on families being enforced correctly, which is not the case when specifying a fixed exit and using guards. (See #183)
* Allow clone-on-copy in tor-circmgr tests to fix a nightly-only clippy warning.Nick Mathewson2021-11-022-0/+2
|
* tor-circmgr: test ExitPathBuilder with guards.Nick Mathewson2021-11-021-0/+103
|
* tor-circmgr: test DirPathBuilder with GuardMgr.Nick Mathewson2021-11-021-0/+40
|
* tor-circmgr: tests for netwoks with no exitsNick Mathewson2021-11-021-0/+31
|
* Do not blame a guard for failures on non-random circuits.Nick Mathewson2021-10-261-1/+11
| | | | | | | | | We must not apply our new path-bias behavior (where we blame a guard if it gives us too many indeterminate circuit failures) if the path was not chosen at random. If too many random paths fail, we know that's suspicious, since the other relays are a random sample. But if a bunch of user-provided paths fail, that could simply be because the user's chosen exit is down.
* Run "cargo fix --edition-idioms=2018".Nick Mathewson2021-10-221-1/+1
|
* Implement guards for multihop paths.Nick Mathewson2021-10-132-21/+82
| | | | There are some limitations here, as noted in the comments.
* Actually select guards for directory circuits.Nick Mathewson2021-10-131-10/+19
|
* Pass the guard manager down to the path selection functions.Nick Mathewson2021-10-112-9/+22
|
* WIPNick Mathewson2021-10-112-7/+11
|
* fix/silence clippy lints in test modulesDaniel Eades2021-09-082-0/+2
|
* Move all crates into a `crates` subdirectory.Nick Mathewson2021-08-272-0/+373
This will cause some pain for now, but now is really the best time to do this kind of thing.