Age | Commit message (Collapse) | Author |
|
- See #1068.
|
|
- The proposal that once thought would end up as the next revision
of OpenPGP does not have the backing of the IETF OpenPGP working
group. We should not support it for the following reasons:
- Accepting it risks proliferation of a proprietary format.
- It is less scrutinized, and interactions with other versions
or features of the OpenPGP standard is not well understood.
Notably, as the "v5" Signature packets use an 8 octet length
counter in the footer, the hashed data streams alias with v3
Signatures. See also
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/220
- Rejecting "v5" Signature Packets addresses these risks.
|
|
- The proposal that once thought would end up as the next revision
of OpenPGP does not have the backing of the IETF OpenPGP working
group. We should not support it for the following reasons:
- Accepting it risks proliferation of a proprietary format.
- It is less scrutinized, and interactions with other versions
or features of the OpenPGP standard is not well understood.
Notably, as the "v5" AEAD encrypted data packet doesn't use key
space separation, it cannot protect against cross-algorithm
attacks, so now the question of which algorithms are safe to use
depends on which packet they are used with.
- Rejecting "v5" AEAD Encrypted Data Packets addresses these risks.
|
|
- The Galois/Counter mode for block ciphers is a FIPS-approved AEAD
mode. It will be added to the upcoming OpenPGP standard so that
we have a FIPS-compliant subset of OpenPGP.
|
|
- This function allows accepting hash algorithm for one particular
security property.
- Closes https://gitlab.com/sequoia-pgp/sequoia/-/issues/595
|
|
- Fixes #892.
|
|
- One of the brainpool curves was not included in our enum Curve,
because at the time we implemented ECC support, it wasn't part of
the RFC4880bis document.
- Unfortunately, we failed to mark enum Curve as non-exhaustive, so
we cannot add a variant without breaking the API.
- We can, however, support the curve by matching on its OID.
|
|
- When rejecting a bad critical notation, `Error::PolicyViolation`
was used incorrectly. The first field is the thing that is in
violation of the policy, not a description.
|
|
- For some packets we'd like to have different policies depending on
the version. This in particular applies to Signatures: by default
we want to reject v3 signatures, but accept v4 signatures.
- By default, reject v3 signatures as of 2007.
- Fixes: #945
|
|
- The test is supported to check that the default is used, so don't
override the default.
|
|
- To use a good list, we need to reject all options by default and
then only enable those on the good list.
- Add a mechanism to reject all options in a particular
category (hash algorithms, critical subpackets, asymmetric
algorithms, symmetric algorithms, AEAD algorithms, and packet
tags).
- See #941.
|
|
- It is sometimes useful to iterate over all variants of a
given enum.
- Add the `variants` method to AsymmetricAlgorithm
`PublicKeyAlgorithm`, `SymmetricAlgorithm`, `AEADAlgorithm`,
`CompressionAlgorithm`, `HashAlgorithm`, `SignatureType`,
`ReasonForRevocation`, `DataFormat`, `packet::Tag`, and
`SubpacketTag` to do this.
|
|
- `HashAlgorithm`, `SubpacketTag`, `SymmetricAlgorithm`,
`AEADAlgorithm`, and `packet::Tag` implement `PartialEq`, `Eq`, and
`Copy`. Change `AsymmetricAlgorithm` to also implement those
traits.
- In addition to the aesthetic motivation, having the same interface
simplifies using all of these types with the same macro.
|
|
- Sometimes it is useful to configure a `StandardPolicy` via a
configuration file.
- To avoid pulling in a number of additional dependencies, this is
implemented in a separate crate, `sequoia-policy-config`.
- Document its existence in the `StandardPolicy` documentation to
improve its discoverability.
- Fixes #941.
|
|
|
|
- Previously, there were two issues:
- There is an implicit policy that constraints the symmetric
algorithm to AES. RFC6637 doesn't forbid other ciphers, so
arguably this should be made explicit and moved to the standard
policy. Only using AES seems to be a sane default choice and will
not impede interoperability in practice (notably, GnuPG constrains
to AES as well).
- We constrain hashes only based on their output length, and are
hence willing to use dubious combinations like (AES128, MD5).
- Constrain the parameters in StandardPolicy::key. Mention this in
the documentation.
- Fixes #839.
|
|
- Fixes #769.
|
|
|
|
- openpgp: Make broken relative links absolute:
- find -name "*.rs" -exec sed -i -E 's,^( *//[/!](.*): )((super::)+packet),\1crate::packet,' {} +
- find -name "*.rs" -exec sed -i -E 's,^( *//[/!](.*): )((super::)+cert),\1crate::cert,' {} +
- find -name "*.rs" -exec sed -i -E 's,^( *//[/!](.*): )((super::)+parse),\1crate::parse,' {} +
- find -name "*.rs" -exec sed -i -E 's,^( *//[/!](.*): )((super::)+policy),\1crate::policy,' {} +
- find -name "*.rs" -exec sed -i -E 's,^( *//[/!](.*): )((super::)+serialize),\1crate::serialize,' {} +
- find -name "*.rs" -exec sed -i -E 's,^( *//[/!](.*): )((super::)+armor),\1crate::armor,' {} +
- find -name "*.rs" -exec sed -i -E 's,^( *//[/!](.*): )((super::)+types),\1crate::types,' {} +
- find -name "*.rs" -exec sed -i -E 's,^( *//[/!] *(\[`PacketPile`\]):).*$,\1 crate::PacketPile,' {} +
- openpgp: Link to PacketParser and Policy structs, not the modules.
- ffi: Make links to sequoia_openpgp and sequoia_net absolute
- find -name "*.rs" -exec sed -i -E 's,^( *//[/!](.*): )((super::)+sequoia_openpgp),\1sequoia_openpgp,' {} +
- find -name "*.rs" -exec sed -i -E 's,^( *//[/!](.*): )((super::)+sequoia_net),\1sequoia_net,' {} +
|
|
- Apply cargo intraconv.
|
|
|
|
- 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
|
|
- Constants have by default a `'static` lifetime
- https://rust-lang.github.io/rust-clippy/master/index.html#redundant_static_lifetimes
|
|
- https://rust-lang.github.io/rust-clippy/master/index.html#match_like_matches_macro
|
|
- https://rust-lang.github.io/rust-clippy/master/index.html#or_fun_call
|
|
- SystemTime +/- Duration may over-/underflow.
|
|
- Currently, the openpgp crate doesn't process third-party
certifications.
- As such, there are no contexts in the openpgp crate where ignoring
a trust signature subpacket or regular expression subpacket would
lead to an incorrect result.
- Similarly, if an application doesn't process third-party
certifications, it also won't incorrectly handle the trust
signature and regular expression subpackets.
- If an application does process third-party certifications, and
doesn't handle trust signatures or regular expressions, then it
should explicitly opt-out.
- As such, change the StandardPolicy to accept the Trust Signature
subpacket and the Regular Expression subpacket.
|
|
|
|
- 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.
|
|
- 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`.
|
|
- Fixes #473.
|
|
|
|
|
|
- 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.
|
|
- All types that are `Send` and `Sync` are checked now.
- Fixes #627.
|
|
|
|
- This ensures that all types with Policies (`Valid*`) are `Send` and `Sync`.
|
|
- Use generics and the anonmymous lifetime in `assert_send_and_sync!`.
- See 627.
|
|
- See #627.
|
|
- 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.
|
|
- Fixes #563
- With an MSRV >= 1.40.0, we can use #[non_exhaustive], as mentioned
in #406.
- This is also a clippy lint:
https://rust-lang.github.io/rust-clippy/master/index.html#manual_non_exhaustive
|
|
|
|
- This will allow us to mark subpackets as authenticated by the
verification operation.
|
|
- This is closer to collection types such as HashMap, and
distinguishes the function from Cert::merge that merges two
certificates.
- See #572.
|
|
|
|
- See #525.
|
|
- This also drops the implementation of PartialOrd since we did not
use it in the key selection after all.
- Fixes #525.
|