im trying to switch to plasma however all my apps now need to be relogged in, im wondering if its possible to switch the keyring backend to gnome-libsecret to ensure everything is logged in as it is in gnome
You can just disable kdewallet (for example, but uninstalling it) then make sure that the GNOME secrets service is automatically started on login - for example by setting it up as a systemd user service. Or you can export your secrets from GNOME secrets and import them into kwallet.
If you provide more information on your setup (like, what OS, how did you install Plasma, etc), we might be able to provide more detailed instructions.
I have EndeavourOS with the gnome desktop as it was what I wanted to try 5 months ago however recently I’ve been experiencing crashes on it and I wanted to give plasma a shot and i initially installed plasma by installing the plasma group, however i then uninstalled it and installed plasma-desktop to try and see if that would work and it did not.
I am unable to uninstall kwallet because it is required by kio and plasma-workspace, and i do not know to export gnome secrets and import them to kwallet because there doesn’t seem to be resources online that exports everything, the top search results are this post, a gnome app called secrets, and posts about how to use gnome-keyring and secret-tool.
OK, so I checked a few more things:
The way free desktops (i.e. KDE and other Linux desktops that implement the freedesktop.org standard APIs) offer system-wide password management, is supposed to be through a D-Bus API called org.freedesktop.secrets. This is normally default implemented in most all Linux operating systems by the GNOME keyring service - check that you have it running in your system by running systemctl status --user gnome-keyring-daemon.service from your terminal.
You can view and mange your password stored in the GNOME keyring using and older GNOME application called “Seahorse” (it was at certain GNOME releases labeled as “Passwords and Keys”). It does not let you export your keyring, but it does let you change the password of a keyring, and if you change the password to an empty password, it will store the keyring in plain text in a format that can be read and manipulated. The decrypted format is incompatible with anything else that you might be interested to load it into, but it is possible to convert it to whatever you want using a converter program - though as far as I can tell no one ever wrote a converter for KWallet’s import/export format - though you can find a converter to CSV or Firefox’s password storage (which is completely separate and that’s a whole different can of worms),
The KDE Plasma desktop, unfortunately, does not implement the org.freedeskstop.secrets API. Instead if users its own API under org.kde.kwalletd5 or org.kde.kwalletd6 (the new Plasma 6 desktop has a different API, but it also offers backwards compatible Plasma 5 APIs and - as far as I can tell - a complete org.freedesktop.secrets API, but not under the official D-Bus name, so it doesn’t compete with GNOME’s keyring on the official API name 
).
There are also other Linux password manager applications that offer the FreeDesktop secrets service, such as KeePass and BitWarden, though I haven’t tested either and I’m not sure how they handle GNOME keyring conflicts. There was an effort in KDE to create a new official FreeDesktop secrets service to replace KWallet, but that was abandoned and I’m not sure what the current plans as to official FreeDesktop secrets service support are.
GNOME has a new app called “Secrets” - that as far as I can tell is also meant to replace GNOME keyring, and is based on the KeePass file format - but at this point it doesn’t provide a FreeDesktop secrets service and does not interact with the GNOME keyring. I think it is out of scope from this discussion, but you mentioned it so here it is.
The current situation on the KDE desktop is that some applications use the FreeDesktop secrets service API and work because GNOME keyring works, others - mostly KDE apps - rely on the kwallet API and will work with that, while some others - which is I believe what you were complaining about by saying “all my apps now need to be relogged in” - support all the protocols and detect which desktop environment you are running on and switch their implementation accordingly. I know that Google Chrome does this, and by extension all applications that use the Chrome/Chromium runtime (it is very popular to build application on top of that, for example Slack).
For Chrome/Chrome-like applications, there isn’t much you can do - I’m not 100% sure how they detect the desktop environment, but it is very likely they just look at the DESKTOP_SESSION environment variable - which you don’t want to mess with. Chrome has a command line flag to force it to use a specific API so if that is your only problem, you can maybe change the Chrome launcher to specifically use the --password-store=gnome-libsecret command line option and not worry about it.
The easiest way forward may be to just add back all the passwords that you need into kwallet, and live with the fact that you have two system keyrings that occasionally need to be synchronized manually by updating passwords.
2 Likes
You need to make sure gnome-keyring-daemon starts before kwalletd6, then the former will grab the org.freedesktop.secrets DBus address.
The easiest way to guarantee this is to start gnome-keyring-daemon in PAM, so it starts before any Plasma services. For example, this is /etc/pam.d/sddm:
#%PAM-1.0
auth include system-login
-auth optional pam_gnome_keyring.so
-auth optional pam_kwallet5.so
account include system-login
password include system-login
-password optional pam_gnome_keyring.so use_authtok
session optional pam_keyinit.so force revoke
session include system-login
-session optional pam_gnome_keyring.so auto_start
-session optional pam_kwallet5.so auto_start
So if you are using SDDM as the display manager, Gnome Keyring should be providing the FDO secret service in KDE when it’s installed. If you are using other display managers, add the lines containing pam_gnome_keyring.so in its PAM config file.
2 Likes
That is a very good point! I wasn’t aware of the auto_start feature in PAM.
I can see that EndeavorOS, with both GNOME and Plasma installed has the gdm configurations only auto_start GNOME keyring, while the sddm configurations start first GNOME keyring, then kwallet5 (not not kwallet6 - for which doesn’t exist… I wonder…).
From my testing, installing Endeavor in GNOME mode, then installing plasma-meta will switch your DM to SDDM - not that it matters much for this issue.
So I don’t think that is the issue the OP is having - he likely has the GNOME keyring started. I think the likeliest explanation for this complaint that moving from GNOME to Plasma caused his applications to not remember passwords is that Chrome/ium applications automatically switching from using the FreeDesktop secrets service to using the KWallet API when running under Plasma.
Yeah, as @guss77 said earlier, you should disable it - not uninstall it.
Install kwalletmanager, if you haven’t already. Then go to systemsettings, in there should now be a KDE Wallet entry under Security & Privacy. In there you can either disable the kde wallet subsystem entirely or untick “Use KWallet for the Secret Service interface”. See if that does the trick after a reboot. If it doesn’t, check if gnome-keyring-daemon.socket is enabled (when you don’t want to use gnome-keyring you have to make sure it’s disabled, therefore I assume the inverse is also true)
I did this to get keepassxc as my secrets provider and I think it works. I don’t think I have any application that makes use of it so I’m not sure actually, but keepassxc itself says it’s working
2 Likes
Also, one more thing that I remembered: If the applications in question are flatpak applications, its a good idea to check the desktop portal defaults in the file /usr/share/xdg-desktop-portal/kde-portals.conf
On my system it includes:
[preferred]
#...
org.freedesktop.impl.portal.Secret=kwallet
which would make applications that use the “Secret service desktop portal” use the KWallet system instead of the GNOME keyring.
1 Like
I actually have OP’s experience in reverse: been using KDE, but recently installed GNOME to test some bugs. Then vscode in KDE lost all logins, as the FDO secrets service is automatically taken over by gnome-keyring, even in KDE.
Perhaps it should be done that the first time the user put something into the secret service, the current backend becomes the chosen backend in all DEs for that user. But I guess there aren’t enough users using multiple DEs or switching DEs to worth the effort.
hello, updating on my temporary (and maybe permanent) solution, i went ahead and changed the .desktop of the applications to have the parameter --password-store=“gnome-libsecret”. this is probably not a good solution in the long run, but it works and if theres another desktop i want to use it would be a seamless switch (in theory).
1 Like
Thank you all for the ideas, I did the same as @mb1 , and in a way that hopefully will survive upgrading to new versions. I basically create a second desktop file and I edited that one. Now I see the “Signal in KDE app” that should stay the same since it’s my own copy:
Here is what I did. Opened Konsole and typed
cd /usr/share/applications
sudo cp signal-desktop.desktop signal-desktop-kde.desktop
kate signal-desktop-kde.desktop
And for the contents, I made some simple modifications and saved (entering the sudo password when asked).
[Desktop Entry]
Name=Signal in KDE
Exec=/opt/Signal/signal-desktop --password-store=gnome-libsecret %U
(all the rest of the entries stayed the same)
That’s it! More work than it should be, but a workable solution in the end! [1]We really, really, really need to make all this stuff transparent to the end user, and fully interoperable between desktop environments.
Footnotes ↩︎
1 Like
@jinliu the correct way to verify that under KDE your applications use kwallet is to make sure that the /usr/share/xdg-desktop-portal/kde-portals.conf lists org.freedesktop.impl.portal.Secret=kwallet
Unfortunately without that specification, the XDG implementation defaults to gnome-keyring, even if the the kde-portals.conf says default=kde (which is not entirely unjustified - IMO the protocol isn’t defined well enough and there’s no good way to choose between different org.freedesktop.secrets implementations available under /usr/share/xdg-desktop-portal/portals/)
If you want to use gnome-keyring both under KDE and under GNOME, make sure that both /usr/share/xdg-desktop-portal/kde-portals.conf and /usr/share/xdg-desktop-portal/gnome-portals.conf show org.freedesktop.impl.portal.Secret=gnome-keyring;
@Leo_JM - if you are editing .desktop files - don’t do it with sudo under /usr. You should copy the file to your user’s desktop entries folder and edit it there - no sudo permissions needed.
Fortunately, this is exactly what the KDE menu editor application does if you right click on a launcher (for example, from the Kickoff main menu) and choose “Edit Application…”. You can change whatever you need to change there, and when you click “Save” - it will save the results to your user’s desktop entries folder where it will override the original application - only for your current user account - and will survive updates to the application.
If you actually want to have two desktop entries for the same application (one on KDE and one on GNOME, which I find weird and unneeded - see my previous comment on how it should be done), in the menu editor you can - instead of editing the main entry - right click it from the menu items list, select copy, then paste and edit the copy - like you do in the command line, but easier and in the proper way.
1 Like
That’s perfect! Thank you, @guss77 , and sorry for suggesting a bad workaround. I just did this, works like a charm. I just wasn’t aware this was possible (I haven’t used KDE in ages).