Re: gnome-keyring Short introduction

[Michael Leupold <lemma confuego org>]

(Sorry, I forgot to hit reply to all on my first mail, reposting this one. 
Hope that's ok for you Stef)

On Thursday 19 February 2009 17:00:04 Stef wrote:
> Michael Leupold wrote:
> > On Thursday 19 February 2009 10:44:56 Stef wrote:
> >> It'd be cool to somehow get a more standard DBus protocol going. But
> >> there are a few issues:
> >>
> >>  * Transferring secrets in non-pageable memory.
> >>  * Validating credentials of the peer.
> >
> > One thing I disliked so far is that you can only unmarshal operations and
> > daemon results if you know what you expect. This means that I have to
> > unmarshal the results based on the operation I sent (which I have to
> > remember because it isn't in the result either). It's not a big deal
> > though and wasn't hard to work around.
> >
> > Apart from that the wire protocol doesn't seem to be that bad.
>
> Here are some more problems I see:
>
>  * Extensibility is a problem. Especially if multiple client libraries
>    implement the protocol, we'll be locked into doing things a certain
>    way forever. There are already changes I'd like to make. There's
>    really no versioning in the gnome-keyring protocol.

I'm not sure I completely understand what you mean. Do you mean DBus' innate 
ability to figure out if the receiver of a message will understand it?

Do you have some notes about which changes you're planning/would like to do?

>  * Discoverability is a problem. Uses an environment variable and unix
>    socket. This is mitigated somewhat by allowing the environment
>    variable to be queried over DBus.
>
>  * Mind share is a problem. It's hard to get people involved in
>    contributing code when we use an obscure protocol.

Agreed. Two more thing I like about a DBus interface:

* It's possible to signal clients. We do that in kwalletd to signal that a 
wallet has been forcefully closed (by the user).

* It will be easier to squeeze in changes to provide all current kwallet 
features so it could be seamlessly replaced (in case there's actually 
something that would have to be changed - not sure yet).

> > Of course DBus
> > is nice and easy to use (we use it exclusively in kwalletd) and it comes
> > with the additional benefit of not having to use a library to access the
> > daemon as well as command-line tools to help debugging. Unfortunately
> > your concerns are very valid. Peer credentials seem to be partly
> > implemented (getting the PID on platforms that support it). But then
> > there's also the problem that distributions currently seem to install
> > DBus with eavesdropping enabled - which means other applications can spy
> > on your secrets.
>
> Some possible solutions for the above problems with DBus:
>
>  * Use a key agreement protocol to establish session keys, and then
>    transfer secrets encrypted while in DBus.
>    Pros: Simple conceptually.
>    Cons: Complex practically, need libgcrypt or other crypto library
>          dependency.

That's one thing I've been thinking about as well. I'm don't know DBus on the 
glib side well enough to comment on complexity. Shouldn't be too hard on the 
Qt side (I'm already using a crypto library because that's where I get non-
pageable memory from).

>  * Use an additional socket for transferring secrets. Similar to how
>    gvfs uses additional sockets for transferring file data.
>    Pros: No crypto knowledge or implementation necessary.
>    Cons: Complicated conceptually.
>
> Any other thoughts?

I'm more in favour of the former DBus-only approach because it sounds easier 
to accomplish if there's several libraries implementing the protocol (key 
exchange + encrypted secrets sounds easier than maintaining several 
communication paths).

Regards,
Michael