kdeinit

[Valentin Rusu]

On 08/20/2011 02:11 PM, Oswald Buddenhagen wrote:
>> A cross-desktop specification, but we still use kwallet. There's no reason to 
>> dump it in favour of another implementation. So I see no arguments at all in 
>> favour of dropping it -- in fact, I see more in keeping it.
>>
> ksecretservice is a new implementation. dunno how much code was reused.
> the arguments against two backends are easy:
> - two backends means almost twice the work, including security auditing
> - assuming the backends use different storage (it's not part of the
>   spec, after all), even after switching desktops you need to stick with
>   the now "alien" password manager.
KSecretsService is a new implementation. It has a new backend that
organizes secrets in collections and follows the freedesktop.org
specification. KDE applications will use the new KSecretsService client
library that'll replace KWallet API. I'm currently rewriting the KWallet
class in order to get it use this new KSecretsService Client API. The
backend (or daemon) will also be able to import kwallet files. So in the
future the kwalletd will become useless.

The KSecretsService Client API will be able to connect to whatever
service will expose the freedesktop.org secrets service specification on
the DBus. That means that KDE applications will be able to store
passwords in gnome-keyring if present instead or ksecretsserviced (this
is the name of the daemon exposing fd.o secrets specification currently
under development).

-- 
Valentin Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)