Bug 313216 - Release a working version of KSecretService
Summary: Release a working version of KSecretService
Status: CONFIRMED
Alias: None
Product: ksecretsservice
Classification: Unclassified
Component: Daemon (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist with 300 votes (vote)
Target Milestone: ---
Assignee: Valentin Rusu
URL:
Keywords:
: 425561 430462 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-01-14 07:38 UTC by Murz
Modified: 2022-07-29 20:22 UTC (History)
35 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Murz 2013-01-14 07:38:15 UTC
KSecretService is greatly improvement of kwallet service, and it will implement sync feature, gnome keyring comparability.

It is announced in KDE 4.8, but from that time there are no news about this project.

What is current development status of it and is there any changes to see some working
version in upcoming KDE 4.11 release?

There are some threads about KSecretService status:
https://bugs.launchpad.net/kubuntu-ppa/+bug/934448
http://www.kubuntuforums.net/showthread.php?57081-KSecretService-in-KDE-Wallet-4-8
http://www.kubuntuforums.net/showthread.php?59156-KSecretService-KSecrets-KDE-4-9

So I open this wishlist for informing users about current status of developing KSecretServiceD and client.

Is continue developing of KSecretService planned? What are release blockers and how community can help to solve them?

I want to help you with developing, but don't know C++ language, so I can help you with bug-testing and other things, please ask me if I can help with something.
Comment 1 Valentin Rusu 2013-01-14 21:40:30 UTC
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.
Comment 2 Murz 2013-07-11 10:28:21 UTC
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
Comment 3 Christoph Feck 2013-07-19 02:17:29 UTC
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.
Comment 4 Philipp A. 2015-03-10 08:08:38 UTC
what’s going on? KF5 is out and stable!
Comment 5 Valentin Rusu 2015-03-10 20:25:47 UTC
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.
Comment 6 Murz 2015-03-11 06:39:49 UTC
 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.
Comment 7 Valentin Rusu 2015-08-04 17:14:45 UTC
Please be informed about the advancement of the project.
https://community.kde.org/Akademy/2015/AllBoF/KSecret_Service
Comment 8 Philipp A. 2015-08-14 08:56:28 UTC
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.
Comment 9 Murz 2016-04-12 08:18:28 UTC
Is there any improvements about KSecretService in fresh KDE releases?
Comment 10 Syiad 2016-05-21 20:16:34 UTC
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.
Comment 11 Rex Dieter 2016-05-21 20:23:41 UTC
kwallet can use login credentials, if you have pam-kwallet installed/enabled
Comment 12 Syiad 2016-06-10 09:43:02 UTC
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?
Comment 13 Luis Miguel García Mancebo 2018-03-13 10:25:31 UTC
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
Comment 14 Luis Miguel García Mancebo 2018-03-13 10:27:05 UTC
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?
Comment 15 Yan 2019-01-17 12:45:09 UTC
org.freedesktop.secrets Required by microsoft docker vscode extension and most probably Skype, so I wish it will be implemeted soon.
Comment 16 Alexander Schlarb 2019-01-19 18:28:10 UTC
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.
Comment 17 Syiad 2019-01-20 17:45:19 UTC
(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.
Comment 18 Alexander Schlarb 2019-01-20 18:29:33 UTC
+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.
Comment 19 61.1p57 2019-04-09 02:22:50 UTC
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.
Comment 20 Andreas Schneider 2019-10-27 08:51:56 UTC
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!
Comment 21 Andreas Schneider 2019-10-27 14:52:37 UTC
The solution would probably that KDE starts to use

https://github.com/frankosterfeld/qtkeychain
Comment 22 hoperidesalone 2019-10-28 16:12:03 UTC
Another vote for KeePassXC and and even maybe adding it to the KDE ecosystem.
Comment 23 Syiad 2019-10-28 17:13:08 UTC
+1
and add a PAM module for keepassxc, to enable opening the last used database at login.
Comment 24 Cherkah 2019-12-14 09:14:28 UTC
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?  '
Comment 25 Christoph Feck 2020-09-03 11:43:27 UTC
*** Bug 425561 has been marked as a duplicate of this bug. ***
Comment 26 postix 2020-09-03 12:19:31 UTC
I don't believe this task is still assigned to Valentin Rusu. Please feel to revert if you disagree.
Comment 27 Guo Yunhe 2020-09-20 07:48:58 UTC
Really want this feature!

Nowadays, all Electron applications depends on org.freedesktop.secrets and I have to install GNOME Keyrings to make it work.
Comment 28 Alexander Schlarb 2020-09-20 14:40:20 UTC
@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.
Comment 29 Alexander Schlarb 2020-09-20 15:08:06 UTC
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.
Comment 30 Christoph Feck 2020-10-20 13:14:16 UTC
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.
Comment 31 Méven Car 2020-12-16 15:50:38 UTC
*** Bug 430462 has been marked as a duplicate of this bug. ***
Comment 32 Björn Bidar (Thaodan) 2021-01-13 15:05:33 UTC
(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.
Comment 33 Alexander Schlarb 2021-01-14 08:25:58 UTC
(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)?
Comment 34 Björn Bidar (Thaodan) 2021-01-14 08:34:28 UTC
(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.