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.
At the site of modify_hop, we now have a comment explaining the
internal-error issue.
To make the internal error less likely, we lower the modify_hop call
in lib.rs into GuardSet, where it can make sure it's looking at the
same filter as was used to select the guard.
The function name "pick_guard_ext" is not permanent; I'm going to
rename it in the next commit.
Previously, the API said "you need to call this in a loop till it
returns false". We did that in one place, but not another.
With the introduction of filters, forgetting to loop here becomes a
bug: so instead, change the behavior of extend_sample_as_needed so
it handles looping itself.
The fake network we construct for these tests is small in ways that
can sometimes cause weird behavior with guard filters. We fix this
by adjusting the parameters of the guard selection algorithm
accordingly in the tests.
With these new parameters, #491 no longer occurs.
This commit also adds comments to explain why the parameters are set
as they are.
Closes#491.
guard-spec.txt specifies that we have multiple separate samples of
guards that we can use depending on whether the filter is
restrictive or not. Here we implement the rules for switching
between samples.
When we're filtering guards, we have to check whether the filter is
"restrictive": if it forbids most of the guards (by bandwidth), we
keep its guards separated from the main set. If it is
super-restrictive, we also warn.
This functionality is specified in guard-spec.txt.
Since a guard can have a bunch of addresses, and the guard is
permitted if any one of those addresses is permitted, then we might
decide to use a guard with some non-permitted addresses. Thus, we
need to filter those addresses before returning the view of the
guard as a FirstHop.
Rustls uses ring, which uses code from BoringSSL, which derived from
OpenSSL before OpenSSL changed their license. So ring is currently
under 3BSD/SSLEay licenses, which aren't GPL-compatible, which may
be a problem for some people.
See #493.
The `DirBootstrapStatus` type now exposes a blockage() method to
return an `Option<DirBlockage>`.
The blockage types reported are more low-level than I'd like, but
they are IMO good enough for now: we'll want to get experience with
actual vs hypothetical problems before we refine them.
A "reset" happens whenever we have to start a download attempt over
-- either because we ran out of retries, or we found something wrong
with the consensus after fetching certificates.
An "error" happens when we have a recoverable error from one or more
directory sources.
A "stall" happens whenever a round of downloads or cache loads leads
to no change in the status.
We don't yet use this as part of our status reporting.
Previously we used the "if-modified-since" time associated with the
consensus download, and/or the "valid-after" time in the consensus
attempt, to put multiple attempts into sequence, and to tell one
from another. But that approach was always a kludge, and will soon
get more unreliable as the DirStatus logic gets a bit more complex.
With this commit, we change separate download attempts to be
identified with an AttemptId that increments whenever we decide to
get a different directory from the one we have. IMO this new code
is _much_ cleaner.
This is about to become only a _part_ of what defines a DirStatus: a
DirStatus will also include a reset count, and some kind of info
about how long we've gone without progress.
These need to be optional: they improve performance by shifting to
asm implementations, which may not be everybody's idea of good practice.
These are not 'pure' features, since they select one implementation
but disable another. Therefore they don't go in `full`.
Closes#441.
This change also means that we need to create the handle and scheduler
earlier in the process of creating the DirMgr. If we don't, we won't
have a way to manage the task before bootstrap() returns.
The "full" feature is a catch-all for all features, _except_:
* Those that select a particular implementation (like
tor-llcrypto/with-openssl) or build flag (like "static")
* Those that are experimental or unstable (like "experimental-api")
* Those that are testing-only.
This change (not yet exposed as an API) will let the TorClient have
a `TaskHandle` corresponding to the directory task, letting it
make the directory task dormant as needed.
In reviewing !553 I noticed that the empty digest list error had to be
handled in two places. I filed #492 about the duplication.
In fact it turns out to have been quadruplication.
The new code also avoids cloning the underlying objects, instead
sorting a Vec of references.
This will make it much more convenient for code that only wants one of
these traits (or a subset of them). This is a good thing to support
because it will allow us to use a ZST in places that do not need an
actual async runtime handle (typically, the runtime handle is needed
only for spawn).
(This is slightly different from recovering from errors in the
middle of a list of mds, since in this case we _can't_ advance to the
next md.)
Also, note that a given branch is probably not reachable.
After changes to the prop339, the domain name in an Address can only be
255 bytes max and can NOT contain nul byte(s).
Unit tests had to be modified to accept this change:
- Centralise msg_ip_address
- Add currently-passing tests for address length
- Test counted address length longer than type wants
Related to #463
Signed-off-by: David Goulet <dgoulet@torproject.org>
Some of our existing code optionally takes a netdir from the
caller. When it doesn't give us one, use the netdir from the
installed NetDirProvider.
(Possibly someday we should remove the NetDir arguments
entirely. I'm deferring that because there are only two APIs
affected, and because making this change would force us to rewrite a
pretty large mess of unit tests.)
Previously it was the job of a task in CircMgr to do this; but we're
going to want to give GuardMgr full access to the latest NetDir for
this, and for other code-simplification reasons.
With this change I'm deprecating a couple of functions in
tor-circmgr. It's no longer necessary for us to have an artificial
external way for you to feed new NetDirs to a circmgr. (I could
just remove them, but I want practice deprecating.)
Our own code is the only stuff that consumes NetDirProvider, and all
the code that consumes it wants it to be Send and Sync.
Making this change avoids our having to define a new function to
upcast Arc<dyn Foo> to Arc<dyn NetDirProvider + Send + Sync>.
Unlike "cancel" and "fire", "suspend" and "resume" don't change any
pending timers or events: they just prevent execution of those
events for a while, and let them resume later on.
This uses some apparently-standard trickery to implement a function
that lets us upcast from Arc<dyn Subtrait> to Arc<dyn Supertrait>.
I considered as alternatives `as_dyn_trait` and `cast_dyn_object`.
Both were nice, but generated a far larger interface than this.
The randomized tests in this crate take a lot of iterations to
converge, so they default to using a deterministic PRNG seed with
few iterations and higher tolerance, and they only randomize the
tests (with more iterations and tighter tolerances) when you
explicitly opt in to randomization.
(If you specify a seed explicitly, you're doing that to reproduce a
randomized case, so we use the same behavior.)
This only affects uses of thread_rng(), and affects them all more or
less indiscriminately. One test does not work with
ARTI_TEST_PRNG=deterministic; the next commit will fix it.
The new `testing_rng()` function is meant as a replacement for
thread_rng() for use in unit tests. By default, it uses a randomly
seeded RNG, but prints the seed before the test so that you can
reproduce any failures that occur. You can override this via the
environment to use a previous seed, or by using a deterministic
seed for all your tests.
Backend for #486.
To me, "Incorrect permissions on file or directory /path: g=w o=w"
implies that the current permissions on /path are 022.
Change the message to "Incorrect permissions: /path is
u=rwx,g=rwx,o=rwx; need g-w,o-w", which is closer to chmod syntax and is
more useful in non-interactive environments such as CI and support.
I was looking to see if we could delete this altogether but I
discovered that on lib.rs the description does not say it's a removed
crate, in the summaries.
Fix this.
Now the validated configuration will never be `Some(0)`, even if that
is what was written in the config file. The arti CLI parser can still
produce this, so we don't touch the code that actually uses this.
(Without the canonicalisation the default builder produces `None` for
the `dns_port`, but the example would produce `Some(0)`, which is
semantically identical but fails the test.)
See https://gitlab.torproject.org/tpo/core/arti/-/issues/488 for some
background.
Canonicalise the `logging.journald` setting in the validated
configuration. Now it will never be `Some("")`, even if that is what
was written in the config file.
This allows us to write `journald = ""` in the example configuration.
(Without the canonicalisation the default builder produces `None` and
the example would produce `Some("")`, which are semantically identical
but fail the test.)
See https://gitlab.torproject.org/tpo/core/arti/-/issues/488 for some
background.
This fixes a unit test failure in weird environments (like some
containers) where the current effective GID is not included in the
list of current groups.
Closes#487.
Bug reported by @sjm217.
Cargo publish (and probably nobody else!) builds this crate with no
features enabled. When you do that, you get a warning about an
unused `use std::io`.
Fixing that.
The compiler can apparently tell that we aren't generating compile
errors! Also that we're not yet using a feature provided here.
(New lint in currently Nightly.)
This commit was made by reverting the previous commit, then
re-running the script I used to generate it. In theory there should
be no semantic changes: only changes due to improved formatting from
cargo edit.
I followed the following procedure to make these changes:
* I used maint/changed_crates to find out which crates had changed
since 0.3.0.
* I used grep and maint/list_crates to sort those crates in
topological (dependency) order.
* I looked through semver_status to find which crates were listed as
having semver-relevant changes (new APIs and breaking changes).
* I scanned through the git logs of the crates with no
semver-relevant changes listed to confirm that, indeed, they had
no changes. For those crates, I incremented their patch-level
version _without_ changing the version that other crates depend on.
* I scanned through the git logs of the crates with no
semver-relevant changes listed to confirm that, indeed, they had
no obvious breaking changes.
* I treated all crates that depend on `arti` and/or `arti-client` as
having breaking changes.
* I identified crates that depend on crates that have changed, even
if they have not changed themselves, and identified them as having
a non-breaking change.
* For all of the crates, I used `cargo set-version -p $CRATE --bump
$STATUS` (where `STATUS` is `patch` or `minor`) to update the
versions, and the depended-upon versions.
These crates had only clippy fixes that do not affect their
behavior:
tor-bytes
tor-cell
tor-events
tor-linkspec
tor-netdir
tor-socksproto
This crate only had the cargo-husky dependency removed, which
does not affect compatibility:
tor-llcrypto
Since these changes have no compatibility effects, it is not
necessary to bump the versions of these crates which other crates
depend on.
It turns out that the `toml` crate can't handle OsString, since
`toml` doesn't support serialize_newtype_variant, and the `serde`
crate tries to serialize OsString using that method.
In this commit we document that limitation, and test that we can at
least round-trip through json.
Found by inspecting test coverage.
Ian Jackson
Nick Mathewson
0x4ndy
Ian Jackson
eta
Dimitris Apostolou
trinity-1686a
David Goulet
Alex Xu (Hello71)
Neel Chauhan
trinity-1686a
michael mccune
Orhun Parmaksız