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 <a...@deuxchevaux.org> uid [ultimate] Axel Beckert (E-Mail + Jabber) <a...@noone.org> uid [ultimate] Axel Beckert (Symlink) <xta...@symlink.ch> uid [ultimate] [jpeg image of size 3155] uid [ultimate] Axel Stefan Beckert uid [ultimate] Axel Beckert (FSFE Fellow) <a...@fsfe.org> uid [ultimate] Axel Beckert (Debian Developer) <a...@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 <a...@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
