| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This matches the behavior of C tor.
Part of #1100.
|
| | |
| |
| |
| |
| |
| | |
Matches the behavior of C tor.
Part of #1100.
|
| | |
| |
| |
| | |
This matches the behavior of C tor. Part of #1100.
|
| | |
| |
| |
| |
| |
| | |
This matches the behavior of C tor.
Part of #1100.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
tor-hsservice: Publisher error message improvements
See merge request tpo/core/arti!1991
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This errors such as
```
DEBUG tor_hsservice::svc::publish::backoff: failed to upload a hidden service descriptor: circuit failed attempt=2 can_retry=true
```
into
```
DEBUG tor_hsservice::svc::publish::backoff: failed to upload a hidden service descriptor: could not build circuit to HsDir attempt=2 can_retry=true
```
|
| |\ \
| | |
| | |
| | |
| | | |
Add design note about bandwidth rate limiting.
See merge request tpo/core/arti!1965
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-hsservice: Report the IptManager status
Closes #1083
See merge request tpo/core/arti!1966
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We should be reporting all IPT errors, not just the ones coming from the
IPTs that are "current".
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1966#note_2996978
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This will enable the `IptManager` to more accurately report its status.
Part of #1083
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The new `IptError` type represents an IPT error that is definitely
caused by a bad IPT.
`IptError` will be made public and exposed through a variant of the
`Problem` enum used for status reporting.
Part of #1083
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We are about to add a new `IptError` type that is only for errors that
are the IPT's fault (the ones `IptEstablisherError::is_ipt_failure()`
returns `true` for).
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Closes #1083
|
| | | | |
| | | |
| | | |
| | | | |
Part of #1083
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `IptManager` now reports its status as `Recovering` (with the
`latest_error` set to `IptError::FaultyIpt`) if it doesn't have enough
good IPTs to publish. Its status is `Degraded` if it has published some
IPTs, but needs to establish more.
Note: unconditionally setting `latest_error` to `IptError::FaultyIpt` is
not entirely correct. We will need to get the actual errors, if any,
from the `IptEstablisher`.
Part of #1083
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `OnionServiceStatus` API can now report errors coming from
`IptManager`.
Part of #1083
|
| | | | |
| | | |
| | | |
| | | | |
Part of #1083
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`State::Degraded` means we've successfully published a number of
introduction points, but we would like to have more.
Part of #1083
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Since these are `*StatusSender` APIs, it seems more idiomatic to call
them `send*`.
|
| |/ / /
| | |
| | |
| | |
| | | |
We don't have blank lines between the other variants, so let's remove
this one too for consistency.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-keymgr: Error type improvements
Closes #1115
See merge request tpo/core/arti!1960
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
`InvalidKeyPathComponentValue::Slug` now has to wrap a `String`, because
we can't get `HsIdParse` errors as static strings.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1960#note_2994317
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
The tor-keymgr crate *is* documented, but could use a better README and
some examples and/or usage guides.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This rewords the docs for clarity.
Part of #1115
|
| | | | |
| | | |
| | | |
| | | | |
This removes a remnant of a now-gone TODO.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
It appears within the public API (it is the error type returned from
`KeySpecifierComponent`), so let's make it public.
|