space separated fingerprints not accepted as user ids
Closed, WontfixPublic

Description

(all tested on 2.0.30 tarball)

NEWS has:

Noteworthy changes in version 2.0.19 (2012-03-27)

  • GPG now accepts a space separated fingerprint as a user ID. This allows to copy and paste the fingerprint from the key listing.

(though not advertised in doc/specify-user-id.texi)

it does not work as expected:
LANG=C GNUPGHOME=/tmp/gnupghome/ ./gpg2 -K "5F50 3EFA C8C8 9323 D54C 2525 91B8
CD7E 1592 5678"
gpg: error reading key: No secret key

LANG=C GNUPGHOME=/tmp/gnupghome/ ./gpg2 -K "5F50 3EFA C8C8 9323 D54C 2525 91B8
CD7E 1592 5678"
gpg: error reading key: No secret key

the key is there:
LANG=C GNUPGHOME=/tmp/gnupghome/ ./gpg2 -K "91B8CD7E15925678"
sec 4096R/15925678 2016-06-01
uid Test1 IntelMQ (no passphrase) <test1.intelmq@example.org>

LANG=C GNUPGHOME=/tmp/gnupghome/ ./gpg2 -k
"5F503EFAC8C89323D54C252591B8CD7E15925678"
sec 4096R/15925678 2016-06-01
uid Test1 IntelMQ (no passphrase) <test1.intelmq@example.org>

GNUPGHOME=/tmp/gnupghome/ ./gpg2 --version
gpg (GnuPG) 2.0.30
libgcrypt 1.6.5
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://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: /tmp/gnupghome/
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

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

Same problem noticed for Ubuntu's 2.0.22.
It works as advertised in 2.1.11.

Details

Version
2.0.30
bernhard set Version to 2.0.30.
bernhard added a subscriber: bernhard.
werner added a subscriber: werner.Jun 8 2016, 4:50 PM

Seem to be a regression in 2.0. 2.1 works as expected.

marcus closed this task as Wontfix.Jul 13 2017, 7:21 PM
marcus claimed this task.
marcus added a subscriber: marcus.

I tried to find evidence that such a change ever landed in 2.0. I now believe the mistake is in the NEWS file. As 2.0 is nearing EOL, we won't backport this.