Akademy/2015/AllBoF/KSecret Service

This BoF for planning the features KSecret Service should have.

Context

KSecret Service development resumed this summer. It lives in the playground/utils/ksecrets. It was initially started several years ago by Lemma who worked on a Freedesktop.org standard draft with Stef Walter from Gnome. Here is the current draft : [1]

Gnome Keyring currently implements that draft. The KDE counterpart development was stopped because of kdelibs splitting into KF5. Meanwhile I took over this project, and now I'll have some time to work on it.

Also, since several years I'm the maintainer of KDE Wallet, for which I developed the GPG backend, and I now have a good grasp of issues along with user feedback.

Aim

I find the initial version of ksecrets a little bit over-engineered and I'd like to use this akademy to:

1. gather the requirements users have from ksecrets,

2. design a simple yet secure architecture, avoiding dbus if possible ; the dbus interface should only be published for non-kde applications

3. put together a roadmap

4. decide how to migrate from KWallet to KSecret Service and how both should live on user systems during the transition phase

Current design decisions

1. automatically unlock the secrets upon session start ; that can be made possible by the use of a :

- pam-ksecrets module - this one is already implemented

- kernel keyring interface - the pam-ksecrets module computes the unlocking keys and puts them here ; a dedicated library will then use these keys - read on.

2. KDE applications use an API (a framework?) that can be configured to either use KSecret Service backend or the gnome-keyring ; currently, this API would connect to dbus to find the KSecret Service daemon ; I plan to change that and only provide the daemon for the non-KDE applications connecting via the freedesktop.org-specified interface

3. Use simple library to handle a secrets file ; that library will be used by both the API and the daemon ; that library relies on the presence of the pre-computed keys into the "kernel keyring".

4. The location of the secrets file should be user-configurable ; that would allow it's synchronization via owncloud, for example, and would avoid us the need to develop a dedicated sync application.

You're welcome to attend and tell me about your ideas or suggestions.