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_f... [3] https://nullprogram.com/blog/2019/07/22/