You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SecretStorage has cleaner dependency, however my first attempt failed because DBUS_SESSION_BUS_ADDRESS was not defined. After my tentatively defining it to match a dbus socket in my Debian desktop, DBUS_SESSION_BUS_ADDRESS=unix:abstract=/var/run/dbus/system_bus_socket (but I omit the guid suffix because I don't know where to find it), it raises another exception:
Traceback (most recent call last):
File "/home/demo/Live-usb-storage/env37/lib/python3.7/site-packages/secretstorage/__init__.py", line 69, in dbus_init
connection = connect_and_authenticate()
File "/home/demo/Live-usb-storage/env37/lib/python3.7/site-packages/jeepney/integrate/blocking.py", line 115, in connect_and_authenticate
sock.connect(bus_addr)
ConnectionRefusedError: [Errno 111] Connection refused
Before I dig deeper, I would appreciate some high level guidance here.
Is SecureStorage the right choice for my background/goal described above? I'm attempting to use SecureStorage as an alternative to my already-successful PyGObject-based experiment, but then I happen to also notice this old issue saying SecureStorage could still depend on PyGObject?
SecretStorage is quite a low-level library. It allows you to communicate with the daemon (e.g. gnome-keyring) which actually stores the passwords for you. It requires D-Bus, and it requires a daemon that implements the Secret Service protocol.
Python-Keyring is a higher level library. It supports multiple backends. For example, it can use SecretStorage on GNOME, KWallet on KDE, native backends on Windows and macOS, and an encrypted file on other systems. If you want your application to support many platforms, I recommend using Python-Keyring.
You can use both SecretStorage and Python-Keyring on headless systems, see this instruction.
libsecret was originally like SecretStorage — a wrapper around the Secret Service protocol. However, if I understand correctly, now it can store passwords itself, without relying on a daemon. Maybe we should add a libsecret backend to python-keyring.
Also, the latest versions of SecretStorage do not use PyGObject. The only dependencies are cryptography and jeepney.
This is a high level question and hope to hear wisdom from Dmitry or community.
Background: My use case is to read/write password on Linux. And I have been able to successfully read/write password, using libsecret, with the help of PyGObject, following this set of examples there. It works but the installation of PyGObject has dependency on graphic library pycairo which I would like to avoid, if at all possible.
SecretStorage has cleaner dependency, however my first attempt failed because DBUS_SESSION_BUS_ADDRESS was not defined. After my tentatively defining it to match a dbus socket in my Debian desktop,
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/var/run/dbus/system_bus_socket
(but I omit the guid suffix because I don't know where to find it), it raises another exception:Before I dig deeper, I would appreciate some high level guidance here.
Is SecureStorage the right choice for my background/goal described above? I'm attempting to use SecureStorage as an alternative to my already-successful PyGObject-based experiment, but then I happen to also notice this old issue saying SecureStorage could still depend on PyGObject?
In general, what is the recommended approach with minimal dependency, for a Python script running on Linux to read/write password (stored in/via libsecret?)? In a conversation here, @mitya57 hinted another Keyring project could be an alternative "If you need some simple API to store passwords in a command-line application, I think you should use something like python-keyring instead", but that keyring project seems actually uses SecureStorage as (one of) its own dependency.
In other words, what solution would give a reasonably-well password encryption on Linux, and with minimal dependency?
The text was updated successfully, but these errors were encountered: