| 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
This covers the easy cases, where we are selecting relays
at random based on a selector.
|
| | |
|
| | |
|
| |
|
|
| |
Part of #1297
|
| |
|
|
| |
Part of #1297
|
| |
|
|
| |
Part of #1297
|
| |
|
|
| |
Part of #1297
|
| | |
|
| |
|
|
| |
Part of #1297
|
| |
|
|
|
|
|
|
| |
Some of the `tor_circmgr::Error` variants will include the `UniqId` of the
corresponding circuit, so we'll need to be able to display it without the
`Circ ` prefix.
Part of #1297
|
| |
|
|
|
| |
We use this for a RetryError in circmgr, but we will also want it in
hsservice.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
We're about to want this.
|
| |
|
|
|
|
|
|
|
| |
This
1. Makes the errors smaller
2. Redacts (currently, scrubs) the chantarget when safe logging is enabled
The other error variants in tor-circmgr::Error don't seem to contain
information that should become sensitive as part of bridge support.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
According to doc/Errors.md, and in keeping with current best
practices, we should not include display an error's `source()` as
part of that error's display method. Instead, we should let the
caller decide to call source() and display that error in turn.
Part of #323.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than running preemptive circuit construction every 10
seconds, we change it to back off when it is "failing". (We define
"failing" as creating no new circuits, and as giving at least one
error.)
This change means that we'll have one less reason to hammer the
network when our connectivity is failed for some reason.
Closes #437.
Part of #329.
|
| |
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
| |
We already have the ability to get peer information from ChanMgr
errors, and therefore from any RetryErrors that contain ChanMgr
errors.
This commit adds optional peer information to tor-proto errors, and
a function to expose whatever peer information is available.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If all guards are down and they won't be retriable for a while, try
waiting that long to get whichever guard _is_ retriable.
Additionally, if we are making multiple circuit plans in parallel,
only report our planning as having failed if we failed at making
_all_ the plans. Previously we treated any failure as fatal for the
other plans, which could lead to trouble in the case when guards
were all down or pending.
Part of #407.
|
| |
|
|
| |
Also add some TODO comments in circmgr for future work.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We handle them by reporting them to task that's waiting for the
circuit, then relaying the panic.
Doing so allows the waiting task to distinguish panics
(EK::Internal) from cases where the reactor dropped the task
entirely (EK::ReactorShuttingDown). And doing _that_ removes one
case of EK::Canceled, which helps us on our goals towards #348.
Closes #347.
|
| | |
|
| |
|
|
| |
We can't use discriminants here now, but maybe we can in the future.
|
| |
|
|
|
|
|
|
| |
From its old name, this error had implied that we were giving no
useful information when we were waiting on a pending cirucit request
that failed. In fact, this error would only happen if we dropped the
`mpsc::Sender` for a circuit attempt without reporting success or
failure.
|
| |
|
|
| |
(Instead of reporting the _last_ error, report the _worst_ error.)
|
| |
|
|
|
|
|
|
|
|
| |
These errors should almost never be seen by the user; we should instead
retry the circuit. But they _can_ be seen by the use if selecting a
guard takes too long, or too many attempts. (Therefore, they aren't true
"internal" errors.)
I suspect that we might not want to keep this TransientFailure kind, but
I'm not sure what else to do here for now.
|
| |
|
|
| |
There are a couple of tricky ones I'll do separately.
|
| | |
|
| |
|
|
|
| |
(By our convention, these errors should say what we were trying to
spawn when the error occurred.)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Provide an enum variant to contain the SpawnError and a From impl.
We use `#[from]` here because it doesn't really make sense to attach
any context, as it's not likely to be very relevant.
|
| |\
| |
| |
| |
| | |
Make most arti-client fields reconfigurable.
See merge request tpo/core/arti!181
|