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 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
