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
pgpsttjyUZjrj.pgp
Description: PGP signature
