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

[Ximin Luo]

On 05/02/16 19:22, Daniel Kahn Gillmor wrote:
> 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 "GnuPG agent is too old" message only started appearing recently, iirc some time after start of 2016, so I guess 2.1.11. (I may be wrong with these dates.) But I guess for Debian at least, we'll never run into that part of my bug report again, since we won't be triggering any more 1.* or 2.0 to 2.1.10- upgrades.

>> 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.
> 

OK so in summary (to check my current understanding is correct) with 2.1.11 the problem is much reduced, since it can detect older "standard socket" agents. The problem remains when older "non-standard-socket" agents are used by gpg1, because gpg2 can't detect that, it will auto-migrate, then both agents will be active.

As I understand, the newer agent will use private-keys-v1.d when connected-to by gpg2 and secring.gpg when connected-to by gpg1 (*). This surprises me, but you can check this yourself with `gpg -K` against a v21-migrated gnupghome and a 2.1 agent.

So then there is only a problem when there are two active agents pointing to the same secring.gpg, since they might clobber each other or something.

This is something we can communicate in NEWS.Debian. In any circumstance (outside of the bug) we should already be advising to users about (*) which is initially surprising but I guess makes sense for compatibility reasons.

An additional thing we could do is, during the upgrade, go through $(pstree), check /proc/$pid/environ if GPG_AGENT_INFO is set, and if that agent is still active as a process, and if so then emit that debconf UI alert. Or, gpg2 could do this itself for the user's own processes, but I don't know if wk would accept such complex code for such a minor scenario.

I don't have any better ideas at this time either...

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git