Your message dated Tue, 19 Apr 2016 14:49:58 -0400
with message-id <[email protected]>
and subject line Re: [pkg-gnupg-maint] Bug#821808: Acknowledgement (libgpgme11:
Fails to locate new key in agent (wrong keygrip?))
has caused the Debian Bug report #821808,
regarding libgpgme11: Fails to locate new key in agent (wrong keygrip?)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
821808: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821808
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libgpgme11
Version: 1.6.0-1
Severity: normal
libgpgme seems to have problems handling my new RSA 4096 bit key. In my
case, this is breaking reprepro (CC'ing maintainer of that).
Having the same problem as this person on Server Fault:
http://serverfault.com/questions/770130/reprepro-export-could-not-find-signing-key
Using gpg-connect-agent's KEYINFO command, and the logging suggestion from
that serverfault post, it seems like gpgme is computing the wrong keygrip(s)
for the key. It sends a HAVEKEY with two keygrips, neither of which match
the keygrips listed by KEYINFO --list.
In the context of reprepro, I'm providing it the SignWith option and giving
the 8 digit hex ID of my new key. This works fine when passed to e.g. gpg
--list-secret-keys. But reprepro complains:
Could not find any key matching '4A3CC4E9'!
Based on the gpgme failure. If I give the hex ID for my old DSA key, it
works fine.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libgpgme11 depends on:
ii gnupg2 2.1.11-6
ii libassuan0 2.4.2-3
ii libc6 2.22-6
ii libgpg-error0 1.21-2
libgpgme11 recommends no packages.
Versions of packages libgpgme11 suggests:
pn gpgsm <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 1.6.0-1
On Tue 2016-04-19 09:39:58 -0400, Matthew Gabeler-Lee wrote:
> I tracked down the problem. It is because all the instructions on the
> web for creating new keys are about using "gpg", but gpgme is built on
> "gpg2", and the two no longer share the private key ring.
>
> Quick fix for anyone that comes across this via google or such:
>
> gpg --export-secret-keys | gpg2 --import -
Thanks for the followup. I'm closing this report since there's a clear
workaround. However, gpg2 (from the 2.1 branch) should have migrated
your secret keyring automatically the first time it ever encountered
them.
See, for example: https://bugs.launchpad.net/bugs/1565963
fwiw, i'm hoping that gpg and gpg2 will be the same thing (from the
2.1.x sources) in debian in the not-too-distant future. There are
packages uploaded to experimental yesterday that make that transition,
and i welcome people trying them out once they pass the build daemons.
--dkg
--- End Message ---
