makepkg: Error "unable to verify the signature." on expired key

Hi,

Many Arch packages employ verification via gpg or git verify-tag to ensure source integrity. Several packages (archiso, devtools, reprotest and others) have expired keys in the official PKGBUILDs. Using the latest pacman 6.0.2-9, the build fails, while in previous versions (6.0.2-8 and earlier) a descriptive warning is emitted.

Description

The error can be reproduced with makepkg --verifysource:

[archiso]$ makepkg --verifysource
==> Making package: archiso 75-1 (Sat Feb 10 20:11:46 2024)
==> Retrieving sources...
  -> Updating archiso git repo...
==> Validating source files with sha256sums...
    archiso ... Skipped
==> Verifying source file signatures with gpg...
    archiso git repo ... %s is unable to verify the signature.
git
==> ERROR: One or more PGP signatures could not be verified!

Expected behaviour

Building the same package (archiso) with pacman 6.0.2-8, the following output is printed:

[archiso]$ makepkg --verifysource
==> Making package: archiso 75-1 (Sat Feb 10 20:11:46 2024)
==> Retrieving sources...
  -> Updating archiso git repo...
==> Validating source files with sha256sums...
    archiso ... Skipped
==> Verifying source file signatures with gpg...
    archiso git repo ... Passed (WARNING: the key has expired.)
==> WARNING: Warnings have occurred while verifying the signatures.
    Please make sure you really trust them.

Note the helpful warning in contrast to the general unable to verify in the current version.

Investigation

I looked at the makepkg source for where the error gets raised, but couldn't find it. Edit: The failing check is in scripts/libmakepkg/integrity/verify_signature.sh.in (for git and for files). Running the check (git -C archiso verify-tag --raw "e72637798c2d6ce69d9444c568e230d44eacf6f5") on archiso, the result is the following:

[GNUPG:] NEWSIG
[GNUPG:] KEYEXPIRED 1706515556
[GNUPG:] KEY_CONSIDERED BB8E6F1B81CF0BB301D74D1CBF425A01E68B38EF 0
[GNUPG:] KEYEXPIRED 1706515556
[GNUPG:] SIG_ID ZuOkdusC4+WPwLujBUmOFOAYwOE 2024-01-24 1706120623
[GNUPG:] KEYEXPIRED 1706515556
[GNUPG:] KEY_CONSIDERED BB8E6F1B81CF0BB301D74D1CBF425A01E68B38EF 0
[GNUPG:] EXPKEYSIG 5CE88535E188D369 nl6720 <nl6720@gmail.com>
[GNUPG:] VALIDSIG 091A55D06E16FF2F5C55CBBC5CE88535E188D369 2024-01-24 1706120623 0 4 0 22 10 00 BB8E6F1B81CF0BB301D74D1CBF425A01E68B38EF
[GNUPG:] KEYEXPIRED 1706515556
[GNUPG:] KEY_CONSIDERED BB8E6F1B81CF0BB301D74D1CBF425A01E68B38EF 0

The filtered lines (if filter_gnupg_statusfile was applied) look like this:

[GNUPG:] NEWSIG
[GNUPG:] SIG_ID ZuOkdusC4+WPwLujBUmOFOAYwOE 2024-01-24 1706120623
[GNUPG:] EXPKEYSIG 5CE88535E188D369 nl6720 <nl6720@gmail.com>
[GNUPG:] VALIDSIG 091A55D06E16FF2F5C55CBBC5CE88535E188D369 2024-01-24 1706120623 0 4 0 22 10 00 BB8E6F1B81CF0BB301D74D1CBF425A01E68B38EF

This indicates an expired key which makepkg correctly identifies in previous versions.
The behaviour in case of failure has been changed in 3aa096a7.

Analysis

Apparently, git verify-tag returns an error if presented with any kind of issue with the key. In previous versions of pacman, the return value didn't matter - the output describing the error, including stderr, is printed into a file and then processed by makepkg.
Since 3aa096a7 however, the return value is checked, and any error is processed as a generic unable to verify the signature, returning an error too. Switching back to the for-loop, makepkg's processing is skipped. This means that an expired key turns from a warning with descriptive text into an error with generic description. I'm not sure this was intended.

While the example uses git verify-tag, the same applies to gpg.

Possible solutions

A fix would be to change the return after the check in verify_file_signature and verify_git_signature from return 1 to return 0 to allow the standard processing to occur.
The current behaviour also means that an expired key becomes an error instead of a warning. This is an issue as packagers generally don't have control over the keys - on the other hand, I don't see a way to cleanly separate key expiration from actual failures. Perhaps a new variable verification_fail is set instead of errors=1 and later on, if it wasn't a warning, it can lead to an actual error by makepkg.

Conclusion

Previously descriptive messages for verification issues have been - potentially unintentionally - replaced with generic messages. The mechanics for the descriptive messages are still in place, which makes a return easier and lends itself to the impression of a bug.

Similarly, previous warnings (e.g. expired keys) are now errors without much apparent discussion in the relevant MR !113 (merged).

Related issues

Curiously, the error message %s is unable to verify the signature. seems to be a raw format string, so there might be another problem at hand. Edit: Fixed in !124 (merged).

-- Vekhir