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

[Jonas Witschel]

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
-------------- 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/1c759ef2/attachment-0001.sig>