[pkg-gnupg-maint] Bug#772897: [Pkg-gnupg-maint] Bug#772897: gnupg2: upgrade to 2.1 fails to import secret keys

[Daniel Kahn Gillmor]

On Wed 2014-12-10 16:27:22 -0500, Ximin Luo wrote:
> Package: gnupg2
> Version: 2.1.0-1
> Severity: important
>
> When upgrading to 2.1, if an existing 2.0 gpg-agent is running, then
> the migration of secret keys fails silently with an unobvious warning
> the first time you run gpg2 after the upgrade.

I think this is only the case if the 2.0 gpg-agent was running with
--use-standard-socket.  Otherwise, new invocations of 2.1 will spawn a
new gpg-agent automatically anyway.

here's what i see starting from gpg 2.0.28 with gpg-agent
--use-standard-socket, and then upgrading to 2.1.11:

0 dkg at frigg:~$ gpg2 --armor --sign test.txt
gpg: starting migration from earlier GnuPG versions
gpg: WARNING: server 'gpg-agent' is older than us (2.0.28 < 2.1.11)
gpg: error: GnuPG agent version "2.0.28" is too old. 
gpg: Please make sure that a recent gpg-agent is running.
gpg: (restarting the user session may achieve this.)
gpg: migration aborted
gpg: no default secret key: No secret key
gpg: signing failed: No secret key
2 dkg at frigg:~$ 

note that the ~/.gnupg/.gpg-v21-migrated is *not* created, which means
that the migration will be run later, once the old agent is actively
gone.

> This can be circumvented, by killing all running gpg-agents during the
> upgrade. GPG 2.1 will automatically start them up when missing, so
> this should be safe.

Killing all running gpg-agents will result in failures for existing
processes that currently point to an agent via GPG_AGENT_INFO and use
/usr/bin/gpg instead of /usr/bin/gpg2.  If gpg2 were to replace
/usr/bin/gpg, then this might be a feasible approach.

> An alternative is to pop up a warning during the install process,
> similar to how libc upgrades pop up a warning that prompt you to
> restart various services.

That seems comparably troubling to the previous suggestion, because it's
not clear what to do for those same running processes, or how to explain
what those tradeoffs might be for existing users -- and i'd rather not
clutter debconf while we're at it.

I'm not sure the right way to resolve this universally, other than
accepting that there may be some sessions that need to be restarted, or
gpg-agents that need to be manually killed to make this happen cleanly.

I'm open to suggestions.

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20160205/23ebfe42/attachment.sig>