[pacman-dev] [PATCH 0/2] Add support for verifying pgp signatures to makepkg

[Allan McRae]

On 23/06/11 17:36, Wieland Hoffmann wrote:
> Hi,
>
> this adds support for verifying pgp signatures provided by upstream to
> makepkg. A new array pgpsigs is defined holding the URLs to all the
> signature files.
>
> However, there're still a few quirks:
>
> * You have to manually import the key which signed the source. Actually
>    that's good, but:
>
> * You don't know why the verification failed. It's either a wrong
>    signature or the key is simply not known to gnupg. This is really
>    bad, so I've chosen to make pgp verification optional for now. makepkg
>    --pgp enables it.


I'm not going to review the actual patches yet because I think there are 
a few things that need discussed about how best to handle this first.

Firstly I want to note that there is another patch implementing this in 
a slightly different way on the bug tracker:
https://bugs.archlinux.org/task/20448
https://github.com/str1ngs/pacman/compare/sigs
So we might be able to combine some ideas here.


So, onto the implementation:

1) Do we need a separate array for signatures, or should they be just 
added in the source=() array?  If it was in the source array, I can just 
use bash expansion like:

source=(http://ftp.gnu.org/gnu/bash/bash-4.2.tar.gz{,.sig})

and it is fairly clear which files have signatures.  It is also flexible 
enough to have a different source line if the signature is hosted 
elsewhere.  As a "bonus" we would get md5sum checks on the signature file...

I find a separate array that is not aligned with the source array (as in 
element x in the source array is not going to always be element x in the 
sig array) to be a bit confusing.  We can detect signatures to check in 
the source array by extension (note comment #4 below) so I really think 
a separate array is overkill.

2) How much control do we need on when this checking is done?  Both 
implementation so far have provided some way to enable/disable this 
checking.  I think it should run by default and a --skippgpcheck  (name 
needs work...) analog to --skipinteg is all that is needed.

3) Can we use some return values from gpg to distinguish the failure 
cases?  Then we could give some granularity in our output - e.g. Pass, 
FAIL, Unknown Key, (others???).  I would be fine if the "Unknown Key" 
case was just a warning.  I would also tend to hide the gpg output here 
as a failure will need manually investigated by the user anyway.

4) Note many projects distribute ascii armored signatures, so the 
extensions that need to be detected are .sig and .asc  (is that all?)

Allan