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
