| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
FallbackDir: orports: Introduce and use VecBuilder
See merge request tpo/core/arti!474
|
| | |
| |
| |
| |
| |
| |
| | |
And drop the ad-hoc orport() method. This brings FallbackDir's
orports field in line with our list builder API.
The general semver note in "configuation" seems to cover most of this.
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Upgrade various dependencies, now that we are MSRV 1.56
Closes #313 and #334
See merge request tpo/core/arti!476
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Now that we require Rust 1.56, we can upgrade to AES 0.8. This
forces us to have some slight API changes.
We require cipher 0.4.1, not cipher 0.4.0, since 0.4.0 has
compatibility issues with Rust 1.56.
|
| |\ \
| |/
|/|
| |
| | |
DownloadSchedule: Introduce Builder
See merge request tpo/core/arti!473
|
| | |
| |
| |
| | |
This entire struct is config. This is otiose.
|
| | | |
|
| |\|
| |
| |
| |
| |
| | |
# Conflicts:
# crates/tor-config/Cargo.toml
# crates/tor-dirmgr/src/state.rs
# doc/semver_status.md
|
| | | |
|
| | |
| |
| |
| | |
These were omitted in the earlier commits.
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/462#note_2797697
we decided not to do this.
However, having looked again at the way the FallbackList works, I
think there is a lot of value in making these two things (and anything
else like them[1]) as similar as possible.
[1] At least PreemptiveCircuitConfig.initial_predicted_ports and
NetworkConfig.authorities need the same treatment, and perhaps also
GuardUsage.restrictions (although there is no
GuardRestrictionBuilder).
In the irc discussion I imagined `LogfilesConfigBuilder` as opposed to
`LogfileConfigBuilder` (differing only in the `s`) which would be bad,
but we can use `List` instead.
We do *not* need to abstract away the validated version of the config.
Providing a type alias helps the derive_builder sub_builder DTRT
without needing special overrides.
I have split this commit so that we can drop it, if we conclude it's
not wanted.
|
| |
|
|
|
|
|
|
|
| |
Now the network fallbacks configuration wants to Deserialize
a Vec<FallbackDirBuilder>, rather than validated Vec<FallbackDir>.
Methods on FallbackListBuilder are as per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/462#note_2797697
mutatis mutandi for the fact that this struct has only fallbacks in it.
|
| | |
|
| |
|
|
| |
Typos found with codespell.
|
| |
|
|
|
| |
Now that we have TaskSchedule, we don't need to expose these any
longer.
|
| |
|
|
|
|
|
|
| |
This time, our estimator discards outliers, takes the mean of what's
left, and uses the standard deviation to try to figure out how
seriously to take our report of skew/not-skew.
These estimates are still not actually used.
|
| |
|
|
|
|
| |
We need this since we want to report certain conditions only when
they happen on a new channel, not if we observe them on a
preexisting channel.
|
| |
|
|
|
|
|
|
| |
Fortunately, we don't need a separate type here: authenticated
clock skew can only come attached to a `tor_proto::Error`.
We also remove skew from `tor_proto::Error::HandshakeCertsExpired`,
since it would now be redundant.
|
| |
|
|
|
|
|
|
| |
of a channel.
At first I wanted to have this information not be a part of channels
at all, but it is a fairly tiny amount of data, and the alternatives
are pretty crufty.
|
| |\
| |
| |
| | |
# Conflicts:
# doc/semver_status.md
|
| | |\
| | |
| | |
| | | |
# Conflicts:
# doc/semver_status.md
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 the code would do stuff like
```
schedule = RetrySchedule::new(INITIAL_DELAY);
```
which is needlessly verbose, since the schedule already keeps track
of its initial delay.
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The various background daemon tasks that `arti-client` used to spawn are
now handled inside their respective crates instead, with functions
provided to spawn them that return `TaskHandle`s.
This required introducing a new trait, `NetDirProvider`, which steals
some functionality from the `DirProvider` trait to enable `tor-circmgr`
to depend on it (`tor-circmgr` is a dependency of `tor-dirmgr`, so it
can't depend on `DirProvider` directly).
While we're at it, we also make some of the tasks wait for events from
the `NetDirProvider` instead of sleeping, slightly increasing
efficiency.
|
| |\
| |
| |
| |
| | |
tor-proto: add the ability to learn clock skew from NETINFO cells
See merge request tpo/core/arti!410
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We now check the handshake certificates unconditionally, and only
report them as _expired_ as a last resort.
(Rationale: if somebody is presenting the wrong identity from a year
ago, it is more interesting that they are presenting the wrong ID
than it is that they are doing so with an expired cert.
We also now report a different error if the certificate is expired,
but its expiration is within the range of reported clock skew.
(Rationale: it's helpful to distinguish this case, so that we can
blame the failure on possible clock skew rather than definitely
attributing it to a misbehaving relay.)
Part of #405.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NETINFO cells, which are sent in every handshake, may contain
timestamps. This patch adds an accessor for the timestamp in the
Netinfo messages, and teaches the tor-proto code how to compute the
minimum clock skew in the code.
The computation isn't terribly precise, but it doesn't need to be:
Tor should work fine if your clock is accurate to within a few
hours.
This patch also notes a Y2038 problem in the protocol: see
torspec#80.
Part of #405.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit refactors the dirclient error type into two cases:
errors when constructing a circuit, and errors that occur once we
already have a one-hop circuit. The latter can usually be
attributed to the specific cache we're talking to.
This commit also adds a function to expose the information about
which directory gave us the info.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
It'll soon more convenient to pass in FallbackDirs as a slice of
references, rather than just a slice of FallbackDirs: I'm going to
be changing how we handle these in tor-dirmgr.
|
| | | |
|
| | |
| |
| |
| | |
Closes #415
|
| | | |
|
