Notes from the first OpenPGP Summit

Neal H. Walfield neal at
Tue Apr 28 17:02:12 CEST 2015

At Tue, 28 Apr 2015 10:26:05 -0400,
Robert J. Hansen wrote:
> > The solution is to fix Gnome Keyring :).  I've spoken with Stef, the
> > main developer of GKR, and he confirmed that the only reason GKR 
> > MITMs GPG Agent is so that it can intercept prompts for the password 
> > to supply any cached value.
> This doesn't seem like a good reason.  It never has.  If I configure
> gpg-agent to cache for 20 minutes, but forget to configure
> gnome-keyring-daemon, then it's possible that 25 minutes later I'll do
> something requiring a passphrase, gpg-agent will ask me for my
> passphrase, but gnome-keyring-daemon will silently intercept it and use
> the cached value, etc., etc., leaving me wondering why gpg-agent isn't
> respecting the timeout I've given it.

I've added a checkbox to pinentry that asks: "Cache password with GKR"
and it is only shown if GKR is present.  So it's opt-in.

> This also means passphrases are cached in two places, not one -- in
> gpg-agent and in gnome-keyring-daemon.  In my day job I work in digital
> forensics, with a good bit of memory forensics work in my past.
> Speaking as a forensicist, if you keep two copies of a sensitive
> passphrase in memory you're making things much easier for me.

There are so many attack vectors that providing this opt-in hardly
seems to make a difference to me.  If we actually had process
isolation, I might agree with you.  But, as things stand, we don't.  I
wouldn't allow GKR to cache my passphrase either, but other people
disagree.  In particular, the maintainer of GKR, which is widely used
and practically a hard requirement even on Xfce.

> I don't understand GKD's choices here.  I never have.  They've always
> seemed foolish.  If GKD wants to implement gpg-agent's protocol and run
> as a replacement gpg-agent, that's one thing... but the current setup
> just does not strike me as wise.

I don't understand this "if".  GKR is implementing (a subset of) gpg
agent's protocol.

> I'm sorry, but I don't think this is a good solution.  GNOME is asking
> for privileges other desktop environments haven't asked for and don't
> get. KDE doesn't get KDE-specific functionality added to pinentry.  Nor
> does XFCE, nor does Enlightenment.  If GNOME gets to have GNOME-specific
> enhancements folded into GnuPG, then what's to prevent KDE, XFCE,
> Enlightenment, Windows, OS X, and all other desktop environments from
> demanding the same?

Actually, the secrets API is a desktop standard and I was told KWallet
speaks it.  So, this enhancement will work with KWallet as well.
Also, the GPG Tools people (Mac OS) do something similar to GKR (but
less invasive) so the modifications to the gpg core will help them as


More information about the Gnupg-users mailing list