[Bug 2114775] Re: Key validity not computed when key is certified by a trusted "certify-only" key (regression due to patch for CVE-2025-30258)

[Julia Sarris]

** Changed in: gnupg2 (Ubuntu)
     Assignee: (unassigned) => Julia Sarris (juliaphoebe)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gnupg2 in Ubuntu.
https://bugs.launchpad.net/bugs/2114775

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 gnupg2 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/gnupg2/+bug/2114775/+subscriptions