| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 updates the code to match the spec.
This fixes TROVE-2024-008.
Closes #1474
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This is just code motion: moving the vanguard-specific parts of
`maybe_extend_stub_circuit()` behind the `vanguards` feature will enable
us to refactor it to use `select_middle_for_vanguard_circuit()`, which
is only available if the `vanguards` feature is enabled.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
This test is not new (it was added in !2168), but I think it's a good
idea to annotate the tests preventing security issues with the TROVE
number and/or arti ticket they pertain to.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
When extending SHORT circuit stubs, the last hop shouldn't be the same
as the circuit 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, the HsCircPool had a bug that caused SHORT lite-vanguards
circuits to be incorrectly extended by one hop when being repurposed as
EXTENDED circuits (EXTENDED circuits only need to be extended by extra
hop if full vanguards are in use).
Closes #1456 and #1458
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
tor-circmgr: Exclude the circ target when building paths.
Closes #1425
See merge request tpo/core/arti!2179
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
We now return an internal error if the path we've just built contains
the same hop in multiple positions.
|
| | |
| |
| |
| | |
Closes #1425
|
| | |
| |
| |
| | |
target.
|
| | |
| |
| |
| |
| |
| |
| | |
When checking for relay equality, we are happy to accept some false
positives (which result in building/selecting a different circuit). We
want to be less tolerant of false negatives, to avoid accidentally using
a circuit that doesn't have the properties we need.
|
| |/
|
|
|
|
| |
This is a follow-up from !2167.
It should prevent issues like #1417 from going unnoticed.
|
| |
|
|
| |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2168?commit_id=3c67fa55c7c5b0c4f30c1d57e8e67fe541d9c99e#note_3033368
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Storing the VanguardMode in multiple places (in the VanguardMgr *and*
the HS circ Pool) is dangerous and can lead to split brain situations
where different parts of the code think they are running in different
VanguardModes.
See #1424
|
| |
|
|
|
|
|
| |
`VanguardMgr` should be the source of truth for obtaining the current
`VanguardMode`.
Closes #1424
|
| |
|
|
| |
See arti#1424
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, HS stub circuit selection (with vanguards enabled) was
buggy: when selecting a circuit stub from the circ pool, we failed to
ensure its last hop was different from the circuit target. So in some
cases, arti would attempt to extend a stub circuit of the form G -> L2
[-> L3] -> T to T, which can't work, because a relay won't extend a
circuit to itself (or to its predecessor, for that matter).
Closes #1417
|
| |
|
|
| |
This will soon grow more complex.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|