Using Keepassxc as gnome-keyring replacement and redirect unlock requests to keepassxc

[8FordPrefect8]

I am trying to use keepassxc as replacement for gnome-keyring. I managed to set it up that way and make it work with eg. evolution.
However if keepassxc is not running already and I start evolution, evolution will start gnome-keyring and prompt me to unlock it. I would rather have it starting keepassxc obviously. I wonder if that is possible anyway. But I guess it could most likely be a problem of evolution having that hardcoded.
What I test and what works is that if keepassxc is running, but still unlocked, I will be prompted to unlock keepassxc and gnome-keyring is not started. So maybe a anyway desirable workaround may be to make keepassxc autostart.

[michaelk83]

You need to create a DBus auto-start file for KeePassXC. See #6274 (comment) . Also, make sure that gnome keyring doesn't auto-start by some other means such as during user login.

[8FordPrefect8]

To be more specific I can find the following line if grepping for secret and keepass:

Jan 22 09:14:58 taschenrechner dbus-daemon[689]: [session uid=1000 pid=689] Activating service name='org.freedesktop.secrets' requested by ':1.19' (uid=1000 pid=777 comm="/usr/lib/xdg-desktop-portal")
Jan 22 09:14:58 taschenrechner dbus-daemon[689]: [session uid=1000 pid=689] Successfully activated service 'org.freedesktop.secrets'
Jan 22 09:14:58 taschenrechner keepassxc[847]: QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*)
Jan 22 09:14:58 taschenrechner keepassxc[847]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
Jan 22 09:14:58 taschenrechner keepassxc[847]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
Jan 22 09:14:58 taschenrechner dbus-daemon[689]: [session uid=1000 pid=689] Successfully activated service 'org.freedesktop.portal.Desktop'

I am unsure if xdg-desktop-portal is something that I should mess around with.

[michaelk83]

AFAIK, xdg-desktop-portal is used by Flatpak. It's probably being called by something else. The last line, "Successfully activated service 'org.freedesktop.portal.Desktop'" indicates it was being auto-started as well, so try looking higher for an "Activating service name='org.freedesktop.portal.Desktop'" to see what's asking for it.

Btw, gnome-keyring does some non-standard stuff during login. If that happened to work around this particular issue, it's not something you can expect from KeePassXC.

[8FordPrefect8]

I have only one flatpak package installed which is gradience. I guess gradience is not needed during runtime and I cant find it via pgrep.
If I look whats starting Desktop it's a bit surprising:

Jan 22 09:48:16 taschenrechner dbus-daemon[659]: [session uid=1000 pid=659] Activating via systemd: service name='org.freedesktop.portal.Desktop' unit='xdg-desktop-portal.service' requested by ':1.11' (uid=1000 pid=680 comm="waybar")

So waybar has a unit, but I disabled it, since it fails anyway (guess because sway is not run via systemd). Status gives:

systemctl status --user waybar.service                                      ~
○ waybar.service - Highly customizable Wayland bar for Sway and Wlroots based compositors.
     Loaded: loaded (/usr/lib/systemd/user/waybar.service; disabled; preset: enabled)
     Active: inactive (dead)
       Docs: https://github.com/Alexays/Waybar/wiki/

Messing around with services has strange effects. Eg. If I disable Networkmanager the keepassxc that is started automatically is covering waybar being somewhat in full window mode. That's a bit over my head stuff^^.

[8FordPrefect8]

Oh gosh, you were absolutely right with flatpak. I couldn't install it directly though since it depends on malcontent. I decided to uninstall malcontent and the not further needed dependencies and flatpak was removed with it and xdg-desktop-portal too:
The autostart of keepassxc is gone. I can now even put keepassxc in autostart of sway config and it works like I expected it.

Don't know if there are upcoming side effects from deinstallation of all those services but at least this annoyance is gone. Thanks for your support.

[Mannshoch]

Could someone please creat a Script that auto replace Gnome Keyring with Keepassxc and backwards.
I run Keepassxc as a Snap.

• I propose a button in Keepassxc that open a popup with some additional hints and a save dialog.
• After save we user have to run the script.
• This script request for root password

I'm a bit more carfull on such security related things and avoid as much as possible to modify things manually.

I would really appreciate if there is an automatism for that.

[morgansimonsen]

Hi. I have been looking into using KeePassXC as the secret service provider, with some success. I have been facing the same disable gnome-keyring issues at everyone else etc. But I don't really understand what the motivation for using KeePassXC for this purpose is, nor any other tool that is not GNOME? I really like KeePassXC but injecting it into an OS subsystem like this smells like trouble. Is there something particularly bad about gnome-keyring? Can someone take a few minutes to explain to a noob? :-) Thanks.

[phoerious]

There's nothing inherently wrong with using GNOME as your keyring provider, but KeePassXC is just more portable from one machine to another and when you reinstall your machine. I also find the encryption of the system keyrings (be it GNOME or KDE) a bit messy and intransparent. KDE keyring by default uses very outdated crypto or GnuPG, neither is very compelling.

[Mannshoch]

Also, there is no add-on for using Firefox with Gnome-keyring.
Personally I would like it, if it's possible to use a kdbx as wallet in Keyring. But that's also not possible.

[michaelk83]

Gnome Keyring and KeePassXC implement the same open standard from FreeDesktop.org, called "Secret Service API". Applications talk to this open standard API to store and retrieve their secret data. This has nothing to do with the OS. You can choose which backend you use for this API, depending on your preferences: Gnome Keyring, KeePassXC, or others. It doesn't matter. For example, on KDE you usually wouldn't have Gnome Keyring installed. However, if you do have Gnome Keyring installed, it monopolizes the interface for this API, because it was the first one to implement it, well before there were any others.

The OS only provides a mechanism for the API backend to be automatically started when it is needed. That is as far as the OS involvement goes. And that is also the place where Gnome Keyring doesn't play nice with other providers.

[morgansimonsen]

Thank you, that was all helpful. The portability when reinstalling or between machines is an advantage. But in my tests it seems that KeePassXC is not able to fully replace gnome-keyring. There is the automatic unlock on login issue, having to unlock when the timeout expires. It also breaks the "online accounts" that use OAuth flows to log in, at least on the machines I have tested. Since the only way I was able to stop gnome-keyring from starting upon login was to remove it, it also broke Evolution, because evolution-data-server depends on gnome-keyring. But maybe all of that can be fixed?

[michaelk83]

There may be some trick to stop Gnome keyring from auto-starting on login without uninstalling it. IIRC, it does some non-standard stuff via PAM. As a first step, check if it has any settings for it, or if there are any autostart files for it. Any settings that mention "login" or the "login" group or anything of the sort.

I suspect that the OAuth issues may be just that those apps are looking for particular keys or whatnot that they've previously stored in Gnome keyring, and can't find them in KeePassXC, since they haven't been stored there. Try reruning the login process for one of them from scratch while KeePassXC is providing Secret Service. If I'm right, it will create the necessary data in KeePassXC, and should work after that.

edit: Specifically re Evolution, I think some people did manage to get it to work with KeePassXC, and possibly without Gnome keyring. Try searching the closed issues.