org.freedesktop.secrets

README.md

Github Desktop

Setup org.freedesktop.secrets the easy way with KeepassXC

Overview

You might want to quickly authenticate with your Github Account to avoid having to manually setup GIT.

Although if you're using a lightweight distribution you might discover that you have to manually create a provider for org.freedesktop.secrets.

I encountered this problem and wanted to share my thoughts and general pointers here 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 DBUS and XDG.
  • You need to have a background daemon to handle requests gnome-keyring-daemon.service.
  • Restart your session after completing the installation to get the right environment variables.
  • Make sure to use libsecret instead of the deprecated libgnome-keyring for it to work properly.

• Alternative 2) kwallet

  It's updated more frequently than Gnome's alternative and has a easier UI, it's a good option if you just want to get this to work quickly with a easy user interface.

• Alternative 3) bitw (backend) + Bitwarden (web-client + server)

  I found this approach 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

  • The database file is stored as a encrypted file in your filesystem which can be automatically synced with any cloud storage provider (like Nextcloud).
  • It's not running in the background as DBUS can initiate it dynamically.
  • There is browser integration as well as a mobile app
  • 2FA support

This is a overkill

Alternatively, if the above is a hassle you could just use Github Desktop as a GUI to handle branches and commits:

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 if you'd like to access 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 DBUS 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 and xdg-desktop-portal-wlr

3. Make sure libsecret is installed

4. Install KeepassXC

5. Setup DBUS integration

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

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 of my conclussions to the issues which I've encountered

Bad session

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

First make sure that SystemD's DBUS (or a alternative like dbus-broker) is running as otherwise there is no middleman which can exchange structured data between peers in your system.

Then make sure that xdg-desktop-portal is actually set up correctly, otherwise your browser have no way of communicating with resources outside of its sandbox. For instance, Sway also needs xdg-desktop-portal-wlr for full XDG functionality.

Missing service

Error: The name org.freedesktop.secrets was not provided by any .service files

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

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.

Access issues

Error: No such interface “org.freedesktop.Secret.Collection” on object at path /org/freedesktop/secrets/collection/login

Depending on which method you've choosen (gnome-keyring), it's likely that you need to reload your session (logout and back in) 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 to generate this error.

Alternatively make sure there isn't a popup waiting for your password to unlock the path.

Broken DBUS

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

Make sure your DBUS is running