org.freedesktop.secrets

README.md

Setup org.freedesktop.secrets the easy way with KeepassXC in Github Desktop

Overview

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!

Secrets Provider?

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: libsecret instead of the deprecated: libgnome-keyring for it to work properly.
  • Restart your session after completing the installation to get the right environment variables.

• 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.

This is a overkill..

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:

1. Setup your SSH keys to commit to Github.

2. Ensure you're using the right name and email address for GIT.

3. (Optionally) Configure gnupg.

4. Create a access key (this works even with GitLab).

5. When cloning a repository in Github Desktop, use the URL option and when prompted for authentication, provide your account's email and use the access key as password from the previous step!

KeepassXC integration

The general gist is:

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

2. Install XDG

   With Sway, this would be xdg-desktop-portal + xdg-desktop-portal-wlr + xdg-desktop-portal-gtk

3. Make sure libsecret is installed

4. Install KeepassXC

5. 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"

6. Enable Secret Service Integration in KeePassXC

   Tools -> Settings -> Secret Service Integration -> [X] Enable KeepassXC Freedesktop.org Secret Service Integration

7. You're done, there is no need to do anything else!

General Troubleshooting

Here's some issues which I've encountered

Bad session

Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached

1. Make sure dbus is running as otherwise there is no middleman which can exchange structured data between peers in your system. I'm using dbus-broker + dbus-broker-units (which is more perfromant than systemd's dbus-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. qdbusviewer has a GUI to make it easier)

2. Confirm that xdg-desktop-portal is 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_DESKTOP exists as this might be missing if you're not using a login manager (like SDDM):

   $ export XDG_CURRENT_DESKTOP='sway'
   $ exec sway

---

Missing service

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

---

Conflicting environment variables

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

---

Access issues

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.

---

Broken D-Bus

GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer: unit failed.

Make sure your D-Bus is running

Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached

@AndrewSav You might find my other post helpful which demonstrates how I troubleshooted and solved this issue in KeePassXC:

keepassxreboot/keepassxc#6274 (comment)

Edit: I've updated this gist with more troubleshooting tips 🙂

@GrabbenD Thank you!