veilid/scripts/earthly/secretsd
2023-08-21 20:12:20 -05:00
..
dbus
secretsd add eartly build 2022-01-09 15:17:36 -05:00
systemd
LICENSE
README.md
requirements.txt
secretsd.py add eartly build 2022-01-09 15:17:36 -05:00

secretsd

This is a generic backend for the libsecret API, used by various programs to store passwords and similar secrets. It mostly implements the Secret Service API specification, to act as an alternative to gnome-keyring-daemon and kwalletd.

badge: "works on my machine"

Dependencies

  • python-cryptography
  • python-dbus
  • python-gobject (3.x)
  • python-xdg

Installation

secretsd is a user-level daemon which uses your D-Bus "session bus". It could be manually started through systemd --user:

cp systemd/secretsd.service ~/.config/systemd/user/
systemctl --user start secretsd

or automatically started on demand through D-Bus activation:

cp systemd/secretsd.service ~/.config/systemd/user/
cp dbus/org.freedesktop.secrets.service ~/.local/share/dbus-1/services/

Security

Secretsd does not aim to provide complete security like a modern password manager would; it only aims to allow using the libsecret API instead of ad-hoc loading of plaintext passwords from ~/.netrc or similar files, but still relies on external protection for those files. In particular, item titles and attributes are not encrypted.

For now, all secrets are encrypted using a single "database key", which is stored in a regular file by default but can be provided through an environment variable, KWallet, or read from an external program. To specify the key source:

secretsd -k file:${CREDENTIALS_DIRECTORY}/secrets.key
secretsd -k env:DATABASE_KEY
secretsd -k kwallet:
secretsd -k exec:"pass Apps/secretsd"

(As secretsd is supposed to be a background service, it is strongly advised to not use an external program which would show interactive prompts. And in particular avoid those which use GnuPG pinentry or otherwise make use of libsecret, for hopefully obvious reasons.)

Individually encrypted collections are not yet supported, but planned in the future. (This will most likely be a fully separate layer of encryption, in addition to the database key.)