| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Fixes part of #2193.
(Edits from nickm: I selected the cases here that I could verify
were correct from immediate context.)
Edited-by: Nick Mathewson <[email protected]>
|
| |
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |
|
|
|
|
|
| |
Abolish the constants with the transitional names.
This also abolishes the controversial name `H_S_DIR`, which Rust case
transformation rules generated from `HSDir`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're going to separate RelayFlag from RelayFlags.
We could continue to provide a bunch of constant values for
RelayFlags, for each individual type, but that would involve an ad-hoc
derive, and would still be a bit of an unusual API.
Instead, we're going to make ``RelayFlag` a normal enum.
In this commit, we change everyone to refer to it by its singular
name. Hopefully separating out this bulk change makes both this, and
the core commit, easier to review.
|
| |
|
|
| |
I would do `#[deprecated]` but empirically that has no effect...
|
| |
|
|
|
| |
Add underscores so that the spec keywords and the flag constants
correspond (according to `paste`'s case-changing rules).
|
| |
|
|
| |
Run maint/add_warning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
|
|
|
|
| |
Now instead of saying "rejected 0/40 as not usable as middle relay;
28/40 as in same family as already selected", we say "rejected 28/40
as in same family as already selected".
Closes #2006.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is the preferred type for choosing a relay,
since unlike a RelayExclusion, it lets us add multiple restrictions,
and a relay usage.
|
| |
|
|
|
|
| |
We'll need this in order to build paths that are specifically
for client rend circuits. I thought of using a boolean here,
but that had potential to get ugly in the future.
|
| |
|
|
|
|
| |
"Useless as xyz" implies that the relay wouldn't work at all as a
middle relay, but that's not true: it _would_ work somewhat, but be
can't use it for some other reason.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When we're trying to exclude relays by family,
we need to know which lists to look at.
This information ultimately comes from the network parameters.
We could avoid this change if we just told clients
"look at all family information all the time",
but that's not what the proposal says.
This is a breaking change.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
As per #1479
|
| |
|
|
|
|
|
|
| |
This is the first step towards clarifying the questions from !2230.
Corresponding torspec changes: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/282
Part of #1479
|
| |
|
|
|
| |
This allows us to set SRVs for example (needed because by default, the
test `NetDir` is built from a consensus that doesn't contain any SRVs).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `path::exitpath::test::by_ports` test sometimes failed now that the
test is using a `GuardMgr` since `select_guard`, when given a chosen
exit, only ensures that the guard and chosen exit are not in the same
family. It does not ensure that the guard and exit do not share an
extended family. This commit relaxes an assertion in the test.
```text
thread 'path::exitpath::test::by_ports' panicked at crates/tor-circmgr/src/path/exitpath.rs:295:9:
assertion failed: r1.can_share_circuit(r3, subnet_config)
```
This "chosen exit" functionality isn't actually being used anywhere
(`ExitPathBuilderInner::ChosenExit` is only ever constructed in tests).
|
| | |
|
| |
|
|
|
|
|
| |
Functions that took `Option<&GuardMgr>` now take only `&GuardMgr`.
Three unit tests were removed that covered behaviour when no guard
manager was set.
|
| |
|
|
|
|
| |
This wraps some unit tests with `tor_rtcompat::test_with_all_runtimes!`.
This is its own commit to get the indentation changes out of the way and
declutter the following commit.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is a follow up from https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2186#note_3035525
Closes #1459
|
| |
|
|
| |
There's not much to refactor about this line.
|
| | |
|
| |
|
|
|
|
|
| |
These tests should give us *some* assurance that the upcoming
`HsVanguardPathBuilder` refactoring doesn't break anything.
Part of #1459
|
| |
|
|
| |
Part of #1459
|
| |
|
|
| |
This is less error-prone than the alternative.
|
| | |
|
| |
|
|
| |
target.
|
| |
|
|
|
|
| |
Otherwise, some of the circuits will fail (because if the target is
selected as one of the L2, L3, or M hops, it won't be able to extend the
circuit to itself).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, we'd `debug_assert` that the length of the path is valid.
However, `debug_` asserts are compiled out for release builds, which
means that if we have some code path that triggers the assertion
failure, it will go unnoticed unless our tests happen to exercise it.
It's safer to return an internal error, because we definitely don't want
to proceed if the path is too short (see arti#1400 and arti#1409).
Addresses https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2154#note_3030820
|
| | |
|
| |
|
|
|
|
|
| |
The previous STUB/STUB+ terminology was confusing, because STUB and
STUB+ are both "circuit stubs" (but STUB is shorter than STUB+).
Closes #1339
|
| |
|
|
| |
Part of #1339
|
| | |
|
| |
|
|
| |
We will soon need to reuse this.
|
| |
|
|
|
|
| |
I am about to reuse one of these on the "lite" vanguards branch. I am
renaming them to make it easier to see which one of the two I will be
using.
|
| |
|
|
|
|
| |
One of these assertions currently fails, because we have a bug in the
vanguard path builder: if lite vanguards are enabled, we only build
2-hop circuits instead of 3.
|
| |
|
|
|
| |
I don't think it's all wrong, this was left over from the first draft
implementation.
|