Age | Commit message (Collapse) | Author |
|
- adds a new method to support the [Policy URI
subpacket](https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.20).
Close #536.
|
|
- The current implementation of `Cert::insert_packets` is O(n*m)
where n is the number of signatures in the certificate and m is
the number of signatures in the packets to insert.
- Be smarter. Put the signatures in a BTreeMap and search it
instead of doing a linear scan to see if we already have a
given packet.
- Fixes #706.
|
|
- Fixes #335.
|
|
- See #335.
|
|
- See #335.
|
|
- This is a low-level interface. We will provide nicer abstractions
in a followup.
- See #335.
|
|
|
|
- https://rust-lang.github.io/rust-clippy/master/index.html#iter_nth_zero
|
|
- https://rust-lang.github.io/rust-clippy/master/index.html#len_zero
- https://rust-lang.github.io/rust-clippy/master/index.html#comparison_to_empty
|
|
- https://rust-lang.github.io/rust-clippy/master/index.html#useless_conversion
|
|
- Compiling with 1.51 toolchains prints warnings about redundant
semicolons. Remove them.
|
|
|
|
- At some point, invalid self-signatures would be mis-classified as
third-party certifications by Cert::canonicalize. As a side-effect,
invalid self-revocations would be considered third-party
revocations, changing the certificates revocation status to
CouldBe. Confusingly, also changing the digest prefix would break
this mis-classification, resulting in a revocation status of
NotAsFarAsWeKnow.
- The underlying issue was fixed in
7afee60b7cf0f19559bfccd8c42fdc77f6b9c655.
- Add a test that demonstrates that bad signatures are now
recognized as such, and that the confusing behavior previously
observed is now consistent.
- Fixes #486.
|
|
- Add a test exercising key encryption.
- Demonstrate that key packets are correctly replacing existing
packets when using Cert::insert_packets.
|
|
- See #686.
|
|
- See #335 and https://savannah.nongnu.org/bugs/index.php?60154
|
|
|
|
- Note that the spec is still in flux, therefore we don't expose it.
|
|
|
|
- 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.
|
|
- 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.
|
|
- 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`.
|
|
- 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.
|
|
|
|
- Avoid the additional `fn f()`.
|
|
- See #480.
|
|
- If the signer controls the data that is being signed, then the
hash algorithm only needs second pre-image resistance.
- This observation can be used to extend the life of hash algorithms
that have been weakened, as is the case for SHA-1.
- Introduces a new `enum HashAlgoSecurity`, which is now passed to
`Policy::signature`.
- See #595.
|
|
- See #615.
|
|
- This way the entire `BufferedReader<C>` will be `Send` and `Sync`.
- Modify all other crates accordingly.
- See #615.
|
|
- See #615.
|
|
- See #615.
|
|
|
|
- This ensures that all types with Policies (`Valid*`) are `Send` and `Sync`.
|
|
- See #627.
|
|
|
|
- Since `set_features` requires ownership of `Features`, it should take
ownership rather than borrowing and cloning them.
See https://rust-lang.github.io/api-guidelines/flexibility.html#caller-decides-where-to-copy-and-place-data-c-caller-control .
- See #616.
|
|
- Make `generate_key` polymorphic over `AsRef<KeyFlags>`.
- Since `set_key_flags` requires ownership of the key flags, it should
take ownership rather than borrowing and cloning the them.
See https://rust-lang.github.io/api-guidelines/flexibility.html#caller-decides-where-to-copy-and-place-data-c-caller-control .
- See #616.
|
|
`key` parameter.
- Make sign_direct_key take Key of key::PublicParts.
- Simplify calling sign_direct_key by using Into.
- Allow passing None to sign_subkey_binding.
- Allow passing None to sign_userid_binding.
- Allow using None as key parameter.
- Improve docs mentioning new default for `pk`.
- `pk` set to `Option::None` will now default to signer's public key.
- Fixes #565.
|
|
|
|
- Hide the `use .. as openpgp` statement if we don't use it in the
example.
|
|
- Secret key material is not authenticated by OpenPGP, so care must
be taken when merging certificates.
- Rename Cert::merge to Cert::merge_public_and_secret.
- Add new function Cert::merge_public. This function can be used to
merge certificates from untrusted sources as it ignores secret key
material that cannot be authenticated by OpenPGP.
- Fixes #584.
|
|
|
|
|
|
- Seal `ValidAmalgamation`, `ValidateAmalgamation` and
`key::PrimaryKey`
- Sealing traits so they cannot be implemented outside the openpgp crate.
This way we can extend the traits without breaking the API compatibility.
Every implementation of a sealed trait needs to also
implement the `seal::Sealed` marker trait.
- Implementing `seal::Sealed` for `ValidKeyAmalgamation<'a, P, R, R2>`
also implements it for
- `ValidPrimaryKeyAmalgamation<'a, P>`
- `ValidSubordinateKeyAmalgamation<'a, P>`
- `ValidErasedKeyAmalgamation<'a, P>`
Therefore these can implement `ValidateAmalgamation`
and `key::PrimaryKey`
without explicitly implementing `seal::Sealed`
- See #538.
|
|
- This allows us to store verification errors with the signatures.
- See #619.
|
|
|
|
|
|
[Seal] the `cert::Preferences` trait
so it cannot be implemented for types outside this crate.
Therefore it can be extended in a non-breaking way.
Attempts to implement the trait will not compile.
refers: #538
[seal]: https://rust-lang.github.io/api-guidelines/future-proofing.html#sealed-traits-protect-against-downstream-implementations-c-sealed
|
|
- Change `Cert::into_packets` to return the underlying packets.
That is don't drop secret key material like `Cert::serialize`
does.
|