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@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@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
signature.asc
Description: PGP signature