| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |\
| |
| |
| | |
# Conflicts:
# doc/semver_status.md
|
| | | |
|
| | |\
| | |
| | |
| | |
| | | |
Delete tor_dirmgr::Error::BadNetworkConfig
See merge request tpo/core/arti!506
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This was anomalous, in that it contains &'static str, rather than a
proper nested error (eg a config::ConfigError, maybe).
But in fact it tursn out it is now not constructed. The last
construction site was removed a long time ago in
Use derive_builder for Authority and FallbackDir.
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
Make the example config file into a template and move it to arti
See merge request tpo/core/arti!503
|
| | | |/ |
|
| | |\ \
| | |/
| |/|
| | |
| | |
| | |
| | | |
Teach DirMgr to use slightly untimely directories
Closes #467 and #412
See merge request tpo/core/arti!500
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- arti#445 highlighted the lack of good documentation around Arti's
multiple runtime support, as well as it being difficult to determine
what runtime was actually in use.
- Improve the documentation to solve the first problem.
- To solve the second problem, make Runtime require Debug (which is
arguably a good idea anyway, since it makes them easier to embed in
things), and print out the current runtime's Debug information when
arti is invoked with `--version`.
- (It also prints out other Cargo features, too!)
fixes arti#445
|
| | | |
| | |
| | |
| | | |
This will help implement #466.
|
| | |/
|/|
| |
| |
| | |
I need this so that I can expose the skew time for the directory
that a circuit will use, when I only have the circuit.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
| |
Relay nicknames are always between 1 and 19 characters long, and
they're always ASCII: That means that storing them in a [u8;19] will
always be possible, and always use less resources than storing them
in a String.
Fortunately, the tinystr crate already helps us with this kind of
thing.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I'm doing this per discussion, so that we can have it be part of the
TorConfig later on, and not break stuff as we change the Mistrust
API to have a builder.
This change, unfortunately, results in a little more internal
complexity and duplicated code in arti and arti-client. I've marked
those points with TODOs.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This is derived from the environment, not the configuration file: We
might not want to trust the configuration file until we've decided
whether we like its permissions.
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
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.
|
| |
|
|
|
| |
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.
|
| | | |
|