| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Run cargo fix --edition
2. Selectively revert the "if let"->"match" changes.
These changes are meant to protect us from the lifetime changes
for "if let" bindings in Rust 2024.
But we're not actually relying on the old lifetime rules
anywhere, and the match syntax here is quite ugly.
3. Automatically revert `$pat:expr_2021` to `$pat:expr`.
(We don't actually want to restrict the expression syntax
that our macros accept).
Done with
`git grep -l expr_2021 | xargs perl -i -pe 's/expr_2021/expr/g;'`
4. Run cargo fmt.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The CircMgr will no longer yield circuits but tunnels (src/tunnel.rs).
This is a first step to rename most circuit related objects to use
"tunnel" instead.
Some "circuit" names have been kept for more precise definitions.
No behavior changes.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
As per #1479
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AbstractSpec and FakeSpec actually make testing more difficult, since
they prevent using FakeBuilder in code that relies on the concrete
TargetCircUsage and SupportedCircUsage types. Removing them means
FakeBuilder can be used in more places, and also means that the test
code is closer to the real code, since TargetCircUsage and
SupportedCircUsage are now exercised directly in more tests.
This did require making one change to a test, which I think was
previously testing behaviour that was true for FakeSpec but not for the
real code:
The mgr::test::isolated test previously asserted that, in the case where
three circuits were requested, two with isolation and one without, the
non-isolated circuit would be shared with one of the isolated circuits.
This was allowed by the FakeSpec::supports function. However, in the
actual code, the path is as follows:
* AbstractCircMgr::get_or_launch
* AbstractCircMgr::prepare_action
* CircList::find_open
* AbstractSpec::find_supported
* abstract_spec_find_supported
* OpenEntry::supports
* SupportedCircUsage::supports
* StreamIsolation::compatible_same_type
StreamIsolation::compatible_same_type checks owner_type, which is
always zero for non-isolated streams and always non-zero for isolated
streams, meaning that a isolated stream will never be compatible with a
non-isolated stream. The seems like desirable behaviour, so I simply
modified the test to make four connections, two isolated and two not,
and checked that the isolated streams never share any circuits, and that
the two non-isolated streams use the same circuit. As far as I can tell,
this is the intended behaviour in the existing code.
|
| |
|
|
|
| |
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).
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
The `VanguardMgr` needs to know whether arti is running as an onion
service or not, in order to figure out which of the `vanguards_enabled`
and `vanguards_hs_service` modes to use.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
When the `vanguards` feature is enabled, we define
`pick_path_with_vanguards` instead of `pick_path`, rather than
conditionally defining 2 different versions of the same function.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This enables us to make `AnonymousCircuitBuilder` private.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
(These functionalities are for onion service circuits, and don't
actually need to go to an exit at all.)
|
| | |
|
| |
|
|
|
|
|
|
| |
I've done this by looking for every non-test instance of pick_relays
or pick_n_relays, and for every non-test usage of any non-ID-related
method on Relay or UncheckedRelay.
Part of #504.
|
| |
|
|
|
|
|
|
|
|
|
| |
This lets us check long_lived_ports only when we are constructing
a TargetCircUsage, and lets us remember whether or not the circuit
we've built is suitable for non-long-lived ports.
It also lets us decide whether existing circuits are compatible with
new requests.
Closes #1100.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The Stable flag means that circuits build through a given relay are
not likely to get closed precipitously. (Currently, the authorities
guess this by looking at the relay's mean time between failures.)
Generally speaking, paths must be Stable if:
* They are going to get used for a rendezvous point.
* They are going to get used for an introduction point.
* They are going to get used for exiting to a member of
long_lived_ports.
|
| |
|
|
|
| |
These messages are very verbose and I doubt anyone will want them,
usually, even when debugging.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This threads the country codes work through the rest of the codebase:
- `tor-dirmgr` will now enable GeoIP with the embedded database when the
`geoip` future is enabled
- This can be extended later using the `DirMgrConfig` to allow
specifying a custom database; this is not done here, though
- `tor-circmgr`'s `SupportedCircUsage` and `TargetCircUsage` fields gain
new `country_code` members to allow filtering circuits by country
- These are `()` in builds where the `geoip` feature is not enabled --
doing it this way means we don't have to copy and paste huge swathes
of code, since we can't use `#[cfg]` in patterns
- `ExitPathBuilder` gains (hacked-in) support for choosing a relay with
the correct country code
- Due to the lack of conjuction, we just copy and paste a small bit,
pending further refactoring
- `StreamPrefs` now lets you specify a country code, letting embedders
make use of the feature
|
| |
|
|
|
|
| |
This resolves a few dead-code warnings.
Closes #801.
|
| |
|
|
|
|
|
|
| |
Now
nailing-cargo +stable clippy -p tor-hsclient --all-features --all-targets
actually works.
squash! Add some missing imports
|
| |
|
|
|
| |
This uncovered a bug: NoUsage wasn't correct for Hs circuits because
of its behavior with channel_usage().
|
| |
|
|
|
| |
This only builds the first 3 hops. It can be extended to a fourth
hop later -- or not, depending on the circuit kind.
|
| |
|
|
|
| |
This resolves an "unused import" warning when bridges are not
enabled.
|
| | |
|
| |
|
|
|
|
| |
Without this fix, any attempt to actually use a circuit for a
`DirSpecificTarget` will fail, since supports() will say false, and
`restrict_mut()` will say `NotSupported`.
|
| | |
|
| |
|
|
|
| |
The target is identified by Into<OwnedChanTarget>.
We introduce corresponding TargetCircUsage and SupportedCircUsage.
|
| |
|
|
|
| |
As suggested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2827246
|
| |
|
|
|
|
|
|
|
|
|
| |
Replace Channel::note_usage with Channel::engage_padding_activities,
which unconditionally causes the channel to (start to) do netflow
padding things.
The condition now lives in chanmgr.
Addresses
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826094
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Channel padding depends on what the channel is being used for. We
therefore need to let the channel code know this information.
The implementation of the per-channel padding control logic will be in
the new note_usage function, which for now is simply a stub.
A future commit will introduce a `PaddingControlState` which lives in
the channel frontend; consult the doc comment for that type to see why
the plumbing through the channel manager terminates in the channel
frontend.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
