| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |
|
|
| |
Part of #1297
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
MockSleepRuntime wraps a MockRuntime instead of using
test_with_one_runtime!(), so the tests should be more
deterministic
|
| | |
|
| | |
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |\
| |
| |
| |
| | |
clippy: Allow some of our existing code patterns
See merge request tpo/core/arti!1396
|
| | | |
|
| |/
|
|
| |
In each of these, it is locally obvious that the range is nonempty.
|
| |\
| |
| |
| |
| | |
rng ranges: Use inclusive Duration ranges in several places
See merge request tpo/core/arti!1385
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Many of these call sites would panic if, somehow, the upper bound was
zero. In most cases it is very complicated to see if whether this
could happen.
However, there is a better answer:
Durations are (conceptually) dense, so picking the closed set (which
includes its boundary) rather than the open one (which doesn't) will
make little practical difference.
So change four call sites to use `..=` instead of just `..`.
|
| |\ \
| |/
|/|
| |
| | |
Optional tracing support in tor-error for error reporting
See merge request tpo/core/arti!1379
|
| | |
| |
| |
| | |
This simplifies our logging a little, and implements part of
|
| |/
|
|
| |
This appeases clippy-nightly.
|
| |\
| |
| |
| |
| |
| |
| | |
Change log levels of messages from INFO to others
Closes #854
See merge request tpo/core/arti!1172
|
| | |
| |
| |
| |
| |
| | |
This commit changes certain log messages to debug for recoverable errors
and a warn if all such attempts fail, in order to not clutter up the
info messages that end users get to see.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Now ClientCirc is no longer `Clone`, and the things that need it
to be `Clone` instead return and use an Arc<ClientCirc>
We're doing this so that ClientCirc can participate in the RPC
system, and so that its semantics are more obvious.
Closes #846.
Thanks to the type system, this was a much simpler refactoring than
I had feared it would be.
|
| |
|
|
| |
We'll use this to implement the circuits used by onion circuits.
|
| |
|
|
| |
Split off for ease of review and possible rebase.
|
| | |
|
| | |
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| | |
|
| |
|
|
|
|
|
| |
It turns out that bug #656 is not a real bug, but it was easy to
overlook the code that prevented it.
Closes #656.
|
| |\
| |
| |
| |
| | |
Channel padding
See merge request tpo/core/arti!657
|
| | |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
A "transient" error is one that does not indicate a true failure,
but rather an _expected_ need to retry. When we hit one of these,
we do not count it against the total number of permitted failures.
(We do impose a higher limit on "real failures plus transient
failures", though, to prevent infinite loops in the event of a
programming error.
Closes #517.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
It's a little overzealous sometimes, but it's mostly to the good.
|
| |
|
|
|
| |
Remove all `use` statements for `TryFrom` and `TryInto`. These are
now redundant in Rust 2021.
|
| |
|
|
|
|
|
| |
This feature is similar to ChanProvenance from ChanMgr, except that
we don't yet need to report it outside the crate. I'm going to use
it to distinguish newly created circuits from existing circuits in
the preemptive circuit builder.
|
| |
|
|
|
|
|
| |
This lets us say that the UsageMismatch cases in some parts of the
code reflect a programming error (RetryTime::Never), whereas in
other case it reflects another circuit request getting to the
circuit first (RetryTime::Immediate).
|
| |
|
|
|
|
|
|
|
| |
Use the new RetryTime type and its associates to decide how long to
wait (if at all) between attempts to build a circuit.
Closes #421.
Part of #329.
|
| |
|
|
|
|
|
| |
Previously we did not distinguish errors that came from pending
circuits from errors that came from the circuits we were
building. We also reported errors as coming from "Left" or "Right",
instead of a more reasonable description.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were treating restrict_mut() failures as internal errors, and
using internal errors to represent them. But in fact, these
failures are entirely possible based on timing. Here's how it
happens:
* Two different circuit requests arrive at the same time, and both
notice a pending circuit that they could use.
* The pending circuit completes; both pending requests are notified.
* The first request calls restrict_mut(), and restricts the request
in such a way that the second couldn't use it.
* The second request calls restrict_mut(), and gets a failure.
Because of this issue, we treat these errors as transient failures
and just wait for another circuit.
Closes #427.
(This is not a breaking API change, since `AbstractSpec` is a
crate-private trait.)
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, if we had launch_parallelism > 1, and we were willing to
retry building a circuit max_retries times, then we'd launch up to
max_retries * launch_parallelism circuits before giving up. Ouch!
With this patch, we try to keep the total number of circuits
planned and attempted to the actual max_retries limit.
Part of #329; found with arti-testing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The guard manager is responsible for handing out the first hops of
tor circuits, keeping track of their successes and failures, and
remembering their states. Given that, it makes sense to store this
information here. It is not yet used; I'll be fixing that in
upcoming commits.
Arguably, this information no longer belongs in the directory
manager: I've added a todo about moving it.
This commit will break compilation on its own in a couple of places;
subsequent commits will fix it up.
|
| |
|
|
|
|
|
| |
This is the logical place for it, I think: the GuardMgr's job is to
pick the first hop for a circuit depending on remembered status for
possible first hops. Making this change will let us streamline the
code that interacts with these objects.
|