On 29/06/11 09:21, Allan McRae wrote:
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.
Another advantage of using the source array is that the gpg keys get included with makepkg --allsource without any modifiations to makepkg.
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.
I see in another message to this thread the mention of using --status-file and grepping the output given gpg is crap with its return codes. That seems fine, but before that is implemented we should get a list of possible values and decide what makepkg will do with them. i.e., success, error or warning for the various cases. I'd lean to more warnings than failures...
4) Note many projects distribute ascii armored signatures, so the extensions that need to be detected are .sig and .asc (is that all?)
Allan