default keyid format

[Daniel Kahn Gillmor]

On Wed 2016-01-27 03:34:18 -0500, Werner Koch wrote:
> On Wed, 27 Jan 2016 07:34, dkg at fifthhorseman.net said:
>
>> i just noticed that 2c3e67430d9b523c85c81ae562223fd51e3608cc claims to
>> be signed-off-by me, but it also includes a change in the default
>> keyid-format, from 0xlong to short.
>
> Actually this new enum KF_DEFAULT is pretty useless: In keyid.c we have
>
>   if (format == KF_DEFAULT)
>     format = opt.keyid_format;
>   if (format == KF_DEFAULT)
>     format = KF_SHORT;
>
> but in gpg.c we set opt.keyid_format to KF_SHORT. 

hm, confusing.  but this is relevant for more than gpg, right?  it's
also relevant in gpgv at least.

>> I actually think that the format should be 0xlong, *not* short [0] (or
>
> Well, I still hesitate to change this because it will break some users
> applications (which are broken anyway by not using --with-colons).

I'm not particularly worried about those script -- if they're doing
parsing of non-machine-readable output, they are going to have fix that.

> Wouldn't it be better to always print the fingerprint with keylistings -
> the fingerprint is the real identity of the key and not the kludge withe
> long keyid.  This is what the option --with-fingerprint does.

I agree -- this was kind of what i was proposing about not showing any
keyids at all, but removing the keyid entirely seemed like it might be
too radical a suggestion.  I'm all for it if other people are up for it
though :)

More conservatively, i guess we could introduce a "none" option for
--keyid-format; and make "none" the default, while enabling
--with-fingerprint automatically.

>> discussion), so i was a little surprised to see this change as
>> attributed to me.
>
> It was commited by Neal and he added another Signed-off-by line.

I see that, but the commit lists me as the author, and the presence of
my own Signed-off-by line implies that i signed off on the whole piece,
including the switch back to short keyIDs.  This isn't a big deal (i'm
not proposing that git history needs to be rewritten), but if anyone
cares about using these things for attribution, it's probably something
to be more careful about in the future.

   --dkg