kdeinit

[todd rme]

On Sun, Aug 21, 2011 at 12:09 AM, Valentin Rusu <kde at rusu.info> wrote:
> 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).

Great! This should be very helpful

A few general questions:

1. Will it be possible to add connections to password providers, like
online password management services or firefox, that allow those
passwords to be integrated with secretservice?  Or is this something
that would need to be handled at the frontend (ksecretserviced) level?

2. Is secretservice integrated with PAM so that the passwords can be
opened on login?  Or is this also something that needs to be handled
at the ksecretserviced level?

3. Will gnome-keyring and ksecretserviced by storing their passwords
in the same location or file(s), or will there need to be a separate
set of passwords for gnome-keyring and ksecretservicd?

4. If you are running gnome programs in a KDE workspace, or vice
versus, will they automatically connect to the right secretservice or
will they try to call their own backend?

-Todd