Hi,
As promised on IRC, here is the "spec" that Stef and I came up with
for saving passwords:
We use libsecret and the following schema:
const SecretSchema the_schema = {
"org.gnupg.Passphrase", SECRET_SCHEMA_NONE,
{
{ "stored-by", SECRET_SCHEMA_ATTRIBUTE_STRING },
{ "keygrip", SECRET_SCHEMA_ATTRIBUTE_STRING },
{ "NULL", 0 },
}
};
stored-by is the name of the application. For GnuPG's pinentry, this
is "GnuPG Pinentry". keygrip is the stable identifier for the key as
indicated by GPG Agent. (For our purposes, this identifier is opaque,
but it corresponds to the so-called keygrip, which is derived from the
actual key material and not the OpenPGP Key like the Key ID. The
reason we don't use the Key ID is that not all keys are OpenPGP Keys.
You can get the keygrip corresponding to your keys using 'gpg2
--with-keygrip --list-secret-keys'.)
In libstore, every password has a label, which is not interpreted, but
is presented to the user. The label should be composed as follows:
GnuPG: keygrip
Where keygrip is again the value passed to the pinentry by GPG Agent.
If you are interested in GPG Agent's protocol for supporting external
password managers, see the pinentry manual. In particular:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=doc/pinentry.texi;h=ec6cc4f0036ad0ec904a662688d1bdeeb9912f87;hb=HEAD#l417
The basic idea is that GPG Agent indicates it supports an external
password cache ('OPTION allow-external-password-cache') and sends the
keygrip ('SETKEYINFO key-grip'). If the password manager reads the
password from the cache, then it indicates this to GPG Agent before
returning the password ('S PASSWORD_FROM_CACHE').
This last bit is essential. If the cached password is incorrect and
this is provided, then the retry counter is not incremented. If the
retry counter were 1, the cached password were incorrect and 'S
PASSWORD_FROM_CACHE' was not sent, then the user would never have a
chance to enter a new password!
Currently, GnuPG 2.1.4 (to be released very soon) and GnuPG's Pinentry
0.9.2 (also to be released very soon) to support the new protocol and
to optionally store the passwords in the external cache if the user so
chooses (at least using the GTK pinentry; the other pinentries
currently will check the cache, but will never store a passphrase).
The remaining bit is to backport the changes to GnuPG 2.0 and to
modify Gnome Keyring's pinentry to support the new protocol and to
excise the GPG Agent proxy.
Neal
At Thu, 07 May 2015 14:58:54 +0200,
Stef Walter wrote:
>
> On 06.05.2015 21:40, Neal H. Walfield wrote:
> > Hi,
> >
> > I'm implementing the password caching feature in gpg's pinentry so
> > that we can remove the gpg-agent proxy from gnome keyring.
> >
> > I've spent some time looking at Gnome Keyring and I'm a bit confused
> > about why Gnome Keyring is using gck to cache the password and not
> > libsecret. Any insight here would be appreciated.
> >
> > Also, if we want to continue to use the cached passwords, we need a
> > migration strategy. When GPG Agent invokes the pinentry, it now
> > provides a unique, stable ID. However, this ID is not the key id.
> > Thoughts?
>
> For anyone following along...
>
> After talking about this on IRC, Neal and I agreed that there doesn't
> seem to be a way to continue to use old cached passwords, at least not
> easily.
>
> The keyid provided to the old gpg-agent != the keygrip provided to the
> pinentry.
>
> Cheers,
>
> Stef
>
_______________________________________________
gnome-keyring-list mailing list
gnome-keyring-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-keyring-list
