Re: gnome-keyring GNOME keyring without Gtk+

[Stef Walter <stefw gnome org>]

FWIW, I'm moving toward a model where gnome-keyring is less monolithic,
with less dependencies, and better integrated with other stuff (think
using the actual the openssh agent, or the actual gnupg agent) rather
than replacing everything with our own implementation.

I'm not against collaborating on gnome-keyring with someone who has
non-GNOMEy goals, while at the same time I want to make sure we don't
give up on the integrated GNOME experience. I think we can accomplish this.

With just me working on it, progress on making gnome-keyring less
monolithic has been slow. We moved the GTK+ dependency out. Worked on a
standard DBus API for password retrieval. And continue to make progress
this release [0].

On 03/20/2013 10:51 AM, Alberto Mardegan wrote:
> Hi all!
>   I recently started a topic in the ubuntu-devel mailing list about what
> password storage to use on the Ubuntu phone and tablet images.
>
> I tried to summarise the discussion in this blueprint:
> https://blueprints.launchpad.net/ubuntu/+spec/mobile-s-password-storage
>
> I've been quickly looking into the GNOME keyring source code but there
> are some points which are still unclear to me, or that I'd like to confirm:
>
> - gnome-keyring-daemon does not depend on Gtk+, and could be used in an
> environment when Gtk+ or X11 are not present.

Right.

> - how does the gnome-keyring-daemon bring up its UI (for example, to ask
> the user to unlock the keyring)? According to what I found in the source
> code, there should be a gnome-keyring-ask-<version> program being
> spawned by the daemon when UI interactions are required, but I cannot
> find such a binary in my Ubuntu installation -- yet, I swear that I can
> see the keyring dialog prompting me to enter the master password.

It uses the GcrPrompt and GcrSystemPrompt [1] classes in the gcr
library. Parts of the gcr library depend on GTK+ and others do not. It's
been awkward doing this split, but I hope it is worth it in the long run.

GcrSystemPrompt has a implementor side: GcrSystemPrompter. [2] Both
gnome-shell and gcr-prompter use GcrSystemPrompter to provide prompts.
GcrSystemPrompt and GcrSystemPrompter use a dbus interface to communicate.

The gcr API is symmetric in that both sides use objects derived from
GcrPrompt.

The prompter dbus interface is (currently) an implementation detail.
It's a bit different than other dbus interfaces, in that we try to make
method returns be 'reliable'. That is: the process that responded back
to a caller over dbus should know whether that response reached the
other side or not.

This is because we're sharing a singleton system resource in an
exclusive manner, the system modal prompt. Only one process can prompt
at a time. I wanted to make sure that if a process crashed or hung, no
matter when in the dbus communication, we could be sure that the prompt
would go away, and the screen wouldn't stay 'locked' with a modal dialog.

The password is passed over dbus using GcrSecretExchange to prevent
accidental logging or paging to disk as it goes into dbus marshalling
and on the wire. [3]

> - related to the above; would it be possible to replace the Gtk+ UI with
> a Qt one? Is there a client library one can use to implement the UI service?

Yes, certainly. You can use gcr to do this. Use the gcr-base pkg-config
file, so you don't pull in a GTK+ dependency.

gcr supports introspection, but not sure if that helps toward making a
QT prompter.

> - would it be possible to make the daemon quit after some seconds of
> inactivity, or would this cause some undesirable side effects (would the
> master password be asked again?)?

This is certainly possible, but perhaps not for all use cases. The
master password would indeed be asked for again.

However I've been working on plans to make autologin work in a secure
but prompt-less manner by integrating with a TPM chip. This would allow
us to exit in that case, and then unlock the keyring using the TPM when
coming back.

> - are there plans to introduce some new dependencies or anyway changes
> which might have impact on using gnome-keyring-daemon in a non GNOME
> environment?

Not really. Although there will be probably be some logind integration,
to help gnome-keyring differentiate which clients are part of different
applications, and keep passwords from one another. But this could be
optional dependency.

Again the reason for this is because I'd like more steady non-me
contributions to gnome-keyring.

So if being open to steady contributors that want make gnome-keyring
work well to use in a non-GNOME environment is what it takes to get
contributors, then I'm willing to compromise on certain things that I
wouldn't otherwise care about if I had a GNOME only mindset.

Let's see if my gambit pays off, hint, hint... :D

> - does seahorse directly access the password storage, or is there some
> IPC protocol which the gnome-keyring-daemon exposes for password viewers?

It uses the same standard Secret Service API [3] that everyone (well
GNOME, KDE, Firefox soon [4], are using).

> Lots of questions, I know. :-)

That's fine.

> And there might be other things to consider which I missed. You are very
> welcome to comment here, or even adjust the blueprint if you think that
> some information there is not correct.

I hope that the above makes my interests clear. Again I'd love for
contributors who help work on gnome-keyring in a non-drive-code-dump
manner (actually we haven't even had many of those, heh heh), even when
those contributions are not GNOME specific.

Cheers,

Stef

[0]
https://git.gnome.org/browse/gnome-keyring/commit/?id=7afaae43f205c059163c3670169af302f1ba6de3

[1] https://developer.gnome.org/gcr/stable/GcrSystemPrompt.html

[2] https://developer.gnome.org/gcr/stable/GcrSystemPrompter.html

[3] https://developer.gnome.org/gcr/stable/GcrSecretExchange

[4] http://standards.freedesktop.org/secret-service/

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=309807