Unifying KWallet/Gnome-Keyring

[nf2]

As you might have read, i'm doing some experimental work on unifying 
desktop network transparent file-management. It's called KIO-GIOBridge 
and makes KIO partially use the new GIO/GVFS system.

(The code is here: 
http://websvn.kde.org/trunk/playground/ioslaves/kio-giobridge/)

To make GIO/GVFS attractive for KDE, of course dependencies are an 
issue. Apart from some - probably easier to resolve GConf depencencies 
in GIO/GVFS) - the gnome-keyring dependency might be seen as a disadvantage.

As having a single passwords/secrets storage might be interesting for 
other reasons anyway (single-sign-on), it might be reasonable trying to 
"unify" KWallet and Keyring, rather than having a switchable DAPI style 
interface into both systems.

To get an idea how KWallet and Keyring are designed and might/might not 
fit together, i started playing with the KWallet/Keyring APIs and data 
models by trying to write a KWallet client implementation on top of the 
keyring-client library.

(code is here: http://websvn.kde.org/trunk/playground/libs/kwalletkeyring/)

Why not the other way round?

* There are already two implementations which people are quite happy 
with - thus there might be lack of motivation writing a third one. So 
it's more-less just flipping the coin and "recycling" one existing 
implementation.

* Keyring is a bit ahead with some security features (ACL on item 
level). They might not be extremely important, but still nice to have.

* This also applies to having key/value maps for defining and looking up 
items (KWallet uses a single string key).

* Keyring-daemon already has the GUI parts separated.

What i found out:  It would be possible to fit KWallets data-model into 
Keyrings data-model (as a subset, using a "kwallet." prefix for 
keyring-names and item-attribute names)... A kind of migration strategy 
- KDE applications could still use the KWallet API, but with only a 
single keyring-deamon process necessary for managing the storage. If KDE 
applications want to share entries with GNOME/3rd party apps they would 
probably have to switch to a new API.

As always - the devil is in the details - for instance KWallet and 
Keyring differ in which operations are async and therefore may trigger a 
dialog. Furthermore KWallet emits change-notifications, but i guess this 
might be a "nice to have" in Keyring anyway.

With my limited knowledge about this topic - i tried to put together a 
list of todo's for both "sides" (i'm sure there are more issues, looking 
forward for your comments).


Gnome-Keyring:
==============

To start with:
--------------

* allow creating keyrings with acl on keyring level (not on item level)
  add a keyring-flags field to keyring-info to optionally enable this
  when creating a keyring.
  (this is required, because the KWallet API only provides async-open,
  but all the functions to retrieve keys are sync-only and therefore may not
  trigger a dialog)

* change notifications: emit D-Bus signals:
 
  + "keyring-changed" with the args:
    - keyring-name
    - change-type: created/deleted
 
  + "item-changed" with the args:
    - keyring-name
    - item-id
    - change-type: created/modified/deleted

* peek function: checks if a certain item/attribute/value combination exist,
  bypassing the ACL. this feature can be enabled in the keyring flags.
  (required to implement the Wallet::folderDoesNotExist() and 
keyDoesNotExist() methods in KWallet.


later:
------

* remove GConf dependency (just stumbled over it - but don't know what 
it's for).

* Change storage path for keyrings to $XDG_DATA_HOME/keyrings

* Standardize binary application to keyring-daemon p2p protocol (or use 
D-Bus p2p?)

* Allow advanced data structures in the "secret" area of items (similar 
the attributes-list)

* Switchable GUI dialogs depending on the currently running desktop
  (an optional kde-keyring-ask executable)

* Make Keyring portable to other platforms

* Improve search functions - support wildcards (maybe)

* change namespace in keyring-client from "gnome_keyring" to "keyring" 
or "gkr"



KDE TODOs
=========


To start with:
--------------

* KWallet implementation which uses Keyring as backend. Maps the KWallet
  data model into the keyring data model.
 
  - keyring names: prefixed with "kwallet."
 
  - item attribute names:
          "kwallet.folder" = folder-name (string)
          "kwallet.key"  = key-name (string)
          "kwallet.type" = Wallet::EntryType (uint32)
 
          1) passwords
              "kwallet.password" = value
 
          2) maps:
              "kwallet.mapentry.{KEY}" (multi) = value (string)
           
          3) binary
              "kwallet.base64data"   = base64 encoded value (string)

later:
------

* Qt/C++ Keyring API -> to get the full Keyring features
  and share content with GNOME/3rd party apps

* Migrate the KWallet-Manager to the Keyring model

* Implement Keyring Dialogs in Qt/C++
 
* Migrate apps
 

if required:
--------------

* Write a pure Qt/C++ client for Keyring - which doesn't link the 
gnome-keyring client

* Write a pure Qt/C++ Keyring daemon implementation (if required)


Cheers,
Norbert