[PATCH] libmakepkg/integrity: handle PGP signature files containing multiple signatures

[Jonas Witschel]

On 2022-06-25 22:09, Allan McRae wrote:
> Somewhat offtopic - I'd argue that it is poor packaging to have more
> validpgpkeys in a PKGBUILD than the key used to verify the source for that
> particular package version.  Lazily just adding more keys to a PKGBUILD and
> not removing unneeded ones in case they are needed in the future is not
> ideal.

We should indeed be more careful in actively removing old keys from
validpgpkeys. However some upstreams have multiple active maintainers that
"arbitrarily" sign new releases, in which case keeping all of them in the array
can be helpful to convey an existing relationship of trust (without having to
go through the revision control system to figure out whether the key of a new
release has been already used in the past, or whether some other means of
establishing a chain of trust is necessary).

> How about...   all signatures from trusted keys (either through PGP web of
> trust, or via being in validpgpkeys) need to validate?
> 
> That does not solve the rogue maintainer issue (it is up to a packager to
> ask why the number of signatures dropped...), but it does address not
> needing to validate a legacy key.

From a security standpoint I am fine with this approach (CC Levente for his
opinion).

From an implementation standpoint I will note that this complicates things a
bit due to the structure of the GnuPG status file: for a valid signature, we
are guaranteed to get a VALIDSIG status code containing the full key
fingerprint [1], matching the information that we record in validpgpkeys.
For an invalid signature, we are only guaranteed to get a BADSIG/ERRSIG
containing the (long) key ID of the key [2] (because the key might not even be
available locally and the signature packet alone only contains the key ID
instead of the full fingerprint). So in order to check whether a bad signature
was produced by a key in validpgpkeys, we need to collect the corresponding key
ID and check whether there is a *partial* match with one of the fingerprints in
the validpgpkeys array.

I will note that it is easy to find colliding key IDs [3], so normally one
should not rely on the key ID alone (even if it is the "long" 64 bit instead of
the "short" 32 bit ID). In this case I think using the ID should be fine
though, since we only use it for "negative" matching as an additional security
check rather than relying on the key ID for "positive" matching of trusted
keys: if someone manages to upload a signature file containing a bad signature
with a spoofed key ID, the validation would still fail (rightfully so), while a
good signature from a spoofed key ID would not be considered as valid because
the fingerprint in VALIDSIG does not match.

If this seems like a reasonable approach to everybody, I would be happy to
implement the necessary partial comparison of the key IDs of invalid signatures
in a v3 of the patch. However I would like to hear Levente's opinion first
since it was he who initially brought up the concerns regarding the handling of
files containing multiple signatures.

Best,
Jonas

[1] https://github.com/gpg/gnupg/blob/master/doc/DETAILS#validsig-args
[2] https://github.com/gpg/gnupg/blob/master/doc/DETAILS#badsig--long_keyid_or_fpr--username
[3] https://nullprogram.com/blog/2019/07/22/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20220625/6ba9b5ac/attachment.sig>