Storing desktopcouch keys: discussion
Stuart Langridge
OAuth, using the randomly-generated OAuth key. The question is: where
should these keys be stored, and how do libraries using desktopcouch get
at them?
Before we start: users and application developers should never, ever
have to care about this question. This should be taken care of by the
library that you're using to access desktopcouch (desktopcouch.records
for Python; couchdb-glib for C; and so on). If ordinary people or
ordinary application developers have to think about this, we're doing it
wrong.
Possible approaches:
1. Generate the key and store it in the desktopcouch ini file. Libraries
parse the ini file to get the key.
Pros:
* only one place to store the key
* since the ini file is the only place, the ini file (which desktopcouch
itself uses) and the storage location never get out of sync
* it's trivially cross platform
* even if you store the keys in a keyring, they've gotta be in the ini
file *anyway*, because that's what CouchDB reads
Cons:
* parsing ini files is notoriously breakable
* keys are secret information. Secret information should be stored in a
platform-specific keyring; this is what platform-specific keyrings are
*for*, because the keyring people care about things like security of the
keys
* You can't revoke access to the key on an application-by-application basis
2. Store the key in the Gnome keyring. Libraries access the Gnome
keyring to get the key. (This is what we do right now.)
Pros:
* Keys stored in a secure location and accessed from that secure location
* You can revoke an application's access to the key without revoking
other applications
Cons:
* totally, totally Gnome-specific. This completely scuppers the idea of
desktopcouch being cross-platform (on KDE, Windows, Mac, Android, etc,
etc), which is why we're looking to not do it
3. Use the python-keyring module (http://pypi.python.org/pypi/keyring)
to store the key in the most appropriate local keyring; python-keyring
uses the Gnome keyring on Gnome; KWallet on KDE; the Keychain on the
Mac; etc. Libraries...well, see below.
Pros:
* all the benefits of using the Gnome keyring, above
Cons:
* python-keyring only exists for Python. So it's fine for desktopcouch
*storing* the key (because desktopcouch itself is Python), and it's fine
for Python consumers (using desktopcouch-records). People writing apps
in C or JavaScript or Vala are SOL, though. This suggests that creating
a new desktopcouch library for a new language (as was done with
couchdb-glib) would also need to include a that-language port of
python-keyring. Ouch.
* Upstream don't seem very responsive
* by definition, python-keyring is a lowest-common-denominator approach,
so if a particular keyring offers facilities that other keyrings don't
(like, say, naming the key, or storing multi-part keys) you don't get to
use that in python-keyring; this is a problem because...how do you know
how to retrieve a desktopcouch key?
4. something else (your suggestions welcomed)
sil
Rodrigo Moya
> On Mon, Jan 18, 2010 at 11:15 AM, Rodney Dawes
> <rodney...@canonical.com> wrote:
> > 4b) A dbus method in desktopcouch to get the oauth token, or better, to
> > just sign the request. Why don't we have DBus interfaces for everything
> > desktopcouch does? It sure beats rewriting the same stuff in every
> > language.
>
> This option seems quite good.
yes, +1 from me
Stuart Langridge
> 4b) A dbus method in desktopcouch to get the oauth token, or better, to
> just sign the request. Why don't we have DBus interfaces for everything
> desktopcouch does? It sure beats rewriting the same stuff in every
> language.
Because there is no D-Bus on Mac and Windows.
The point of python-keyring is that it abstracts across platform
keyrings. Moving to D-Bus abstracts across gnome-keyring and KWallet.
They are not the same thing.
sil
Stuart Langridge
>> The point of python-keyring is that it abstracts across platform
>> keyrings. Moving to D-Bus abstracts across gnome-keyring and KWallet.
>> They are not the same thing.
>
> so unless you write a custom abstraction under the DBus API to only use
> gnome-keyring and KWallet, then it can do other things. For instance,
> desktopcouch could do all the OAuth signing and communication, and use
> python-keyring to do so, but provide that API via DBus, so that anything
> in any language can call it. And it can support any keyring on any
> platform.
Aha, sneaky. I see what you mean, now. So desktopcouch itself, which is
written in Python, uses python-keyring to store and retrieve keys from
the appropriate local keystore, and exposes a separate "get a key" API
using the appropriate local IPC mechanism?
That makes sense.
Yay abstraction!
sil
Mikkel Kamstrup Erlandsen
Taking up an oldish thread...
I don't see http://www.freedesktop.org/wiki/Specifications/secret-storage-spec
mentioned in this discussion? I realize that it's not fully mature
yet, but afaik Gnome-keyring will have support for it in 2.30 - but
this needs to be verified.
--
Cheers,
Mikkel
Manuel de la Peña
--
You received this message because you are subscribed to the Google Groups "Desktop CouchDB" group.
To post to this group, send email to desktop...@googlegroups.com.
To unsubscribe from this group, send email to desktop-couch...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/desktop-couchdb?hl=en.