Freedesktop Secrets API provider (libsecret dbus provider)

[colemickens]

I think it would be nice to be able to run passrs libsecret in a systemd user unit and have it provide the Freedesktop Secrets API for various applications to use for secret storage/retrieval.

This would give me a nice way of using Fractal, for example, which only uses libsecret to store credentials, without needing to use Gnome-keyring.

The only thing in this area I've found is a python bridge, but that's a bit of a non-starter for me for multiple reasons: https://github.com/mdellweg/pass_secret_service

WIP: I have a branch where I did less than the bare minimum. It autogens some dbus code, but I didn't actually wire anything up: https://github.com/colemickens/passrs/commits/libsecret

Thoughts? It's already implemented as an optional feature (albeit on by default at the moment).

[cole-h]

I hadn't heard of libsecret before -- sounds interesting!

How would this work, though? I'm under the impression that using libsecret means that secrets are stored in DBus and not ~/.password-store (or PASSWORD_STORE_DIR). Does this then become an alternative backend to a PGP-encrypted store? Or is this an alternate way of interacting with the credentials stored in PASSWORD_STORE_DIR? Going off the Python bridge, I'm assuming the latter, but I'd like to 100% certain.

[colemickens]

dbus isn't really a storage mechanism, it's a communication bus.

In this case, various services can startup and register themselves as providing certain dbus interfaces. That way an application, say fractal, can just make a dbus request to the service providing the FreeDesktop Secrets API, and if there's a service registered, it will respond according to the expected dbus protocol (the xml file in my branch).

So, at runtime on a users' desktop, they are likely to be running a libsecret provider. On gnome, it's gnome-keyring. KDE has their own. The python thing is another example. passrs libsecret would be one as well. They all attempt to register as providing this specific secrets api.

So, not too much like what you described. This is just putting another facade on top of the same storage backend, and re-uses the code you have already written for handling fs/encryption/git/gpg stuffs.

If you were to use this, an example usage would look like this:

passrs show riot.im | head -1 | wl-copy
passrs libsecret # blocks

fractal &
# login to fractal (with pass on clipboard)
# on login, fractal will call (via dbus) for a secret provider (if any) to store the "fractal login" secret
# passrs would be listening and would store the secret under `libsecret/<secretname>`

pkill fractal
fractal &
# login to fractal
# on start, fractal calls out for secret providers and asks if any have the "fractal login" secret
# passrs would be listening and would respond with the value under `libsecret/<secretname>`

[cole-h]

Ah, OK. I'm extremely uninformed about how things like DBus work and got confused by the docs showing things that look like paths. When you say "store the secret under libsecret/<secretname>," is this in the password store, or is this in DBus's magical communication representation thing-that-looks-like-a-path-but-isn't?

Either way, this sounds cool; feel free to PR it!

[colemickens]

I'm extremely uninformed about how things like DBus work and got confused by the docs showing things that look like paths.

I would suggest thinkging less filesystem and more java-style namespacing, hence the org/....

When you say "store the secret under libsecret/<secretname>," is this in the password store, or is this in DBus's magical communication representation thing-that-looks-like-a-path-but-isn't?

That's just an example implementation detail. Fractal wants to store secret, passrs volunteers to store it, it needs to pick somewhere to store it. It might be something users will want to configure, having some random top-level libsecret added might not fit with users' existing organization pattern or naming schemes.

I'll keep chipping away at wiring up the generated dbus.