Page MenuHome GnuPG
Create Task
Maniphest T7547

signatures from revoked or expired keys show up as missing keys
Open, Needs TriagePublic
Actions

Description

On the stable branch for 2.4, the fixes for T7527 appear to have a surprising consequence. A signature from a revoked key now shows up as a missing key.

In particular, in 2.4.7, the status output for evaluating a signature from a revoked key looks like this:

[GNUPG:] NEWSIG
[GNUPG:] KEY_CONSIDERED 5E13F2DF8D46E26AAC0B055CD808B9D3D20FBCCE 0
[GNUPG:] SIG_ID NFOUKuyqo/qGbuxXzbj0WZrlL/8 2025-02-27 1740676664
[GNUPG:] KEY_CONSIDERED 5E13F2DF8D46E26AAC0B055CD808B9D3D20FBCCE 0
[GNUPG:] REVKEYSIG AC54359E527359FA test key
[GNUPG:] VALIDSIG C8C34B4E807DF6907B618FB3AC54359E527359FA 2025-02-27 1740676664 0 4 0 22 10 01 5E13F2DF8D46E26AAC0B055CD808B9D3D20FBCCE
[GNUPG:] KEY_CONSIDERED 5E13F2DF8D46E26AAC0B055CD808B9D3D20FBCCE 0
[GNUPG:] KEYREVOKED
[GNUPG:] KEY_CONSIDERED 5E13F2DF8D46E26AAC0B055CD808B9D3D20FBCCE 0
[GNUPG:] TRUST_UNDEFINED 0 pgp

But built from STABLE-BRANCH-2-4 (in particular, with rG25d748c3dfc0102f9e54afea59ff26b3969bd8c1 , rG9cd371b12d80cfc5bc85cb6e5f5eebb4decbe94f and rGda0164efc7f32013bc24d97b9afa9f8d67c318bb applied), the status output looks like:

[GNUPG:] NEWSIG
[GNUPG:] KEY_CONSIDERED 5E13F2DF8D46E26AAC0B055CD808B9D3D20FBCCE 3
[GNUPG:] KEY_CONSIDERED 5E13F2DF8D46E26AAC0B055CD808B9D3D20FBCCE 3
[GNUPG:] ERRSIG AC54359E527359FA 22 10 01 1740676664 9 C8C34B4E807DF6907B618FB3AC54359E527359FA
[GNUPG:] NO_PUBKEY AC54359E527359FA
[GNUPG:] FAILURE gpg-exit 33554433

I don't know enough about the expectations of the broader ecosystem here, but this is at least tickling some brittle test suites that include the use of GnuPG, such as https://bugs.debian.org/1098995

Details

Version
STABLE-BRANCH-2-4

Related Objects

Event Timeline

dkg created this task.Thu, Feb 27, 6:54 PM
dkg renamed this task from signatures from revoked keys show up as missing keys to signatures from revoked or expired keys show up as missing keys.Thu, Feb 27, 10:36 PM
dkg added a comment.Thu, Feb 27, 10:44 PM

The same effect seems to be happening on signatures made from expired keys.

From 2.4.7, before those changes, we see the following status:

[GNUPG:] NEWSIG
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] KEY_CONSIDERED DCE608D4BC44587AE23652E641904183CD74E90B 0
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] SIG_ID 1pD6BtAaWlwZ52hYZh3ML3cOaa8 2023-01-01 1672549200
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] KEY_CONSIDERED DCE608D4BC44587AE23652E641904183CD74E90B 0
[GNUPG:] EXPKEYSIG 95904693B6DB5286 very old3
[GNUPG:] VALIDSIG 7CBC9E67C1134FCE0810F42495904693B6DB5286 2023-01-01 1672549200 0 4 0 22 10 01 DCE608D4BC44587AE23652E641904183CD74E90B
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] KEY_CONSIDERED DCE608D4BC44587AE23652E641904183CD74E90B 0

But with those changes applied, we see the following status:

[GNUPG:] NEWSIG
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] KEY_CONSIDERED DCE608D4BC44587AE23652E641904183CD74E90B 3
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] KEYEXPIRED 1735534800
[GNUPG:] KEY_CONSIDERED DCE608D4BC44587AE23652E641904183CD74E90B 3
[GNUPG:] ERRSIG 95904693B6DB5286 22 10 01 1672549200 9 7CBC9E67C1134FCE0810F42495904693B6DB5286
[GNUPG:] NO_PUBKEY 95904693B6DB5286
[GNUPG:] FAILURE gpg-exit 33554433

Aside from the status file, the normal output and the return code of the program changes. Without the changes, 2.4.7 returns 0:

0 $  gpg --status-file gpg.status.expired.old --verify < test.msg 
gpg: Signature made Sun 01 Jan 2023 12:00:00 AM EST
gpg:                using EDDSA key 7CBC9E67C1134FCE0810F42495904693B6DB5286
gpg: Good signature from "very old3" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: DCE6 08D4 BC44 587A E236  52E6 4190 4183 CD74 E90B
       Subkey fingerprint: 7CBC 9E67 C113 4FCE 0810  F424 9590 4693 B6DB 5286
0 $

But with the changes, we get a return code of 2:

0 $ gpg --status-file gpg.status.expired.new --verify < test.msg 
gpg: Signature made Sun 01 Jan 2023 12:00:00 AM EST
gpg:                using EDDSA key 7CBC9E67C1134FCE0810F42495904693B6DB5286
gpg: Can't check signature: No public key
2 $

You should be able to replicate this with the old3.cert OpenPGP certificate, which is already expired:

old3.cert973 BDownload

Over this inline-signed message, which was made when the certificate was *not* expired:

test.msg283 BDownload

dkg added a comment.Fri, Feb 28, 8:22 PM

This is also causing problems with ostree, see https://bugs.debian.org/1098951 and https://github.com/ostreedev/ostree/issues/3386