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

Reply via email to