Using `zeroize` here tells these crates that they should make
various structures zeroize-on-drop.
(This is not yet implemented in `aes` 0.8.1, but support has been
merged in the repository for `aes`, so it should go out in the next
release.)
No corresponding feature flag is needed to enable zeroize-on-drop
for `rsa` and `*25519-dalek` private keys.
This allows us to give better errors in the case where bootstrapping
succeeds at first, but fails thereafter for long enough to make our
directory expire.
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.