2.1.0~beta864 bugfixes [was: re: packaging dirmngr from 2.1.0]

Daniel Kahn Gillmor dkg at fifthhorseman.net
Tue Oct 7 20:54:19 CEST 2014

[readding gnupg-devel, since these are upstream-relevant questions]

On 10/07/2014 02:06 PM, Eric Dorland wrote:

> Did the upgrading to keybox [get fixed]?

The originally-reported problem (creating ~/.gnupg/pubring.gpg as a
keybox format) is fixed -- new keyrings created by gpg2 (2.1.x) are
created as ~/.gnupg/pubring.kbx instead.

I just discovered a new problem, though, which will affect people on
systems that have gpg and gpg2 coinstalled:

 0) create a new keyring with gpg2, and use it exclusively with gpg2 for
a while.
 1) somehow (accidentally?) use gpg (1.4.x) again -- this creates
 2) future runs of gpg2 now only look at pubring.gpg and ignore
pubring.kbx -- the keys you had accumulated in the keybox are no longer
listed in the output of gpg2 --list-keys

Not sure what the right thing to do about this is.  Would it be possible
for gpg2 to work by default with the union of both ~/.gnupg/pubring.gpg
and ~/.gnupg/pubring.kbx where they exist?

Or should gpg2 default to using .kbx when the .gpg file exists?

> [Did the] gnupg-agent problems get fixed?

upgrading gpg-agent:

gpg-agent-related code in 2.1.0~beta864 appears to always use the
standard socket by default (~/.gnupg/S.gpg-agent) and ignores

This means that if you were running gpg-agent from 2.0.26, and finding
its socket with $GPG_AGENT_INFO (e.g. how the current session scripts
work), then invocations from gpg 2.1 will notice that the "standard
socket" isn't in use, and will launch their own gpg-agent, so you'll
have both of them running in parallel.  This is suboptimal, but probably
not a terrible outcome.

If the old gpg-agent was listning on the standard socket in the first
place, then invocations of the gpg 2.1.0 beta that need access to the
newer agent will fail with the following message:

0 foo at alice:~$ gpg2 --list-secret-keys
gpg: starting migration from earlier GnuPG versions
gpg: error: GnuPG agent version "2.0.26" is too old.
gpg: Please install an updated GnuPG agent.
gpg: migration aborted
2 foo at alice:~$

This happens even though the updated agent is *installed*, but it just
happens to not be running.  The wording is slightly misleading, but the
problem should go away after a reboot (or just after a restart of the
user's session)

I'm also a little bit concerned that gpg 1.4.x will *not* try to start
up a gpg-agent by default if it does not find one running, which means
effectively that we still need to launch a gpg-agent during X11 session
startup when use-agent is set, just to be sure that gpg1 users have a
functional agent.


I know the above problems are transitional problems, and won't crop up
for users who have moved entirely to gpg 2.1.0.  This transitional work
is the cost of supporting multiple versions simultaneously, though, and
we seem to be committed to doing that, at least in the jessie timeframe,
so we need to get at least the dual keyring issue sorted out.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141007/93b01f1e/attachment-0001.sig>

More information about the Gnupg-devel mailing list