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

Valentin Rusu kde at rusu.info
Mon Aug 22 18:41:30 BST 2011

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
> 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
> 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 Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)

More information about the kde-core-devel mailing list