Register as the default Secret Service provider (DBus service)

raffaem commented 3 years ago

In Tools->Settings->Secret Service, in the General tab, there should be an option to register KeePassXC as systemd default Secret Service provider.

On Ubuntu 20.10 this can be achieved by opening /usr/share/dbus-1/services/org.freedesktop.secrets.service and changing

Exec=/usr/bin/keepassxc/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

into

Exec=/usr/bin/keepassxc

We can probably have a backup of the file and if the user de-select the option we restore the backup

REASON

When an application ask for the Secret Service API on D-Bus, if there is no provider, systemd will open the defaut provider as specified in that service file. On Ubuntu this will default to gnome-keyring.

Enabling "KeePassXC freedesktop.org Secret Service integration" does not change this behavior. If KeePassXC is not already opened, at a Secret Service request on D-Bus, gnome-keyring, not KeePassXC, will be opened.

For a real use case scenario, see Maestral#352.

TEMPORARY WORKAROUND

Open a terminal and run

sudo sed -i -E 's/Exec=.*/Exec=\/usr\/bin\/keepassxc/g' /usr/share/dbus-1/services/org.freedesktop.secrets.service

droidmonkey commented 3 years ago

You should never change files in /usr/share like that, it will get overwritten on the next update to gnome-keyring. It also requires root permissions, which you should not be giving to KeePassXC. This will not be implemented.

raffaem commented 3 years ago

If we can't change /usr/share files, what is the correct official way to change systemd default Secret Service provider?

WORK AROUNDS

it will get overwritten on the next update to gnome-keyring.

Can we chattr +i the file?

It also requires root permissions, which you should not be giving to KeePassXC. This will not be implemented.

We an make a separate bash script with only that line, so the user can check before running

droidmonkey commented 3 years ago

You'll have to ask the Ubuntu team on this one.

ntninja commented 3 years ago

@raffaem: The right place to put system customization is (almost) always /etc. In this case however there seems to be no /etc directory for this, so the next best place would be /usr/local/share, where you can override the service activation file by placing a file with the same name in /usr/local/share/dbus-1/services.

Therefore:

sudo mkdir -p /usr/local/share/dbus-1/services
sudo tee /usr/local/share/dbus-1/services/org.freedesktop.secrets.service <<EOF
[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/keepassxc
EOF

However dbus-daemon also supports per-user customization for session service activation and this is something that KeePassXC could reasonably use:

mkdir -p "${XDG_DATA_HOME:-${HOME}/.local/share}/dbus-1/services"
cat > "${XDG_DATA_HOME:-${HOME}/.local/share}/dbus-1/services/org.freedesktop.secrets.service" <<EOF
[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/keepassxc
EOF

See https://dbus.freedesktop.org/doc/dbus-daemon.1.html for all the details of dbus configuration (in particular the ).

droidmonkey commented 3 years ago

@Aetf can we add the above to secret service settings so you can easily change the default provider to keepassxc?

ntninja commented 3 years ago

I just wasted a bunch of time trying to figure out why the KeePassXC “returned empty results on searches” before realizing that somehow gnome-keyring-daemon got hold of the DBus name instead. So having this would likely have avoided this whole thing in the first place.

(Also update the title. This has nothing to do with systemd and is now actually about the “default user password / Secret Service provider”, not system-wide.)

Some caveats about placing the config file in ${XDG_DATA_HOME:-${HOME}/.local/share}/dbus-1/services/org.freedesktop.secrets.service:

To the best of my knowledge it will remain in effect even if KeePassXC is uninstalled, thereby actively breaking dbus activation of gnome-keyring-daemon unless manually removed or disabled before uninstall
In at least GNOME, Mate and Unity desktop environments gnome-keyring-daemon is also started using the auto-start configuration in /etc/xdg/autostart/gnome-keyring-daemon-secrets.desktop – this would have to be either overshadowed in ${XDG_CONFIG_HOME:-${HOME}/.config}/autostart/gnome-keyring-daemon-secrets.desktop or the current name owner of the org.freedesktop.secrets D-Bus name should be killed on KeePassXC startup
- Ideally this could use the D-Bus service hand-over mechanism, but gnome-keyring-daemon doesn't appear to support it

Aetf commented 3 years ago

I've been consider this for a while.

Once we provide a dbus service file in package, I'm not sure how dbus handles a service with multiple providers exactly. I remember reading somewhere that in this case dbus will choose an arbitrary one. So the package manager needs to mark keepassxc and gnome keyring as conflict to each other. I maybe very wrong on this, though.

Gnome keyring may be started by multiple means:

via dbus service activation (configured by the dbus service file)
via xdg auto start
via pam_gnome_keyring.so during user logging in (PAM authentication) This is very early and even before proper environment variables are set for X or wayland.

So properly disable gnome keyring needs more than just provide the dbus service file. Ideally we'd like to also start keepassxc early in PAM, similar to pam_gnome_keyring.so or pam_kwalletd.so. So we will be sure we are the owner of the service name. And has the additional benefit that to optional unlock database using user login password.

But this is difficult because environment variables issue I mentioned above. KDE has a similar issue in kwalletd, which is also a graphic program. They make it possible by using a hack to let the program block until env vars are setup. I don't quite want to implement this, and I'm thinking if there's a better way to do this.

Aetf commented 3 years ago

Haven't heard of D-Bus service hand-over mechanism. Let me do some searching on this. If it's good, we can open a feature request to gnome keyring to implement it.

Aetf commented 3 years ago

There may be security related risks if gnome keyring allow hand over, i.e. DBUS_NAME_FLAG_ALLOW_REPLACEMENT. So it may not be easy to persuade them implementing this.

ntninja commented 3 years ago

I'm not sure how dbus handles a service with multiple providers exactly. I remember reading somewhere that in this case dbus will choose an arbitrary one. So the package manager needs to mark keepassxc and gnome keyring as conflict to each other. I maybe very wrong on this, though.

The arbitrary thing is indeed what'll happen if the service files are placed in the same directory. It cannot happen however, if adhering to the (strong, but mostly unenforced) convention of naming the .service file after the service name it describes, since that would result in a file conflict. It would be possible to install the service file into a higher priority directory instead, but I strongly advise against this since it will force the system-wide default to change for all users. In Debian at least the alternatives system may be used in these cases, but it'll require an update to the gnome-keyring package so this will only affect new releases of Debian and its derivatives. (If you need a workaround for installing upstream packages on existing Debian, that can be hacked in using dpkg-divert.)

I'll submit a request to the Debian maintainer for gnome-keyring about this and it should trickle down eventually. Note that I'll advise to give keepassxc a lower priority than gnome-keyring, so that installing keepassxc (non-default package) will not result in sudden “loss” of all keyring data of a user.

This is all distributer-level stuff through. I'd advise to only care about per-user configuration here, since its much simpler and doesn't carry the risk of inadvertently changing some other users keyring without them noticing.

Gnome keyring may be started by multiple means

That looks correct, I hadn't considered the PAM thing yet. So unless gnome-keyring-daemon registers its name with DBUS_NAME_FLAG_ALLOW_REPLACEMENT, killing it to taking over the bus name will be the only option, since…

Ideally we'd like to also start keepassxc early in PAM, similar to pam_gnome_keyring.so or pam_kwalletd.so. So we will be sure we are the owner of the service name.

…starting during PAM is not a solution, since your PAM module may be invoked before the other PAM module, but the spawned KeepassXC subprocess may still end up connecting to the bus and claiming the service name after the subprocess spawned by pam_gnome_keyring.so already did.

And has the additional benefit that to optional unlock database using user login password.

Please treat this whole PAM ordeal as a separate feature, even if I'm sure many would like to see this. There are literally hundreds of ways it can go wrong and as I mentioned above, it isn't actually part of the solution either way.

But this is difficult because environment variables issue I mentioned above. KDE has a similar issue in kwalletd, which is also a graphic program. They make it possible by using a hack to let the program block until env vars are setup. I don't quite want to implement this, and I'm thinking if there's a better way to do this.

There is unfortunately no better way. PAM modules are way too early for spawning regular user-session programs, but they are the only place where one can sniff the entered user password so one has to do so anyways.

The whole hack can be simplified if your willing to require systemd & pam_systemd.so:

If XDG_RUNTIME_DIR env isn't set, exit – pam_systemd.so should have set that up
Wait until ${XDG_RUNTIME_DIR}/bus appears (the session bus), then connect to it
Connect to the org.freedesktop.systemd1 service over the bus, if this fails exit (as I understand it the name should always be in acquired state, if the user-session was started with a systemd user manager around and pam_systemd.so should ensure that the user manager is started)
Wait for the /org/freedesktop/systemd1/org.freedesktop.system1.Manager.StartupFinished signal to be fired
Read /org/freedesktop/systemd1/org.freedesktop.system1.Manager.Environment and use it as the process environment for starting keepassxc --pw-stdin --minimized
Pass the password over the stdin pipe to KeepassXC
Exit

Of course, as I said, none of this as anything to do with the problem at hand. Let's move this to another issue.

There may be security related risks if gnome keyring allow hand over, i.e. DBUS_NAME_FLAG_ALLOW_REPLACEMENT. So it may not be easy to persuade them implementing this.

I'll submit a patch for this to https://gitlab.gnome.org/GNOME/gnome-keyring/ once I get my account re-enabled there. We'll see what they say.

Aetf commented 3 years ago

Yeah. PAM is a completely separate beast. I mentioned it just because I personally wanted this kind of setup, and have done quite a bit of research on the topic, and it's somewhat relevant to the situation.

I agree with @ntninja that the easiest route going forward is just to ship the dbus service in the user configuration. And probably warn more obviously (keepassxc already warns the user if it detects another service implementation is running. But probably that's not too discoverable) and/or kill gnome-keyring if the user requested.

This is not the optimal integration experience with DEs. But it's a step forward anyway.

michaelk83 commented 3 years ago

The correct way to implement this with SystemD is similar to how diplay-manager.service is handled. Each provider should install a provider-specific service file ~~into /usr/share/dbus-1/services/ (or whichever the correct /usr/share/dbus-1/ subfolder is for available rather than enabled services),~~ with Alias=org.freedesktop.secrets.service in their [Install] section. So you may have org.freedesktop.secrets.gnome-keyring.service, org.freedesktop.secrets.keepassxc.service, and so on. Then when one of these is enabled, SystemD would set a symlink from org.freedesktop.secrets.service to the correct provider file, which automatically disables the other providers' services.

This should probably be added to the Secret Service spec under a "Configuration/SystemD" section (for now, just post to https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues ; I might do that later).

There should probably be some way to control this via Debian's alternatives system as well, but I'm less familiar with the details. Maybe something like register the provider-specific .service file as an available alternative. But that should probably be in a separate issue. This one is about SystemD. In any case, there should always be only one provider running, and its identity should be configured by the system. This is a run-time configuration conflict, not a package-level conflict.

@ntninja , did you end up submitting any tickets re this to gnome-keyring in the end? If so, please post the links here in a comment. Thanks.

michaelk83 commented 3 years ago

It appears there was some confusion: the .service files under /usr/share/dbus-1/services/ are NOT SystemD service files. Those are DBus activation files. They have the same extension, but it's a different and separate service activation mechanism. SystemD is yet another option, that adds to the list posted by @Aetf.

I've re-read the thread with this in mind, and some of the previous comments make more sense now.

I would advise against placing config in /usr/local/share/ or ${XDG_DATA_HOME:-${HOME}/.local/share} by default, as this would still be "selfish" behavior that would conflict with other Secret Service providers. If implemented, this should be an optional configuration. For example, installed when "Enable Secret Service integration" is checked, or even as a separate step:

Check "Enable Secret Service integration".
KPXC detects that another Secret Service provider is configured, displays a warning and "Override" button.
Override button installs the user-specific configuration.
Uninstall cleans it up (and maybe also when "Enable" checkbox is cleared).

Unfortunately, DBus activation files don't have the same Alias mechanism as SystemD. And there are still the other auto-start mechanisms.

michaelk83 commented 3 years ago

I've posted xdg-specs:75 as a proposal how these config should be set, based on what was discussed here; and gnome-keyring:86 asking gnome-keyring to fix on their end (pointing them at xdg-specs:75). Of course, any comments are welcome from both sides.

@Aetf , I've also posted xdg-specs:73 re the prompt complete signal. I'm leaving the InteractiveAuthorizationRequired issue to your discretion, as you may want to handle that differently. But I've found org.freedesktop.Secret.Error.IsLocked as an alternative to InteractiveAuthorizationRequired (maybe they can even be returned together).

saddy001 commented 2 years ago

After issuing all methods for disabling the gnome-keyring

The gnome-keyring-agent was still running at boot on Xubuntu 20.04. As a last resort I removed the executable bit to the binary.

Aetf commented 2 years ago

@saddy001 gnome-keyring-agent is gnome keyring's ssh agent, and it is different from gnome-keyring-daemon which actually provides the org.freedesktop.secrets DBus service.

Discussed in this issue and in the links you mentioned is about gnome-keyring-daemon and not gnome-keyring-agent

saddy001 commented 2 years ago

@saddy001 gnome-keyring-agent is gnome keyring's ssh agent

Sorry I typed this from my head. I mean gnome-keyring-daemon.

SquigglyDog commented 2 years ago

Sorry I really don't understand the purpose of Secret Service Aggent and I am gettingg more confused. I have the message Warning: Another secret service is running (PID: 1343, Executable: /usr/bin/gnome-keyring-daemon). Please stop/remove it before re-enabling the Secret Service Integration."

Is this a security risk. I am not clear on whether this indicates KeepassXC has been hacked

droidmonkey commented 2 years ago

If you don't know what it is, keep it off. Read up on the capability though: https://rtfm.co.ua/en/what-is-linux-keyring-gnome-keyring-secret-service-and-d-bus/

SquigglyDog commented 2 years ago

It is off and to my knowledgge has never been on. The article may be of help but having started to read it I doubt I will understand why there is a warning in Keepassxc about this service I don't use Sorry this is beyond my understanding. I was looking for a password manger and now I face the prospect of trying another manager that is not so difficult to comprehend. It is hard to find managers that do not store encrypted data online

droidmonkey commented 2 years ago

Just ignore it. We are just telling you that you already have a secret service provider running and you'll have to disable that one to use the one built into keepassxc. It is off by default.

invidian commented 2 years ago

In my case, gnome-keyring-daemon has been socket-activated by systemd. Workaround: systemctl --user mask --now gnome-keyring-daemon.socket.

t-chab commented 2 years ago

@saddy001 : same issue here on Ubuntu 22.04.

Did you find a cleaner workaround ? I am not the only user on the computer, but I'm the only keepassxc user, and I don't want to disable gnome-keyring-daemon for the others.

saddy001 commented 2 years ago

No, still using this workaround.

boogiewoogit commented 11 months ago

@raffaem: The right place to put system customization is (almost) always /etc. In this case however there seems to be no /etc directory for this, so the next best place would be /usr/local/share, where you can override the service activation file by placing a file with the same name in /usr/local/share/dbus-1/services.

Therefore:
sudo mkdir -p /usr/local/share/dbus-1/services
sudo tee /usr/local/share/dbus-1/services/org.freedesktop.secrets.service <<EOF
[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/keepassxc
EOF
However dbus-daemon also supports per-user customization for session service activation and this is something that KeePassXC could reasonably use:
mkdir -p "${XDG_DATA_HOME:-${HOME}/.local/share}/dbus-1/services"
cat > "${XDG_DATA_HOME:-${HOME}/.local/share}/dbus-1/services/org.freedesktop.secrets.service" <<EOF
[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/keepassxc
EOF
See https://dbus.freedesktop.org/doc/dbus-daemon.1.html for all the details of dbus configuration (in particular the ).

Would it be possible to add this file as share/dbus-1/services/org.freedesktop.secrets.service under the build output? That'd be a nice little first step, without any assumptions, that already smoothes the process of providing keepassxc as the default for (at least some, I reckon most) distro packagers by a noticeable margin.

genevieve-me commented 9 months ago

Would it be possible to add this file as share/dbus-1/services/org.freedesktop.secrets.service under the build output?

I would also love to see this. I tried writing up the following simple patch to do so:

share/CMakeLists.txt --- CMake
59 59     endif(KEEPASSXC_DIST_FLATPAK)
60 60     configure_file(linux/${APP_ID}.desktop.in ${CMAKE_CURRENT_BINARY_DIR}/linux/${APP_ID}.desktop @ONLY)
61 61     install(FILES ${CMAKE_CURRENT_BINARY_DIR}/linux/${APP_ID}.desktop DESTINATION ${CMAKE_INSTALL_DATADIR}/applications)
.. 62     configure_file(linux/org.freedesktop.secrets.service.in ${CMAKE_CURRENT_BINARY_DIR}/linux/org.freedesktop.secrets.service @ONLY)
.. 63     install(FILES ${CMAKE_CURRENT_BINARY_DIR}/linux/org.freedesktop.secrets.service DESTINATION ${CMAKE_INSTALL_DATADIR}/dbus-1/services)
62 64     install(FILES linux/${APP_ID}.appdata.xml DESTINATION ${CMAKE_INSTALL_DATADIR}/metainfo)
63 65 endif(UNIX AND NOT APPLE AND NOT HAIKU)
64 66 

share/linux/org.freedesktop.secrets.service.in --- Text
1 [D-BUS Service]
2 Name=org.freedesktop.secrets
3 Exec=@CMAKE_INSTALL_PREFIX@/bin/keepassxc

Unfortunately the file doesn't seem to be created, but this probably comes down to my lack of cmake knowledge. For reference: the KDE docs on dbus activation which use cmake.

GrabbenD commented 3 months ago

The solution from above stopped working for me. Coincidentally I think it broke after upgrading from dbus-daemon-units to the new default: dbus-broker-units for dbus-broker?

I'm currently seeing Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached when authenticating from Github Desktop.

Troubleshooting

Unlike other distributions, Arch Linux automatically registers a DBUS session for Sway through /etc/sway/config.d/50-systemd-user.conf as seen here:

$ exec sway
$ echo $DBUS_SESSION_BUS_ADDRESS 
unix:path=/run/user/1000/bus

Declaring XDG_DATA_HOME before launching Sway didn't help

$ export XDG_DATA_HOME="$HOME/.local/share"
$ exec sway
$ echo $XDG_DATA_HOME
/home/user/game/.local/share

Here's my org.freedesktop.secrets.service

$ less ~/.local/share/dbus-1/services/org.freedesktop.secrets.service
[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/keepassxc

XDG is running fine:

$ echo $XDG_CURRENT_DESKTOP
sway

$ systemctl status --user xdg-desktop-portal{,-wlr,-gtk} | grep Active
     Active: active (running) since Wed 2024-04-17 14:51:06 CEST; 18s ago
     Active: active (running) since Wed 2024-04-17 14:51:06 CEST; 18s ago
     Active: active (running) since Wed 2024-04-17 14:51:06 CEST; 18s ago

$ systemctl status --user dbus-broker.service | grep Active
     Active: active (running) since Wed 2024-04-17 14:51:04 CEST; 22s ago

Furthermore, monitoring DBUS shows that KeePassXC gets invoked:

$ dbus-monitor --session | grep keepassxc
      string "org.keepassxc.KeePassXC.MainWindow"
                  string "/usr/bin/keepassxc"
                     string "/usr/bin/keepassxc"

I've confirmed that DBUS uses ~/.local/share/dbus-1/services/org.freedesktop.secrets.service since it breaks with a different error if the service file is deleted:

Error: The name is not activatable

Github Destop authentication successfully opens my browser but after authorizing access, I don't see a entry for org.freedesktop.secrets in qdbusviewer

SOLUTON

Tools > Settings > Secret Service Integration > [X] Enable keepassxc

(FIY: I had to login twice. The first attempt created a KeePassXC database and the second seeded it).

michaelk83 commented 3 months ago

@GrabbenD Those steps are complementary:

Using the DBus service file tells DBus to launch KeePassXC when the Secret Service is requested by a client. It does not tell KeePassXC to activate the service.
Enabling that setting in KeePassXC tells KeePassXC to activate the service when it is launched. But it does not automatically launch KeePassXC at any point. (You'd need to launch it by other means.)

If you want KeePassXC to act as your default provider, then you need to do both steps.

In addition, you need to make sure that Gnome Keyring nor any other Secret Service provider don't run before KeePassXC (such as from a start-on-login configuration). If they do, they will grab the service, and KeePassXC will refuse to take over.

"The name is not activatable" error means that DBus doesn't know which app to launch when the service is requested by a client. That's because it can't find any service file for that service.

agowa commented 3 weeks ago

Just for reference, this is what the archlinux wiki contains: https://wiki.archlinux.org/title/KeePass#Autostart

Creating the file ${XDG_DATA_HOME:-$HOME/.local/share}/dbus-1/services/org.freedesktop.secrets.service with:

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

However when I tried to set this up I ran into issues with having to have gnome-keyring installed simultaneously. I couldn't see such issues with having kwallet installed (but disabled in the settings). gnome-keyring have didn't offer a way to be disabled without being uninstalled. Therefore I needed an additional configuration change to the package manager of my ArchLinux to no longer extract the dbus unit of gnome-keyring by going into /etc/pacman.conf and adding:

NoExtract   = usr/share/dbus-1/services/org.gnome.keyring.service usr/share/dbus-1/services/org.gnome.keyring.PrivatePrompter.service usr/share/dbus-1/services/org.gnome.keyring.SystemPrompter.service usr/share/dbus-1/services/org.freedesktop.secrets.service usr/share/dbus-1/services/org.freedesktop.impl.portal.Secret.service

And what I also noticed is that sometimes KeePassXC will just itself automatically disable that service and I'll have to manually go into the settings and enable it again. Sadly almost always this causes Electron apps to hick up and needing to be re-initialized (esp. the Element client will just refuse to reuse it's settings after it failed to access the secret backend even once...)

And another issue I noticed (that KeePassXC probably should work around even though it isn't at fault here) is Electron apps using the default chrome names e.g. "Chrome Safe Storage" and "Chrome Safe Store Control" (same probably also for "Chromium" instead of "Chrome") and thereby conflicting with each other...

tsilvs commented 3 weeks ago

I'm on Fedora Silverblue 40 & I tried to write a workaround script for this issue:

All of these were collected from several random sources online.

cp /etc/xdg/autostart/gnome-keyring-secrets.desktop /etc/xdg/autostart/gnome-keyring-secrets.desktop.bak
cp /etc/xdg/autostart/gnome-keyring-pkcs11.desktop /etc/xdg/autostart/gnome-keyring-pkcs11.desktop.bak
cp /etc/xdg/autostart/gnome-keyring-ssh.desktop /etc/xdg/autostart/gnome-keyring-ssh.desktop.bak
echo "X-GNOME-Autostart-enabled=false" >> /etc/xdg/autostart/gnome-keyring-secrets.desktop
echo "X-GNOME-Autostart-enabled=false" >> /etc/xdg/autostart/gnome-keyring-pkcs11.desktop
echo "X-GNOME-Autostart-enabled=false" >> /etc/xdg/autostart/gnome-keyring-ssh.desktop
sed -i -r -e 's/^(X-GNOME-Autostart-Phase=PreDisplayServer)/#\1/' /etc/xdg/autostart/gnome-keyring-{secrets,pkcs11,ssh}.desktop
sudo systemctl --system mask gnome-keyring-daemon.service
sudo systemctl --system mask gnome-keyring-daemon.socket
cp /etc/pam.d/gdm-autologin /etc/pam.d/gdm-autologin.bak
cp /etc/pam.d/gdm-password /etc/pam.d/gdm-password.bak
cp /etc/pam.d/passwd /etc/pam.d/passwd.bak
sed -i -r -e 's/^(-?)(auth|session|password)([ ]+|[\t]+)(optional)([ ]+|[\t]+)(pam_gnome_keyring)/\#\1\2\t\4\t\6/' /etc/pam.d/{gdm-autologin,gdm-password,passwd}

I also tried this:

mv /etc/xdg/autostart/gnome-keyring-secrets.desktop /etc/xdg/autostart/gnome-keyring-secrets.desktop.bak
mv /etc/xdg/autostart/gnome-keyring-pkcs11.desktop /etc/xdg/autostart/gnome-keyring-pkcs11.desktop.bak
mv /etc/xdg/autostart/gnome-keyring-ssh.desktop /etc/xdg/autostart/gnome-keyring-ssh.desktop.bak

But it doesn't really work. I still get the gnome-keyring-daemon to launch automatically.

These will not work on any ostree managed atomic systems for obvious reasons (/usr being read-only):

sudo chmod -x /usr/bin/gnome-keyring-daemon
sudo sed -i -E 's/Exec=.*/Exec=\/usr\/bin\/keepassxc/g' /usr/share/dbus-1/services/org.freedesktop.secrets.service

zroug commented 2 weeks ago

I found a working workaround for Silverblue. I just created a dummy RPM package that simulates providing gnome-keyring-daemon. This package uses the following spec file but is otherwise empty:

Summary: Summary here
Name: gnome-keyring-dummy
Version: 0
Release: 0
License: Public
Provides: gnome-keyring, gnome-keyring-pam
%description
Package description here
%files

After creating the package, you can install it with rpm-ostree install /path/to/package.rpm. Then, uninstall the actual gnome-keyring package using rpm-ostree uninstall gnome-keyring. This approach successfully silences the annoying gnome-keyring, and isn't too hacky in terms of modifying read-only locations.

GitHub won't let me upload the rpm file, but it's easy to build with rpmbuild --target=noarch -bb gnome-keyring-dummy.spec.

keepassxreboot / keepassxc