[pacman-dev] [PATCH 0/2] Add support for verifying pgp signatures to makepkg
themineo at googlemail.com
Wed Jun 29 10:34:04 EDT 2011
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:
> >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:
> >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:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: not available
More information about the pacman-dev