Page MenuHome GnuPG
Create Task
Maniphest T2954

signing a file shows me my short keyid instead of long
Closed, InvalidPublic
Actions

Description

$ touch tmp ; gpg --detach-sign tmp
gpg: using "0x7B75921E" as default secret key for signing

this shouldn't show a short keyid, as I have this in my gpg.conf:

keyid-format long

arguably, it shouldn't show that by default anyways, as there are easy collisions...

$ gpg --version
gpg (GnuPG) 2.1.18
libgcrypt 1.7.6-beta
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/anarcat/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Details

Version
2.1.18

Event Timeline

anarcat added projects: gnupg, Bug Report.Feb 10 2017, 11:58 PM
anarcat set Version to 2.1.18.
anarcat added a subscriber: anarcat.
justus added a subscriber: justus.Feb 13 2017, 9:52 AM

This is because you use a short key id in your gpg.conf. gpg is merely echoing
back whatever you specify there:

% touch tmp ; gpg2 --detach-sign tmp
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: using "baz" as default secret key for signing
% grep default-key gpg.conf
default-key baz

justus closed this task as Invalid.Feb 13 2017, 9:52 AM
justus claimed this task.
justus raised the priority of this task from Low to Normal.
justus removed a project: Bug Report.
anarcat added a comment.Feb 13 2017, 2:17 PM

that is true. however i still think the actual key fingerprint used should be
shown here. shouldn't we avoid short keyids everywhere?

justus added a comment.Feb 13 2017, 2:27 PM

however i still think the actual key fingerprint used should be shown here.

There are two problems with this proposal:

1/ Usability. Showing a keyid or fingerprint is less user-friendly than to show
the identifier that the user actually used in the configuration file to refer to
her key. I'd guess that most users use a UID here.

2/ Consistency. The code around the message in question also deals with error
handling in case looking up the key fails. In this case, we cannot show
anything besides what the user used in her configuration.

shouldn't we avoid short keyids everywhere?

We should avoid short keyids everywhere we use keyids, but this is not the case
here.