Hallo, Allan McRae:
On 29/06/11 09:21, Allan McRae wrote:
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.
I'm a bit short on time until next week, but I'll add a comment on Flyspray so we're not duplicating our efforts :)
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.
It should be possible to implement this without adding a separate array.
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.
The reason for disabling this by default were that is was unclear why the verification process failed.
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...
To better illustrate this, I've uploaded my patch to github, too: https://github.com/mineo/pacman/compare/makepkg-pgp . -- Wieland