On 08/21/2011 09:31 AM, todd rme wrote: > On Sun, Aug 21, 2011 at 12:09 AM, Valentin Rusu <[email protected]> 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)
