single sign-on project

Kevin Krammer kevin.krammer at
Fri Oct 3 21:52:34 BST 2008

Hi Michael,

On Friday 03 October 2008, Michael Leupold wrote:

> I had a look at keyring which is the current daemon GNOME uses for this
> purpose. It's basically kwalletd with quite some additional features. For
> example it already offers unlocking client keys by having the possibility
> to act as a PKCS#11 provider. This means that applications like Firefox can
> already use client certificates provided by keyring. After having a (quick)
> look at the keyring code I think it could serve as a basis for a common
> daemon as it's well structured and the GUI dependant code is separate from
> the background stuff.
> What do you think about the general itinerary I should take? Do you think
> adopting keyring is a "no-go" or a valid option once certain circumstances
> are met?

My personal opinion is this:
you are the maintainer of the respective KDE side functionality and since you 
see the current GNOME implementation as a good starting point, it most likely 
is one.

> Personally I think having a common daemon should be the way to go. I
> wouldn't object to keyring and I'd even help working on it and getting it
> to where we need it. I am however concerned about the hit-by-a-bus factor
> (KDE-wise) and the fact that it might be hard to gather people to code on
> it in KDE as it's written in C/glib and unrelated to Qt.
> I wouldn't object to just specifying protocols either and building our own
> KDE-only daemon. I'd also contribute to that but as it's quite a lot more
> work we'd probably need more manpower.

As far as I understand the situation, the plan is to have several levels of 
specifications and use gnome-keyring as the starting point of a reference 

In which case the worst possible thing would be that we (as in general KDE 
developer community) would have to implement our own version of certain parts 
of the stack if the respective reference part becomes unmaintained.

I'd say the only real showstopper would be unwillingness to have shared 
maintenance, i.e. not giving commit access to motivated and trusted 
developers from our side or upfront insistance on implementation details we 
would most likely have a problem with [1].

Since it is currently not possible to add new projects at I 
suggest you ask the GNOME keyring maintainer if they would consider hosting 
the shared parts on their infrastructure for now [2] and ensuring you quickly 
get commit acccess to that.


[1] E.g. I don't see any problem in using things like GLib in the daemon, 
probably not even in a reference client lib, as long as we can do a Qt based 
client lib ourselves and protocol changes are not "dumped on us"

[2] probably an equivalent to our kdesupport module, though I think they 
prefer creating top level modules for independent projects.

Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list