Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: gnupg (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnupg in Ubuntu.
https://bugs.launchpad.net/bugs/2114774
Title:
Key validity not computed when key is certified by a trusted "certify-
only" key (regression due to patch for CVE-2025-30258)
Status in gnupg package in Ubuntu:
Confirmed
Bug description:
Importing a public key that is signed by an ultimately trusted public key
cause the validity of the imported key to be set to "unknown" when the trusted
signing key lacks the "Sign" key flag (0x02).
In particular, importing public keys signed by an ultimately trusted public
cause whose sole key flag is "Certify" (0x01) yields an "unknown" validity on
the imported keys while it should yield a "full" validity.
Bug appeared on:
gnupg 2.2.27-3ubuntu2.3 (jammy / Ubuntu 22.04.5 LTS)
Steps to reproduce:
1) Create a fresh GPG keyring.
mykeyring=$(mktemp -d)
2) Generate a "cert-only" certifying key
gpg --homedir "$mykeyring" --pinentry-mode loopback --passphrase ""
--quick-generate-key "My certifying key" brainpoolP256r1 cert never
3) Export the certifying key owner trust.
gpg --homedir "$mykeyring" --export-ownertrust >my_cert_key.ownertrust
4) Generate a key to be signed.
gpg --homedir "$mykeyring" --pinentry-mode loopback --passphrase ""
--quick-generate-key "My to-be-signed key" brainpoolP256r1 cert,sign never
5) Sign "My to-be-signed key" with "My certifying key"
gpg --homedir "$mykeyring" --sign-key "My to-be-signed key"
6) Export the public part of the certifying key and the public part of the
signed key.
gpg --homedir "$mykeyring" --export "My certifying key" >my_cert_key.pub.gpg
gpg --homedir "$mykeyring" --export "My to-be-signed key"
>my_signed_key.pub.gpg
7) Create a new fresh keyring
my_fresh_keyring=$(mktemp -d)
8) Import the certifying key into the fresh keyring and set its trust to
ultimate
gpg --homedir "$my_fresh_keyring" --import my_cert_key.pub.gpg
gpg --homedir "$my_fresh_keyring" --import-ownertrust my_cert_key.ownertrust
9) Import the signed key into the fresh keyring.
gpg --homedir "$my_fresh_keyring" --import my_signed_key.pub.gpg
10) Observe the validity value of "My to-be-signed key" in the fresh keyring.
gpg --homedir "$my_fresh_keyring" --list-keys
Rationale:
The backported patches for CVE-2025-30258 cause get_pubkey_for_sig() to
restrict look-up to keys with the "Sign" key flag set, regardless of the key
flags requested in pk->req_usage by the caller.
When updating the trustdb, the key validity update code ends up calling
check_signature_over_key_or_uid(), which specifically requests keys with
"Certify" key flag set when calling get_pubkey_for_sig(). Due to the
patched-induced behaviour, certifying keys that lack the "Sign" key are ignored
when computing the validity of a key.
Proposed fix:
get_pubkey_for_sig() should look-up "Certify" keys when caller specifically
requests so.
Upstream gnupg git has a patch in its stable branch that address this
regression, even though the symptom described in the commit message is slightly
different:
Commit 9b7c067717d815e16f9ea3cec88bca09a6cce7cb
gpg: Fix another regression due to the T7547 fix.
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=9b7c067717d815e16f9ea3cec88bca09a6cce7cb
Recompiling gnupg 2.2.27-3ubuntu2.3 on jammy with the above patch
fixes the issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/2114774/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp