[pkg-gnupg-maint] Bug#834922: gnupg: No more able to sign with my 4096R key since the switch to GnuPG 2.x, but still able to sign with my old 1024D key

Sat Aug 20 15:28:09 UTC 2016

Package: gnupg
Version: 2.1.14-5
Control: affects -1 devscripts git-buildpackage git

Dear GnuPG Maintainers,

approximately since the switch to GnuPG 2.x I can no more use my
4096R/2FF9CD59612616B5 key to sign stuff:

----------------------------------------------------------------------
→ echo foo | gpg --clearsign
gpg: using "2FF9CD59612616B5" as default secret key for signing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

foo
gpg: signing failed: No secret key
gpg: [stdin]: clearsign failed: No secret key
----------------------------------------------------------------------

Nevertheless --list-secret-keys finds that key without issues:

----------------------------------------------------------------------
→ gpg --list-secret-keys 2FF9CD59612616B5
sec   rsa4096/2FF9CD59612616B5 2009-07-12 [SC]
uid                 [ultimate] Axel Beckert <abe at deuxchevaux.org>
uid                 [ultimate] Axel Beckert (E-Mail + Jabber) <abe at noone.org>
uid                 [ultimate] Axel Beckert (Symlink) <xtaran at symlink.ch>
uid                 [ultimate] [jpeg image of size 3155]
uid                 [ultimate] Axel Stefan Beckert
uid                 [ultimate] Axel Beckert (FSFE Fellow) <abe at fsfe.org>
uid                 [ultimate] Axel Beckert (Debian Developer) <abe at debian.org>
ssb   elg4096/E230E02B004AB7CC 2009-07-12 [E]
ssb   rsa4096/6BE663C75A35C975 2014-12-29 [S] [expires: 2020-12-27]
----------------------------------------------------------------------

I can reproduce this issue even with only having a single line in my
~/.gnupg/gpg.conf:

----------------------------------------------------------------------
default-key 2FF9CD59612616B5
----------------------------------------------------------------------

I also tried using "default-key 6BE663C75A35C975" (i.e. the most recent
signing subkey) instead after David Bremner mentioned something about
known issues with subkeys on IRC. But that didn't help either.

I can though still sign stuff with my old, deprecated
1024D/C09E1D8995930EDE key, e.g. if I change the above line to
"default-key C09E1D8995930EDE":

----------------------------------------------------------------------
→ echo foo | gpg --clearsign
gpg: using "C09E1D8995930EDE" as default secret key for signing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

foo
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAle4ZssACgkQwJ4diZWTDt45PQCdH83vEH8DN0VLjZsxmfp6SLo6
LI0AnA319OwDkFwY8Vd2b6oYAbYHquMz
=IvvU
-----END PGP SIGNATURE-----
----------------------------------------------------------------------

Using gpg1 instead gpg works fine with "default-key 2FF9CD59612616B5",
too:

----------------------------------------------------------------------
# echo foo | gpg1 --clearsign

You need a passphrase to unlock the secret key for
user: "Axel Beckert <abe at deuxchevaux.org>"
4096-bit RSA key, ID 2FF9CD59612616B5, created 2009-07-12

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

foo
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJXuGd9AAoJEC/5zVlhJha1ryUP/Rwyr2U7fqL7bHE+ECn0yFYy
FSldxU/F1WzbEx59FxEFFLAdSFdHbjqRemHMngRW2gwR6YgxQT/4sWcNIaNgVj+f
X+laFTlqtY4FITY33kxrDyL8WhCC4zon/Hd3S1DlFGRV5JigLSH571pW1rE6NwhM
jpBGBS3AJ9a7TQULX5FXM1hpxGZsQOr3stFHIEDqLmCOPfNe2CcQgYnW4QR38joO
kku1idWoe45Ehx9xJkT/5jV5Gf24V5z0sC2Ar4O71qiEI0tJFfUAP1ejKOQ/dk6A
MNwjOO9iyZGkN2vXyjTJUzuqljZvNUB+t6J0DPQWGxBI7TO1ycIUkW+1MUcM3mFr
ZKMz6j2WQUGRW2w1UqquEfD/GCy+fTOHz3krqSW6Kg6ApuB6C9duhaOrCrcSUAKq
kYhO9S4bMlURe6eg6jLwcZqrX3WYizuXdJiRtRPpG8hzS8VA8K44QWV5IwkyeFF6
WPQImDoVBR32vrUpYRuXB6aajYXFRr2BQq0vc+RQC8jSc4p96gqMnSAefDTFK/Gt
LvDRmN4UnSwoMp7RzTPtJ+VNROUJPrj6ARw+xTKSueNI5lKuA22LyPtEqXgYzrpQ
+he3kAu50QgKymifagxz8aZeDqoiXw098Z+M8AhFuKPs37+yl0dLfK26L1xrq9/B
mj2FqtlogW7zgQJCae7i
=dupP
-----END PGP SIGNATURE-----
----------------------------------------------------------------------

Ran into this issue with "gbp import-…", "debsign …" and "git tag -s …".

At least for debsign I found a workaround by instructing it to use gpg1
instead: "debsign -pgpg1 …" -- But that's not a solution for eternity.

Since I can even reproduce this with only having "default-key
2FF9CD59612616B5" in my ~/.gnupg/gpg.conf while that (secret and public)
key definitely exists in my keyring, I consider this being a bug, maybe
an incomplete conversion when GnuPG 2.x was first run or so.

IIRC the conversion happened during a run of "gbp import-dscs --debsnap
…" or similar command, i.e. nothing where I called gpg manually or could
intervene. At least there exists an empty file called
~/.gnupg/.gpg-v21-migrated, dated 16th of August 2016, 00:57 CEST
(GMT+0200).

P.S.: Even in the case that this is not a bug but a configuration issue
(then where?), any help or hint is appreciated as this issue severly
hinders me in doing work for Debian and I already invested several hours
to find a fix or at least track down the reason (commenting out line by
line in gpg.conf, etc.). TIA!

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-rc7-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gnupg depends on:
ii  gnupg-agent    2.1.14-5
ii  libassuan0     2.4.3-1
ii  libbz2-1.0     1.0.6-8
ii  libc6          2.23-4
ii  libgcrypt20    1.7.3-1
ii  libgpg-error0  1.24-1
ii  libksba8       1.3.4-4
ii  libreadline6   6.3-8+b4
ii  libsqlite3-0   3.14.1-1
ii  zlib1g         1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii  dirmngr     2.1.14-5
pn  gnupg-l10n  <none>

Versions of packages gnupg suggests:
ii  parcimonie  0.10.2-1
ii  xloadimage  4.1-23+b2

-- no debconf information