Setup org.freedesktop.secrets the easy way with KeepassXC in Github Desktop
You might want to quickly authenticate with your Github Account to avoid having to manually configure GIT.
Although if you're using a lightweight distribution you might discover that you have to manually find a provider for org.freedesktop.secrets.
I encountered this problem and wanted to share my thoughts and general pointers from what I've learned!
Github Desktop can authenticate with Github with just a few clicks if you have a secrets provider for org.freedesktop.secrets.
Here's a few common alternatives which I came across:
-
Alternative 1)
gnome-keyring(backend) +seahorse(gui-client)I would avoid this outside of GNOME DE.. Here's some of my notes:
- It needs to be integrated into
PAM. - From personal experience it can be cumbersome to get it to cooperate with D-Bus and XDG.
- You need to have a background daemon to handle requests:
gnome-keyring-daemon.service. - Make sure to use:
libsecretinstead of the deprecated:libgnome-keyringfor it to work properly. - Restart your session after completing the installation to get the right environment variables.
- It needs to be integrated into
-
Alternative 2)
kwallet(QT)It's updated more frequently than Gnome's alternative and has a user friendly interface. It's a good option to get started quickly.
-
Alternative 3)
vaultwarden/or/bitwarden(backend) +bitw(client)(Note: Official Bitwarden client isn't a libsecret provider yet)
I found this approach to be not desirable for me personally as you'll have to consider:
- Managment of a Bitwarden server (and all that is involved like: handling updates, backups, where it's hosted for uptime and reliability).
- License pricing (depending on which features you'd like to have such as 2FA).
-
Alternative 4)
pass-secrets(CLI)This seems like a good minimalistic approach to just get the job done but the lack of development and small userbase wasn't appealing to me.
-
Alternative 5)
keepassxc(GUI)I personally avoid Password Managers but I changed my mind after discovering just how well this one works and the fact that it can be used as a provider for
org.freedesktop.secrets- Uses socket activation to avoid background services (meaning D-Bus initiates it dynamically).
- The database file is stored as a encrypted file in your filesystem which can be automatically synced with any cloud storage provider (like Nextcloud).
- There is browser integration as well as a mobile app.
- 2FA support.
Alternatively, if the above is a hassle consider using Github Desktop as a GUI to only handle branches and commits since the rest can be done in your terminal:
-
Ensure you're using the right name and email address for GIT.
-
Create a access key (this works even with GitLab).
-
When cloning a repository in Github Desktop, use the
URLoption and when prompted for authentication, provide your account's email and use the access key as password from the previous step!
The general gist is:
-
Ensure that D-Bus is running
If you're using systemd this is already done. Otherwise you might need a lightweight solution like dbus-broker.
-
Install XDG
With Sway, this would be
xdg-desktop-portal+xdg-desktop-portal-wlr+xdg-desktop-portal-gtk -
Make sure
libsecretis installed -
Install KeepassXC
-
Setup D-Bus integration
# Default: $HOME/.local/share/dbus-1/services/org.freedesktop.secrets.service [D-BUS Service] Name=org.freedesktop.secrets Exec=/usr/bin/keepassxc
This path might be different if XDG_DATA_HOME is declared (meaning:
$XDG_DATA_HOME/dbus-1/services/org.freedesktop.secrets.service). Do not touch this variable if you don't need it. Default value is:XDG_DATA_HOME="$HOME/.local/share" -
Enable Secret Service Integration in KeePassXC
Tools -> Settings -> Secret Service Integration -> [X] Enable KeepassXC Freedesktop.org Secret Service Integration -
You're done, there is no need to do anything else!
Here's some issues which I've encountered
Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached
-
Make sure
dbusis running as otherwise there is no middleman which can exchange structured data between peers in your system. I'm usingdbus-broker+dbus-broker-units(which is more perfromant than systemd'sdbus-daemon+dbus-daemon-units).Example for
dbus-broker:$ systemctl status --user dbus-broker.service | grep Active Active: active (running) since Wed 2024-04-17 14:51:04 CEST; 22s ago
Depending on your distrbution and choice of DE/WM, you might also need to create a D-Bus session manually. Arch Linux automatically seeds the required D-Bus session variables for Sway as seen here: /etc/sway/config.d/50-systemd-user.conf and this can be confirmed with:
$ echo $D-Bus_SESSION_BUS_ADDRESS unix:path=/run/user/1000/bus
You can check if D-Bus sees the event with:
$ dbus-monitor --session | grep keepassxc string "org.keepassxc.KeePassXC.MainWindow" string "/usr/bin/keepassxc" string "/usr/bin/keepassxc"
(P.S.
qdbusviewerhas a GUI to make it easier) -
Confirm that
xdg-desktop-portalis actually set up correctly, otherwise your browser have no way of communicating with resources outside of its sandbox.Example for Sway in Arch Linux; make sure these XDG services are running for full XDG functionality:
$ 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
Furthermore, make sure that
XDG_CURRENT_DESKTOPexists as this might be missing if you're not using a login manager (like SDDM):$ export XDG_CURRENT_DESKTOP='sway' $ exec sway
Error: The name org.freedesktop.secrets was not provided by any .service files
D-Bus can't communicate with any org.freedesktop.secrets provider. Make sure one is installed correctly (e.g. providers like gnome-keypass needs PAM integration and gnome-keyring-daemon.service has to be running).
Error: The name is not activatable
If you're using a Window Manager like Sway, you might not need dbus-run-session to start your WM (e.g. in case of Arch Linux) as it conflicts with dbus-update-activation-environment which is executed automatically.
Furthermore, make sure that org.freedesktop.secrets.service file is located in the correct directory (check XDG_DATA_HOME above).
Error: No such interface “org.freedesktop.Secret.Collection” on object at path /org/freedesktop/secrets/collection/login
Depending which method you've choosen, it's likely that you need to reload your session (logout and then login) to get the right environment variables (e.g. gnome-keyring through PAM).
Another possibility is that some parts of your $HOME might be owned by a different user which causes permission issues hence this error.
Alternatively make sure there isn't a popup waiting for your password to unlock the path.
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer: unit failed.
Make sure your D-Bus is running
@GrabbenD Hey, similar set up worked for me for several months, but today I'm suddenly getting
Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached. without me doing any changes I would consider as relevant. Would you be available to help troubleshoot by sharing some thoughts in what direction I should dig? My system is PopOs and it's systemd system so dbus is there. I never touchedxdg-desktop-portal. What can I do to find out why this has stopped working and is giving the timeout? Totally fine if you don't have time for this, but if you could it would be much appreciated.