[PATCH] libmakepkg/integrity: handle PGP signature files containing multiple signatures
Allan McRae
allan at archlinux.org
Sat Jun 25 05:18:27 UTC 2022
On 9/6/22 05:15, Levente Polyak wrote:
> Nice spot and great patch :)
>
> Review disclaimer: patch not field tested yet
>
>
> On 6/8/22 19:32, Jonas Witschel wrote:
>> PGP signature files can contain multiple signatures from different
>> keys. In
>> this case, verification is considered to be successful if *all*
>> signatures are
>> valid, compare e.g. the behaviour of the gpgv verification tool.
>
> No hard feelings here at all, but my thoughts are as follows:
>
> 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.
Allan
More information about the pacman-dev
mailing list