[pkg-gnupg-maint] Changes for GnuPG in debian

[Daniel Kahn Gillmor]

On Thu 2016-08-04 17:16:32 -0400, Bill Allombert wrote:
> On Thu, Aug 04, 2016 at 02:57:51PM -0400, Daniel Kahn Gillmor wrote:
>> > How will that work for popularity-contest ?
>> > popularity-contest use gpg for encryption and not signature, and this
>> > is not handled by gpgv.
>> 
>> Thanks for the prompt followup!  I just did a quick scan of
>> popularity-contest and it looks to me like it all works smoothly with
>> 2.1 providing /usr/bin/gpg.
>> 
>> > Specifically in /etc/cron.daily/popularity-contest
>> >
>> >   GPGHOME=`mktemp -d`
>> >   $GPG --batch --no-options --no-default-keyring --trust-model=always \
>> >        --homedir "$GPGHOME" --keyring $KEYRING --quiet \
>> >        --armor -o "$POPCONGPG" -r $POPCONKEY --encrypt "$POPCON"
>> >   rm -rf "$GPGHOME"
>> 
>> This looks fine.  If you're willing to Depends: gnupg (>= 2.1.14) in the
>> future, you could change this to use "--recipient-file $KEYRING" instead
>> of "--trust-model=always --keyring $KEYRING -r $POPCONKEY", but given
>> that the current code works on all versions i'd recommend that you just
>> keep it as it is.
>
> Thanks, will do at some point.
>
>> One proposed cleanup patch is attached (use fingerprints instead of
>> keyids as a general best practice!), but shouldn't be immediately
>> necessary or relevant to the upgrade.
>
> There is only one key in the keyring. It would be simpler not to specify
> a key at all, but I could not find a way to do it.

Well, the new way to do it without specifying a key is --recipient-file,
mentioned above :)

> Using fingerprint is slightly worse.

by this logic, using a long key ID is also slightly worse than using a
short key ID, yet you didn't use a short key ID. :P

Rather, the reason to use a fingerprint is because key IDs generally
need to go away.  If you're trying to specify a key someplace, you can
either specify it by user id or e-mail address (human-readable, but not
cryptographically-strong), or you can specify it by fingerprint
(cryptographically-strong, but not human-readable).  It doesn't make
sense to pick a point anywhere in the middle of this spectrum.

If you go the cryptographically-strong route, you'd be doing me a favor
by switching to full fingerprints because authors of other tools (where
it might be more important to use full fingerprints because of how
they're structured) wouldn't be able to point to popcon as an example of
a place where key IDs are deemed acceptable.

if you're going the human-readable route, maybe it would be better to
instead use:

  -r "<${MAILTO}>"

and drop $POPCONKEY entirely?

it'd require a bit more footwork to support the approach described in
the "FAQ for derivative distribution" section of FAQ, though.  (that bit
probably needs some re-thinking if you go the --recipient-file route as
well, fwiw).

anyway, that's just food for thought for future popcon development.

thanks for your work on popcon, by the way.  it's handy to have those
stats.

Regards,

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20160804/fe29fa13/attachment.sig>