We need to replace the AtomicBool for dormant mode with something that
can wake up tasks. postage::watch is the right shape.
But we want to be able to update it but suppress no-op updates.
(There is going to be a call site where no-op updates can occur.)
In the absence of a suitable upstream method as requested here
https://github.com/austinjones/postage-rs/issues/56
we introduce this facility via an extension trait.
Every error now has an action (what we were trying to do), a
resource (what we were trying to do it to), and a source (what
problem we encountered).
Initially I tried to add "action" and "resource" fields to error
variants individually, but that led to a combinatorial explosion.
Part of #323.
This is behind a feature flag, since it isn't needed for pure
clients: only onion services and relays need this.
I've named the object that constructs these certs
`Ed25519CertConstructor` because it doesn't follow the builder
pattern exactly: mainly because you can't get an Ed25519Cert out of
it. _That_ part is necessary because we require that an Ed25519Cert
should only exist if the certificate was found to be well-signed
with the right public key.
Closes#511.
- arti#448 and arti!607 highlight an issue with upgrading `rsa`: namely,
the `x25519-dalek` version previously used has a hard dependency on
`zeroize` 1.3, which creates a dependency conflict.
- However, `x25519-dalek` version `2.0.0-pre.1` relaxes this dependency.
Reviewing the changelogs, it doesn't look like that version is
substantially different from the current one at all, so it should be
safe to use despite the "prerelease" tag.
- The new `x25519-dalek` version also bumps `rand_core`, which means we
don't have to use the RNG compat wrapper in `tor-llcrypto` as much.
closes arti#448
"Trivial" here includes stuff like cargo reformatting, comment
edits, error message string changes, and clippy warning changes.
Crates that depend on these do not need to increment.
Some of these were for decoding particular objects (we now say
what kind of objects), and some were unrelated tor_cert errors that
for some reason we had shoved into a tor_bytes::Error.
There is now a separate tor_cert::CertError type, independent from
tor_cert's use of `tor_bytes::Error` for parsing errors.
These changes make sure that the errors conform to our preferred
style, and include a description of what exactly we were doing when
something went wrong.
Note: the `base64ct` crate rejects invalid characters when the
decoding is done on padded strings. However, the `FromStr` impl
for `B64` can have both padded **and** unpadded inputs, so all
inputs are now padded first, before decoding.
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.
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.
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.
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.
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.
We support all of the following (in TOML notation):
```
user = "rose" # by name
user = 413 # by ID
user = false # no user
user = ":current" # A 'special' user.
user = { name: "rose" }
user = { id: 413 }
user = { special: ":none" }
user = { special: ":current" }
```
This is a general-purpose implementation of the ad-hoc approach
currently taken in (eg) crates/tor-proto/src/channel/reactor.rs,
with an API intended to defned against the more obvious mistakes.
This allows us to separate the two concerns: the channel reactor can
focus on handling channel cells and control messages and is over 2.5x
shorter.
The complexity of the manual sink implementation, and the machinery
needed to avoid having to suspend while holding an item, are dealt
with separately. That separate implemenation now has proper
documentation. (Tests are in the nest commit to avoid this one being
even more unwieldy.)
We use `extend` to define this as an extension trait. A competitor is
`ext` but in my personal projects I have found `extend` slightly
better.
Generally, change the paths that mention the crate name to go via a
module-level "use".
This involves adding tor-config as a direct dependency for a few
crates.
This is a benchmarking tool, and fs-mistrust doesn't like the
permissions in our CI. The env var ARTI_FS_DISABLE_PERMISSION_CHECKS
is (of course) specific to arti. Maybe it should be honoured here,
or this should be done via the config files.
But disabling this is fine for now.
A build script reaching into your .git/hooks/ and modifying them
nonconsensually was a bit of a horrifying concept, and also made it hard
to build arti with the feature disabled. Remove this crate, and replace
it with manual instructions on how to install the hooks in
CONTRIBUTING.md.
- The additional parameters passed to GetConsensusState are now passed
through all the states, and used as well.
- WriteNetDir doesn't have a now() or config() method any more, since
the states now get this from the runtime or the config parameters.
- This required modifying the tests to make a mocked runtime and custom
config directly, instead of using DirRcv for this purpose.
- Additionally, because we don't have to upgrade a weak reference for
DirState::dl_config(), that function no longer wraps its return value
in Result.
- (A bunch of the FIXMEs from the previous commit that introduced the
additional parameters have now been rectified as a result.)
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.
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.
For reference, the git source for this crate (and the others in its
workspace) currently lives in my personal github account (ijackson).
If this fork turns out to be long-lived and gains features and/or
users, it would be good to move it to a gitlab somewhere.
I have granted Nick crate ownership on the crates.io system.
This is a rough first-cut of an API that I think might help us with
keeping limited categories of sensitive information out of our logs.
I'll refine it based on experiences with using it.
This allows us to use this with an item builder type which doesn't
impl Default. (Obviously this only makes sense for items which aren't
actually builders.)
Document that this can contain either a string for expansion, or a
literal PathBuf not for expansion.
Rename the `from_path` method to `new_literal`: a very important
difference is whether it gets expanded - less important than the Rust
type. Also, now it takes `Into<PathBuf>`, which avoids a needless
clone.
(We don't change the API in `arti-client` because
`&tempfile::Tempdir()` doesn't implement `Into<PathBuf>`, so
`arti-client` has to have some new `as_ref` calls.)
Provide accessors `as_unexpanded_str` and `as_literal_path`. The
deserialisation already makes this part of the stable API,l so not
pvoding accessors seems just obstructive. They are useful for tests,
too.
Add tests for the new entrypoints, and for deserialisation of both
variants from TOML (via config, or directly) and JSON.
Nick Mathewson
Ian Jackson
eta
Ian Jackson
Arturo Marquez
trinity-1686a
Jim Newsome