GNOME.org
 

gnome-keyring RGNOME keyring for Ubuntu/Mobile

On 2013-03-21 20:53, Stef Walter wrote:

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


IMO mobile devices need something else than GCR; they need a integrated
keystore and enrollment system.  The competition will have that at least:

http://webpki.org/papers/PKI/certenroll-features.pdf

This is running in a PoC format on Android.

To succeed you also need to bring in Mozilla who also work
with their own Mobile OS (which is lagging wrt user-keys).

I would be interested in working with this but I feel that
everybody is really waiting for Google since they are the
market leader in this space.

Anders



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

_______________________________________________
gnome-keyring-list mailing list
gnome-keyring-list gnome org
https://mail.gnome.org/mailman/listinfo/gnome-keyring-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]