On Tue, Mar 22, 2016 at 01:02:40PM +0000, David Woodhouse wrote: > On Mon, 2016-03-21 at 18:02 +0100, Till Maas wrote: > > > > It is a simple one-liner if you use gpgv2: > > http://pkgs.fedoraproject.org/cgit/rpms/youtube-dl.git/tree/youtube-dl.spec#n35 > > That's better than my version; thanks. It also means there's probably > not a lot of point in trying to simplify it with an RPM macro. > > Might be nice if we could just use the ASCII-armoured key instead of > having to generate the gpgkey-$KEYID.gpg keyring, but it's not the end > of the world. I already meant to file this feature request after discussing this with Werner Koch, so here it is and hopefully it will really be implemented: https://bugs.gnupg.org/gnupg/issue2290 > The original draft does raise an interesting question — do we need to > put the upstream PGP key directly into the package git tree instead of > the lookaside cache? IMHO this makes it easier to manage, since one can just use fedpkg new-sources for the new tarball and signature without making sure that the key stays in the sources file. > I suppose while the lookaside cache is still only using MD5(!) to > validate what it downloads, the answer to that is an unequivocal 'yes'. > Which means it would be even nicer to find a way to use the ASCII- > armoured version of the key. Perhaps even if the check ends up being a > two-stage process where we *make* a keyring and then use it with gpgv2? > But really, the key is encoded in the signature already; can't we just > specify the acceptable fingerprint on the gpgv2 command line? Is that a > reasonable feature request for gpgv2? The key itself is not part of the signature, only the short key id is an optional part of the signature. Btw. the keyring is just the de-armored GPG key, therefore an armored key can be de-armored with: gpg --dearmor But it also might make sense to first import the key and then export it in a minimised form with: gpg --export-options export-minimal --export $KEYID > $keyring > The original draft also asks if we want the signature itself to be in > the git tree. I don't really see the point, if the signing key is > trusted. I agree with you here. Kind regards Till -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
