Replace kwallet with KeePassXC as keyring

[diwou]

I have just switched from Debian to Manjaro. On Debian I was running KDE Plasma (Wayland) together with GDM3. There I had disabled the Gnome keyring and replaced it with KeePassXC. Everything worked fine so far, all apps automatically used KeePassXC instead of kwallet.

Now I wanted to have this under Manjaro as well. And the setup is similar, except that I use SDDM as installed by default. Otherwise also KDE Plasma (Wayland). I figured that since there is no GDM3, there is no Gnome keyring that needs to be disabled.

KeePassXC set up and it works so far. When I save or retrieve passwords with the command line tool secret-tool, this all ends up in KeeyPassXC.

But the many other KDE applications generally refuse to go via libsecret, but persistently want to access kwallet.

With the Brave browser and the Nextcloud client, I was able to work around the problem by setting the following environment variables:

export XDG_CURRENT_DESKTOP=anythingelse
unset KDE_FULL_SESSION

Now I can’t set these variables globally, because some programs don’t work properly with them, or the GUI doesn’t run properly.

The korganizer (via akonadi) completely refuses to use the libsecret under Manjaro, which worked under Debian.

I’ve been looking for a solution for 3 days now, but haven’t really found one. GDM3 comes with the Gnome keyring, which I had deactivated under Debian to make it work (otherwise Debian behaved similarly).

Only with SDDM there is no GNU keyring that could be deactivated. But it still doesn’t work.

Has anyone tried this themselves and got it to work?

[ChrisCanyon]

Maybe this option could help, i did not try it though.

[diwou]

Thanks for the tip.

But I had already switched that off. I also had to disable it under Debian, otherwise you could not activate the keyring in KeePassXC.

However, the Debian version also had the “Enable Secret Service DBus API” switch, which had to be activated. This is completely missing in the Manjaro version.

The strange thing is that it basically works, but some programs do not use it as long as the variables XDG_CURRENT_DESKTOP with KDE and KDE_FULL_SESSION are set to true.

If you change these, then it also works. But then many programs no longer recognize that KDE is running and look strange in the menu structure, icons, etc., so they cannot be used properly in some cases.

However, I was also running KDE Plasma with Wayland under Debian (somewhat older version) and these variables were also set in this way there. As soon as the programs there noticed that KeePassXC was running as a keyring, it was used.

The GNU keyring simply had to be switched off (and prevented from being reactivated), as otherwise KeePassXC would automatically switch off its own keyring. But the GNU keyring is not even installed under the Manjaro KDE version.

[Mirdarthos]

Without reading the original post, my guess is that this is probably related:

https://bbs.archlinux.org/viewtopic.php?id=287302

And/or:

https://fossies.org/linux/keepassxc/utils/keepassxc-kdewallet

[ChrisCanyon]

Everything work fine on my system and i enabled keepassxc as secret service integration from yesterday to play around.
Both variables you are talking about are set to KDE and TRUE, i do not have any issue with that.

@diwou

many programs no longer recognize

Which programs ? What does journalctl say ?

@diwou

look strange in the menu structure,

Screenshot ?

The only difference is i use X11 and not Wayland, i am on testing branch with Plasma 6.

[diwou]

There is no error in the classical sense. The programs just use the kwalettd5 service instead of KeePassXC. This is why there is no error in the log.

For example, korganizer, browsers based on Chrome, Nextcloud Client, VPN tools, and many more. In other words, all programs that store data in the keyring.

The settings from the KDE profile, such as size, fonts, color, etc., are not used. Instead, a default value is used. On HighDPI monitors, for example, a magnifying glass is needed to read the font.

The variable deprives the program of the possibility of knowing which system it should run on, so it cannot read the corresponding settings.

But I think I have slowly solved the problem. Unlike Debian, the KDE password storage system must generally be deactivated in the system settings. This may be because the point with the D-Bus Api is missing in Manjaro.

I have now apparently been able to solve this via the files ~/.config/kwalletrc and /usr/share/dbus-1/services/org.freedesktop.secrets.service. I have activated the D-Bus Api in kwalettrc (I can’t say why this item is missing in the system settings) and I have entered KeePassXC as a keyring in org.freedesktop.secrets.service (Debian still contains the Gnome keyring).

As a precaution, I also prevented kwalletd5 from starting in the file /usr/share/dbus-1/services/org.kde.kwalletd5.service.

However, I cannot yet say why Debian and Manjaro behave so differently here. With Debian, kwalletd5 continued to run without any problems. If the service is running in Manjaro, you cannot activate the integration in KeePassXC.

I’m still looking for what’s different.

[ChrisCanyon]

@diwou

Manjaro, you cannot activate the integration in KeePassXC.

But i could do it…maybe i do not have apps which use it

What is surprising is even if SSI apparently works with keepassxc (i enabled this option within keepassxc and disabled SSI in KDE settings), KWallet still get my wifi password.

I did not completely disabled KWallet in KDE settings, but in this case, what is the purpose of disabling SSI only ?

[diwou]

I have now got everything up and running. I can’t quite explain why there is such a difference here. Maybe the GDM3 comes with some libraries that the SDDM doesn’t have.

To be on the safe side, I installed a new “Manjaro KDE Plasma” instance in a virtual machine and added KeePassXC to it.

And this behaved in exactly the same way as my actual computer.

I got the whole thing up and running as follows:

Deactivate KDE password storage system

The first step is to deactivate the password store in the system settings. To do this, open the System settings tool and select “KDE password storage” in the “Personal information” section on the left-hand side. In the right-hand section, uncheck “Activate KDE password storage system”.

Activate Secret Service API

The next step is to edit the file ~/.config/kwalletrc in the home directory. Various blocks may already be found there. If the [Wallet] block is present, you should check that the Enabled value is set to false.

[Wallet]
...
Enabled=false
...

And if not already present, a further entry must be added at the end or adapted accordingly:

[org.freedesktop.secrets]
apiEnabled=true

Change Secrets Service API for KeePassXC

The file org.freedesktop.secrets.service, if it does not exist, must be created and adapted, and the file modified as follows:

[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/keepassxc

The “Exec” item is particularly important, as another keyring may have been entered that needs to be replaced by KeePassXC.

Restart computer

The computer can now be restarted. You should then check whether the kwalletd5 service is still running, see point 2 above. Otherwise, check the individual configuration points again and adjust or correct them if necessary.

Configure KeePassXC

Now the Secret Service integration in KeePassXC can be activated. To do this, open KeePassXC and go to the settings (either via “Tools” → “Settings” or via the cogwheel in the top bar). Then select “Secret Service Integration” on the left and check the box “Enable KeepassXC Freedesktop.org Secret Service integration”.

Confirm these changes with “OK” and exit the settings (simply press the “Escape” button).

It is best to create a new group for the keyring here. This is not a requirement, but it is better to separate it from the other password settings. To do this, click on “New group” under “Groups”, assign a name and confirm with “OK”.

Then click on “Database” in the menu bar and select “Database settings”. Click on “Secret service integration” on the left-hand side and select “Disclose entries under this group:” on the right-hand side. The previously created group can then be selected and saved with “OK”.

Brave Browser

Now, with the exception of the Brave Browser, everything runs via KeePassXC. In order for the Brave Browser to do the same, I have to explicitly start Brave in Manjaro with the additional switch --password-store=gnome-libsecret. Otherwise it takes a good 30 seconds to start. It then switches to Basic Password Store mode.

This presumably applies to all browsers based on Chrome.