Bug 313216

KSecretsService will indeed provide many useful features as those you mention. It's central piece is the API that'll replace KWallet API, in kdelibs. Only, kdelibs development is frozen right now. This was decided by the core development team during the 2011 June meeting, in Randa. A big kdelibs splitting effort was then started, adjusting them (if not rewriting parts of it) to prepare the QT5 move. kdelibs will no longer be that big, monolythical piece of software but will morph into a layered structure of frameworks - that's why it'll be called KDE Frameworks 5 or KF5. I was invited to join these efforts and I'm currently helping this splitting effort, during my extra-work hours. Please see this page for more information:
http://community.kde.org/Frameworks

As you may know, QT5 is now here. We now must finish splitting kdelibs and release KF5. Once KF5 will be out, KSecretsService integration will be only a matter of time, as new features addition will become possible. Having a working KF5 system will let us (you, dear reader, included) test it, polish it and get it done!

Meanwhile, I'd like to let you know that I'm also working on other wallet related tools. For instance, I'm now refactoring the KWalletManager user interface. This kind enhancement will be compatible with KDE 4.x. It's in a very early stage but the work is advancing smoothely, so I'll soon get in touch with kdeutils maintainers for review and release plan.

I hope I was clear explaining this. However, please feel free to ask further questions if details should be explained further. Also, do net hesitate to add your suggestions here.

Your help is welcome. If you're not a programmer, then you may help testing, but also writing good documentation for the service. Let's keep in touch for that.

I am not a programmer, but I am advanced linux and kde user, and I want to help you with testing. Where can I see the progress of kwallet development and how I can help you with testing?

I use fresh Kubuntu with latest KDE installed via ppa (starts from alpha or beta versions), so I can test new pre-released features and report bugs. You can contact me via mail murznn at gmail.com

As written in comment #1, KSecretsService will only make its debut in KF5. You could learn how to build current development snapshots of Qt5 and KF5. This would be a prerequisite to help testing KSecretsService, when it is going to be ported to Qt5 and KF5.

For more information, see http://community.kde.org/Frameworks

If you have questions for the steps mentioned there, join the kde-frameworks developer mailing list to ask them.

what’s going on? KF5 is out and stable!

Well, yes, KF5 is out and stable. It's me not having time for this, as I'm doing KDE during my spare time, after returning from work. However, I think I could start working on this in about 1 or 2 months, as the situation will change.

 Valentin Rusu, thanks for the info, I am not a programmer, but want to help you with testing new KDE Wallet features, at first - syncing between computers.

Please be informed about the advancement of the project.
https://community.kde.org/Akademy/2015/AllBoF/KSecret_Service

Ah great, I see you’ve uploaded the slides/slide-outline!

> Only needed when someone forgot some application-stored password?

Yeah, but for that i need it sometimes, mainly because of flakiness of other stuff: Connecting to some server via SFTP makes dolphin(?) constantly ask for my private key password, elsewhere “remember password” doesns’t work, …

As long as that stuff isn’t rock solid, we definitely need a relatively easy way to enumerate passwords.

Is there any improvements about KSecretService in fresh KDE releases?

kwallet repeatedly asks for the password, e.g. when another program starts. ksecretservice as replacement will hopefully use the login credentials. When can we poor ordinary users have it? It would be great, if you could release a working version and improve it later. User feedback should then help guide your improvement efforts, once we have a chance to actually use it.

kwallet can use login credentials, if you have pam-kwallet installed/enabled

Yes - maybe. But it is far from straight forward. I tried to enable it on Kubuntu 15.10 -> no success. Haven't tried with 16.04 yet. Is there a how-to for Kubuntu 16.04 somewhere?

Hey,

It's 2018 already :)

Can we have some more info on this one? I think this is not working, at least in Kubuntu 18.04 daily.

I'm trying the Remmina client and it says this:

** Message: 11:14:16.974: Remote error from secret service: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files

Sorry: failed to say that Kwallet is enabled and opened, yet Remmina keeps printing the same error. Is "secrets" service enabled and working in KWallet?

org.freedesktop.secrets Required by microsoft docker vscode extension and most probably Skype, so I wish it will be implemeted soon.

Why not just use `gnome-keyring-daemon` on KDE? I mean as a standard KDE plasma desktop component not as a every-user-for-himself bolted on top thing, of course.

It comes with no “exciting” dependencies (GIO, GLib, gnuTLS & libcap-ng, as well as GSettings+DConf [some people may object to this, I know] and p11-kit [for smartcards]). Some user-facing utilities (gcr-prompter, gcr-ssh-askpass & pinentry-gnome3) do depend on GTK+3 but these can easily be replaced where this hasn't already happened (pinentry-qt). The biggy left for this approach is of course the frontend (seahorse), but this could be done incrementally: start with a basic “show my passwords” UI, then extend it as users keep asking for other stuff.

(In reply to Alexander Schlarb from comment #16)
> Why not just use `gnome-keyring-daemon` on KDE? I mean as a standard KDE
> plasma desktop component not as a every-user-for-himself bolted on top
> thing, of course.

Why not use 'KeePass' instead and have it integrated into the KDE ecosystem?

With people using different platforms (smartphone, tablet, Windows, Linux) on different devices concurrently, it would be smarter to have a credentials storage that works across devices and platforms. A platform-specific solution, even if it works with Gnome _and_ KDE, but only on Linux, is a bit outdated. KeePass is available for all relevant platforms and has thus become a de-facto standard. It also offers the benefit of storing the (endcrypted) credentials database in a cloud storage, such that the same data is available across all devices.

+1 for using KeyPassXC (which is even implemented using Qt5 in case you're wondering) as default provider. It's still lacking libsecret support as well through (https://github.com/keepassxreboot/keepassxc/issues/1403), but doing the work there has the possibility of potentially benefiting a lot more users as Syaid correctly observed.

My impression is that system-level credential storage is usually used to save tokens. They are sensitive enough to be stored _somewhere_ better than scattered text files, but still not too important that you want to carry around and go through a long threat model analysis to protect it. It just appears to me that the focus should be lightweight and uniformed, rather than having as many features as a modern password manager.

keepassxc version 2.5.0 has been release and offers a org.freedesktop.secrets service now! It would be great if applications would prefer to check org.freedesktop.secrets first before trying org.kde.kwalletd5!

The solution would probably that KDE starts to use

https://github.com/frankosterfeld/qtkeychain

Another vote for KeePassXC and and even maybe adding it to the KDE ecosystem.

+1
and add a PAM module for keepassxc, to enable opening the last used database at login.

just a copy and past to this post https://forum.kde.org/viewtopic.php?f=15&t=156925 so as to renew the quetion related to kwallet and secret service: 

' What is the status of KWallet development now in KDE? Does it have a developer, that plan to improve it? Main problem for me is missing sync passwords between different Linux systems.

KWallet sync feature was planned many years ago, but still no progress.

Workarounds via manually syncing kwallet.kwl file got more problems, that profit, here is detailed description: https://bugs.kde.org/show_bug.cgi?id=403648

Also there was be plans to implement KSecretService as replacement to KWallet https://community.kde.org/KSecretService but seems it also stopped.

Now Linux have those popular password storage implementations:

    KDE use KWallet that missing sync feature
    Gnome Keyring use Secret Service - https://specifications.freedesktop.org/secret-service/
    pass, named as "the standard unix password manager" - https://www.passwordstore.org/ with QtPass GUI https://qtpass.org/
    KeePassXC https://github.com/keepassxreboot/keepassxc that try to implement support for libsecret/DBus https://github.com/keepassxreboot/keepassxc/issues/1403
    Qt apps use QtKeychain as API to access system password storage


If KWallet development was stopped and no plan to improve it, which project we can recommend to select as alternative?  '

*** Bug 425561 has been marked as a duplicate of this bug. ***

I don't believe this task is still assigned to Valentin Rusu. Please feel to revert if you disagree.

Really want this feature!

Nowadays, all Electron applications depends on org.freedesktop.secrets and I have to install GNOME Keyrings to make it work.

@Guo Yunhe: I'm not sure if you are aware, but you could use KeePassXC instead as it implements the org.freedesktop.Secrets API since 2.5 and does a good job at it. It's database can also be synced without any issues.

I would really appreciate any update from anybody related in any position to the KSecretService project. Also, I would appreciate answers to the following questions: (If they sound like they are written by somebody who feels like there is little future for the existing KWallet/KSecretService plans then that is just my personal bias, definitely prove me wrong if you feel this to be unjust sentiment!)


From what I can tell, this project is dead, never had a working release and at this point it does not appear as if anybody is interested in picking it up again; is this observation accurate?

And if that is indeed the case: Are future plans focused entirely around maintaining the existing KWallet system or is there any plans / interest beyond mere “+1”s to extend/replace that ecosystem with something else?

Finally, how would you feel about replacing the existing KWallet daemon with a proxy implementation that forwards all calls on the KWallet D-Bus API to org.freedesktop.Secrets/KeePassXC? At this point we're back to “+1”s of course, but if done properly, KWalletManager and all existing KWallet clients should continue to work and, as a future endeavour, KeePassXC could be stripped of its GUI and simply run as a daemon in the background while supporting the well-established KDBX2 database format with native sync support, as well as having browser integration and of course the org.freedesktop.Secrets API.

We didn't find a new contributor to continue KSecretService and/or rework KWallet to improve it or integrate it with other password wallet solutions.

*** Bug 430462 has been marked as a duplicate of this bug. ***

(In reply to Alexander Schlarb from comment #29)

> Finally, how would you feel about replacing the existing KWallet daemon with
> a proxy implementation that forwards all calls on the KWallet D-Bus API to
> org.freedesktop.Secrets/KeePassXC? At this point we're back to “+1”s of
> course, but if done properly, KWalletManager and all existing KWallet
> clients should continue to work and, as a future endeavour, KeePassXC could
> be stripped of its GUI and simply run as a daemon in the background while
> supporting the well-established KDBX2 database format with native sync
> support, as well as having browser integration and of course the
> org.freedesktop.Secrets API.
This could break usescases that use GPG to encrypt the password database.

(In reply to Thaodan from comment #32)
> (In reply to Alexander Schlarb from comment #29)
> 
> > Finally, how would you feel about replacing the existing KWallet daemon with
> > a proxy implementation that forwards all calls on the KWallet D-Bus API to
> > org.freedesktop.Secrets/KeePassXC? At this point we're back to “+1”s of
> > course, but if done properly, KWalletManager and all existing KWallet
> > clients should continue to work and, as a future endeavour, KeePassXC could
> > be stripped of its GUI and simply run as a daemon in the background while
> > supporting the well-established KDBX2 database format with native sync
> > support, as well as having browser integration and of course the
> > org.freedesktop.Secrets API.
> This could break usescases that use GPG to encrypt the password database.

I see, didn't know KWallet could do that. Is this a blocker though? When do people actually use this option over master passwords (and especially the auto-unlock with login password option)?

(In reply to Alexander Schlarb from comment #33)
> (In reply to Thaodan from comment #32)
> > (In reply to Alexander Schlarb from comment #29)
> > 
> > > Finally, how would you feel about replacing the existing KWallet daemon with
> > > a proxy implementation that forwards all calls on the KWallet D-Bus API to
> > > org.freedesktop.Secrets/KeePassXC? At this point we're back to “+1”s of
> > > course, but if done properly, KWalletManager and all existing KWallet
> > > clients should continue to work and, as a future endeavour, KeePassXC could
> > > be stripped of its GUI and simply run as a daemon in the background while
> > > supporting the well-established KDBX2 database format with native sync
> > > support, as well as having browser integration and of course the
> > > org.freedesktop.Secrets API.
> > This could break usescases that use GPG to encrypt the password database.
> 
> I see, didn't know KWallet could do that. Is this a blocker though? When do
> people actually use this option over master passwords (and especially the
> auto-unlock with login password option)?

When they want to secure the wallet by more then a password, especially when the authentication method is separate from the computer e.g. on smartcard.
This also allows to cache the authentication to limit the time the wallet can be opened without opening the authentication method again.

This is also a part of a central authentication with a key instead of a password and allows physical separation from the device that requests the authentication and they one that stores the secret that is unlocked.
This then allows to remove the physical token when the user leaves the computer.

https://invent.kde.org/frameworks/kwallet/-/merge_requests/11

(In reply to soredake from comment #35)
> https://invent.kde.org/frameworks/kwallet/-/merge_requests/11

This has now been merged and released in KDE Frameworks 5.97.0. This can probably be marked as resolved.

*** Bug 234434 has been marked as a duplicate of this bug. ***

(In reply to Björn Bidar (Thaodan) from comment #34)
> (In reply to Alexander Schlarb from comment #33)
> > (In reply to Thaodan from comment #32)
> > > (In reply to Alexander Schlarb from comment #29)
> > > 
> > > > Finally, how would you feel about replacing the existing KWallet daemon with
> > > > a proxy implementation that forwards all calls on the KWallet D-Bus API to
> > > > org.freedesktop.Secrets/KeePassXC? ...
> > >
> > > This could break usescases that use GPG to encrypt the password database.
> > 
> > I see, didn't know KWallet could do that. Is this a blocker though? When do
> > people actually use this option over master passwords (and especially the
> > auto-unlock with login password option)?
> 
> When they want to secure the wallet by more then a password, especially when
> the authentication method is separate from the computer e.g. on smartcard.
> This also allows to cache the authentication to limit the time the wallet
> can be opened without opening the authentication method again.
> 
> This is also a part of a central authentication with a key instead of a
> password and allows physical separation from the device that requests the
> authentication and they one that stores the secret that is unlocked.
> This then allows to remove the physical token when the user leaves the
> computer.

If KWallet daemon is replaced by a proxy forwarding to KeePassXC (or some other Secret Service provider), then encryption is handled by the Secret Service provider, so GPG is no longer needed. Of course, the user would have to choose, either use the full KWallet + GPG, or proxy + Secret Service backend. A similar idea was proposed in https://github.com/keepassxreboot/keepassxc/issues/3679#issuecomment-578498231 .

Specifically KeePassXC already supports using an external key file or device (YubiKey et al) as one of the DB credentials. It has configurable auto-lock time limit. There are also plans for QuickUnlock using PIN or fingerprint, though not yet supported on Linux. So I think KeePassXC already covers the GPG use case.

However, we're now seeing this issue with the new native support for Secret Service API in KWallet Framework 5.97.0: see Bug 458085 comment 13.

(In reply to michaelk83 from comment #36)
> (In reply to soredake from comment #35)
> > https://invent.kde.org/frameworks/kwallet/-/merge_requests/11
> 
> This has now been merged and released in KDE Frameworks 5.97.0. This can
> probably be marked as resolved.

After more testing, it looks like the implementation is still broken/incomplete in a few places. See the blockers for Bug 458318, among lesser issues.