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.
1 Like
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.
1 Like
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
1 Like
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).