Debian Patches

Status for rust-sequoia-openpgp/2.2.0-2

Patch Description Author Forwarded Bugs Origin Last update
drop-wasm-and-windows.patch diff --git a/Cargo.toml b/Cargo.toml
index c4ae49b..555be3d 100644		 no
drop-experimental-and-variable-time-crypto-backends.patch =================================================================== no
simplify-version-ranges.patch diff --git a/Cargo.toml b/Cargo.toml
index bbe196d..75175dd 100644		 no
update-botan.patch diff --git a/Cargo.toml b/Cargo.toml
index 75175dd..6ab82b1 100644		 no
disable-crypto-cng-and-crypto-rust-features.patch diff --git a/Cargo.toml b/Cargo.toml
index 6ab82b1..93fed06 100644		 no
downgrade-rand-to-0.8.patch diff --git a/Cargo.toml b/Cargo.toml
index 93fed06..5976329 100644		 no
disable-flaky-leak-tests.patch diff --git a/Cargo.toml b/Cargo.toml
index 5976329..dca8321 100644		 no
0001-openpgp-Reject-nested-embedded-signatures.patch [PATCH 1/2] openpgp: Reject nested embedded signatures.
OpenPGP supports nested signatures. Normally only a single level of
nesting is used, however, an attacker could create a deeply nested
data structure. When Sequoia would parse such a signature, it would
recurse, which could exhaust the stack, and cause the program to
crash. We've mitigated this vulnerability by changing Sequoia to
reject signatures that have more than a single level of nesting.

Nested signatures are used in conjunction with subkey binding
signatures.

To associate a subkey with a certificate, the primary key issues a
so-called subkey binding signature over the primary key and the
subkey. This is a statement by the primary key that the subkey is
part of the certificate.

To prevent an attacker from claiming a subkey and any signatures it
issued, signing-capable subkeys also issue a so-called primary key
binding signature. A primary key binding signature is a statement by
the subkey that says what certificate it is a part of. Unless the
attacker has the subkey's secret key material, it can't forge a
primary key binding signature and thus can't claim the subkey.

Whereas the subkey binding signature is stored as a top-level packet
in a certificate, the primary key binding signature is nested in the
subkey binding signature as an embedded signature. As an embedded
signature is just a normal signature, a subkey binding signature can
also contain an embedded signature. An attacker can use this to
create a deeply nested signature.

For details, see Sections 5.2.3.34, 5.2.1.8 and 5.2.1.9 of RFC 9580:

https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.3.34
https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.1.8
https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.1.9

When Sequoia would parse an embedded signature, it would recurse and
parse it like a normal signature. An attacker could create a
signature that contains thousands of nested signatures. When Sequoia
parsed such a signature, it could exhaust the stack, which would
result in the program crashing.

Fix this by rejecting embedded signatures that contain an embedded
signature.

This vulnerability is present since the first release of
sequoia-openpgp.		 "Neal H. Walfield" <neal@sequoia-pgp.org> no 2026-04-22
0002-openpgp-Don-t-imply-missing-key-flags-from-key-type.patch [PATCH 2/2] openpgp: Don't imply missing key flags from key type.
Some old v4 certificates (ca. 1998) used v3 signatures for binding
signatures. Since v3 signatures do not have signature subpackets,
they do not include the key flags field. In such cases, an
implementation would infer the key capabilities from the key's public
key algorithm.

The way that Sequoia infers the key flags can lead to a key flag
confusion attack in which Sequoia does not check that a signing subkey
has a back signature, but should. This allows an attacker to claim a
subkey and any signatures it issued.

The key flags confusion arises as follows. Sequoia exposes the key
flags via two methods: [`SubpacketAreas::key_flags`] and
[`ValidKeyAmalgamation::key_flags`]. The former method returns the
raw key flags. It can't infer key flags based on the key's public key
algorithm, as that information is not available. The latter method,
`ValidKeyAmalgamation::key_flags`, has both the binding signature and
the key and infers the key flags from key public key algorithm if the
key flags subpacket is absent. This means that two different views of
the key flags may be inadvertently used when making a security
decision.

[`SubpacketAreas::key_flags`]: https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/packet/signature/subpacket/struct.SubpacketAreas.html#method.key_flags
[`ValidKeyAmalgamation::key_flags`]: https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/cert/amalgamation/key/struct.ValidKeyAmalgamation.html#method.key_flags

When checking whether a subkey belongs to a certificate, Sequoia used
`SubpacketAreas::key_flags` to get the key flags. If the key flags
were not set, then it would not check for a valid back signature.
When verifying a signature over data, it would use
`ValidKeyAmalgamation::key_flags` (via `for_signing`) to check if the
signing key was signing capable. In this case, if the key flags were
not set, the key flags would be inferred from the key's public key
algorithm. This allows an attacker to circumvent the back signature
check by binding a subkey to their certificate and not setting its key
flags in the binding signature.

https://gitlab.com/sequoia-pgp/sequoia/-/blob/cd6116b2/openpgp/src/cert/bundle.rs#L375
https://gitlab.com/sequoia-pgp/sequoia/-/blob/cd6116b2/openpgp/src/parse/stream.rs#L2899

This change removes the code that infers the key flags from the public
key algorithm. That code was introduced in July 2023, which was first
released in `sequoia-openpgp` 1.17.0.

https://gitlab.com/sequoia-pgp/sequoia/-/commit/9e48a064e55e5ee61bc8caf6d7d0979c398aa4cd		 "Neal H. Walfield" <neal@sequoia-pgp.org> no 2026-04-23

All known versions for source package 'rust-sequoia-openpgp'

Links