Notes from the first OpenPGP Summit

[Robert J. Hansen]

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

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.

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.

> The solution is to enhance pinentry so that if GKR is available it 
> caches the password with GKR.

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150428/11961408/attachment.bin>