Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
- The libtest benchmark harness that is automatically added by cargo
interferes with criterion. Disable it everywhere where there are no
benchmarks.
- https://github.com/rust-lang/rust/issues/47241
- https://bheisler.github.io/criterion.rs/book/faq.html
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Actually use the functions being documented.
|
|
|
|
- Fixes #188.
|
|
|
|
- Adjust the interface of crypto::symmetric::Mode so that the crypto
backend is responsible for managing the IV rather than the caller.
- The new API is one step towards facilitating a RustCrypto backend
for Sequoia (see #333), as RustCrypto does not expose the IV
modifications to the caller.
- As a bonus, this commit introduces proper support for ECB mode.
Previously callers that wanted ECB mode would request CBC mode, then
hackily zero out the IV on each call. Nettle actually has proper
support for ECB mode, just via a slightly different API.
|
|
|
|
- Add a convenience function to determine if a KeyHandle contains an
invalid identifier.
|
|
- We implement Fingerprint::to_hex and KeyID::to_hex. Also
implement it for KeyHandle.
|
|
- We implement str::FromStr for Fingerprint and KeyID. Also
implement it for KeyHandle.
|
|
- It is possible for a primary key to also be a subkey.
- Correctly handle that case.
- In particular, don't merge Public Key packets with Public Subkey
packets, etc.
|
|
- `Cert::armored` conveniently wraps a `Cert` with ASCII armor and
adds nice comments.
- Provide the same mechanism for `TSK`s.
|
|
|
|
- Release buffered-reader 1.0.0, sequoia-openpgp 1.0.0, and
sequoia-sqv 1.0.0.
- Also release sequoia-sop 0.22.0.
|
|
- Fixes build on architectures with unsigned chars.
|
|
- Fixes #630.
|
|
- January 1st is a holiday in much of the world.
- When we disable an algorithm, things will almost certainly break
somewhere.
- Reduce the chance that things break when people are on vacation by
using February 1st as the cutoff day instead of January 1st.
|
|
- A `Policy` now knows whether the use of a hash requires collision
resistance or only second pre-image resistance.
- Extend `StandardPolicy`'s hash policy API to allow a user to
express a more nuanced policy that takes this information into
account.
- See #595.
|
|
- This uses calculated hash algorithm security instead of a hard-coded
value.
|
|
- Adjust `self_signatures`, `certifications`, `self_revocations` and
`other_revocations` to return `impl Iterator` over the signatures.
- Adjust all call-sites including doc tests.
- Adjust downstream projects (sq, autocrypt).
|
|
- The standard policy currently has two policies related to hash
algorithms: when a hash algorithm should be rejected for normal
signatures, and when a hash algorithm should be rejected for
revocation sigantures.
- If we distinguish two security contexts, then we'll have four
policies (the cross product).
- If the currently state is not already unmanageable, then this
certainly is.
- Simplify this by using a single scalar to represent how long a
revocation certificate using a broken hash should continue to be
accepted.
- This is probably sufficiently expressive in practice as this is a
largely inexact science. And, if a more nuanced policy is
required, it is always possible to wrap `StandardPolicy`.
|
|
- Add `Duration::years`.
- This function assumes that there are 365.2425 days in a year,
which is the average number of days in a year in the Gregorian
calendar.
|
|
- Make `Duration::seconds` a const fn.
|
|
- Certificates with a primary key that is not signing capable, and a
subkey that is, are strictly more secure than ones that combine
signing and certification capabilities in the primary key.
- If the owner of a certificate with a signing-capable primary key
can be tricked into creating a binary signature over carefully
chosen attacker-controlled data, this signature can be repurposed
to bind arbitrary attacker-controlled components to the
certificate using a chosen-prefix collision attack on the hash
function (see e.g. "SHA-1 is a Shambles" for a similar attack).
- Having a separate signing-subkey mitigates the attack, because
signatures by the signing subkey cannot bind components to the
certificate.
|
|
|
|
|
|
|
|
- If no data has been read, that may indicate an error. In this
case, even requesting no data may fail.
|
|
|
|
- Remove the function.
- Remove associated tests.
- Cert::revocation_keys does examine all live self-signatures.
- Fixes #629.
|
|
- Avoid the additional `fn f()`.
|
|
- See #480.
|
|
- Fixes #473.
|
|
|
|
- Fixes #622.
|
|
|