On 2022-06-25 15:18, Allan McRae wrote:
I'm not too sure we really want to mimic gpgv behavior. Validating all signatures sounds great in theory, but the only real security guarantee we can give with the current control mechanisms and options in makepkg is basically "source has any signature available in validpgpkeys".
As we have no constraints to specify a signature threshold, there is no way for makepkg to consider tree, two or one available signature as more or less trustworthy. For instance a rogue maintainer can just distribute whatever they want using a single trusted signature which makepkg will happily consume. Hence the only guarantee we can provide currently is to have `any` signature instead of `all`.
While this is the case, this may lead to potential issues like "random" secondary signatures or potentially even old superseded keys that are still used as a multi signature which we don't actually wanna forcefully trust anymore.
Taking this into account, I'd suggest we go with an `any` approach instead of `all` for the time being. If makepkg ever gets finer trust control per source, such adjustments should be reflected here as well.
I have read this argument multiple times and I just don't understand it...
Switching to any signature being valid rather than all means we could have two signatures saying "bad file, do not use" and one saying "all is good", and we trust the good one. I would not use the source fine in this case.
If there is one good and one bad signature, this could mean that one of the two maintainers has gone rogue and uploaded a malicious release, but was not able to produce a valid signature by the other maintainer. However, nothing stops them from just uploading a release that has only a single valid signature made by their own key: there is no way to tell pacman (or gpgv, for that matter) that a release must be signed by both keys, since there is no way to specify a threshold on the number of required signatures. So in this scenario, requiring both signatures to be valid does not offer increased signature benefits since a new release with just a single signature would be recognised as valid just as well. On the other hand, upstreams might be signing releases with an old, deprecated key in addition to the current main signing key. In this case, if the old key gets revoked at some point we would not want to invalidate releases just because they are still signed by the old key, which is what would happen when requiring all signatures to be valid. Even worse, if we require all signatures to be valid, the old key *must* be added to the validpgpkeys array because a release signed by both keys could not be validated without trusting that key. However, a new release signed by only the old key would then also be considered to be valid, see above. So requiring all keys to be valid forces maintainers to add less trusted keys as valid just to make the validation pass. Levente's argument is that we do not gain much from validating both signatures in the first scenario, while in the second case requiring both signatures even makes the situation actively worse. Therefore without being able to specify more detailed key usage policies in the PKGBUILD, trusting any valid signature seems to be a reasonable default, and is also in line with the current approach of trusting *any* of the keys in the validpgpkeys array. One way the situation could be improved is to add a threshold for the number of required valid signatures. In the first scenario, this threshold could be set to 2 in order to always require both signatures to be present and valid. In the second scenario, one would set the threshold to 1 instead and only add the newer key to validpgpkeys, which prevents releases that are only signed by the deprecated key to be considered as valid. However, it is not entirely clear what the default value for this new threshold would be: setting it to the number of keys in the signature file does not make sense since this can arbitrarily vary between releases as shown by the first scenario above. Therefore the only reasonable default threshold would be 1, which exactly corresponds to the approach taken in v2 of the proposed patch to require at least one valid signature. Therefore I would argue that having such a threshold would be more of an improvement that could be based on v2 of the patch rather than a separate implementation: it could be easily achieved by changing arrays_intersect() to return the number of elements in the intersection and to compare that number with a new threshold variable specified in the PKGBUILD (which would default to 1 if unset in order to be backwards compatible). Best, Jonas