It still requires gnome-keyring even on KDE

[blaatunga]

As it seems, the keytar module 4.0.2 claims to depend only on libsecret for Linux, however on Kubuntu 17.04 it still needs the gnome-keyring in order to work properly.

[promeneur]

same problem

opensuse leap 42.2
libsecret-1-0

skype for linux 5.5 or skype for linux preview 8.5 use keytar and claim using libsecret but

• installing skype installs gnome keyring
• use gnome keyring

[wellington1993]

Hi,

I have the same @promeneur skype problem.

[tzarebczan]

We are seeing the same on KDE systems in our LBRY app which uses keytar - please see lbryio/lbry-desktop#386

Any updates on this?

[mclang]

If I understand right, this affects also using Mailspring under KDE Plasma:

• Mailspring Issue 77
• Mailspring Issue 681

Is there any progress on this issue?

[shiftkey]

No real progress on this issue - the use of libsecret is supposed to mean keytar can interoperate with other providers, but even KWallet doesn't support it (see this discussion for more details).

[shiftkey]

libsecret is a library for storing and retrieving passwords and other secrets. It communicates with the "Secret Service" using D-Bus. gnome-keyring and ksecretservice are both implementations of a Secret Service.

• [Source]

libsecret needs an implementation to be available on the user's machine to act as the secret service, and I recommend either gnome-keyring or ksecretservice be installed, but it looks like neither KWallet or ksecretservice ever completed their support for it.

The original goal with choosing libsecret was to avoid being directly coupled to gnome-keyring, and it's not clear to me a way out of this if there's not a KDE-based alternative available.

[flying-sheep]

ksecretservice is unfinished and KWallet itself is in maintenance mode, so we have a few options:

1. get ksecrets/ksecretservice to a state where KWallet can be replaced (probably hard, but would be the best way)
2. implement a library that wraps libsecret and KWallet for the time being (a stopgap solution, as the secret service standard exposed by libsecret should be the real thing. would be reusable by a lot of software that becomes aware of it and easier than to replace KWallet in KDE)
3. just add support for KWallet in keytar (would probably be easiest, but least reusable, since only JS projects can benefit)

[nglgzz]

@shiftkey wouldn't using keyctl instead of (or as a fallback for) libsecret be a viable solution? It's built in the Linux kernel.

It doesn't offer persistence across reboots, but as a user of apps depending on this package, I prefer my apps to be working out of the box and re-enter passwords after reboots than installing packages I didn't plan to use.

[vladimiry]

By the way, aside from gnome-keyring, keepassxc also implements needed Secret Service interfaces, see details in this FAQ. So keepassxc is an alternative to gnome-keyring.

[shiftkey]

@nglgzz I don't have the time available to write a second backend and support gracefully degrading from one to the other if the first is not available. If someone else wants to take a shot at it, that's great, but I can't promise I'll support it officially because it feels risky.

@vladimiry that's great to hear. I had a look at the changelog for keepassxc and it looks like support was added in 2.5.0 which was published in October 2019. I then checked the packages registry for Ubuntu and found this package which is still based on 2.4.3.

Archlinux seems to have the latest version, and perhaps other distributions do too so that users don't need to build from source themselves, so maybe we can update the README to mention this as being important for Linux usage.

[crabdancing]

KDE support is still pretty badly needed tho. :(

[JohnPinto]

@alxpettit An interesting MR was made to the KWallet repository, just a week ago, aimed at supporting the org.freedesktop.secrets API, but the discussion is still underway.
https://invent.kde.org/frameworks/kwallet/-/merge_requests/11