kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)

[Valentin Rusu]

On 08/21/2011 09:31 AM, todd rme wrote:
> 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?
I already started a sync tool named SecretSync that'll allow password
synchronization over several machines/terminals.
Google Chrome works with KWallet so it'll also work with KSecretsService.
Firefox KWallet plugin maintainship is stalled.
All these should use KWallet API or better switch to KSecretsService
Client.
> 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?
This is not yet defined.
> 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?
These are two different tools, each with it's own implementation and
maintainers.
> 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?
KDE KSecretsService API will connect to whatever daemon provides the
right interfaces on the DBus. So it'll be possible for a KDE application
to use gnome-keyring to store it's secrets. Ongoing work will define how
users will choose the daemon they want.

Valentin

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