Support for libsecret's dbus API

Quexten · January 16, 2024, 1:13am

I missed checking this thread for a while, but just to clear things up, Goldwarden does not currently implement the libsecret dbus api. But here is the open issue for it: Libsecret Support · Issue #9 · quexten/goldwarden · GitHub

24mu13 · June 23, 2024, 7:42am

It’s the only reason why I cannot move to Bitwarden from KeePassXC: you have several good features, but without libsecret/dbus support no way to use Bitwarden.

I have the feeling quite a lot people experience the same

VeldoraTheDragon · March 18, 2025, 8:11am

I’m already using Bitwarden as my main password-manager and I’m still stuck with Gnome Keyring, which is so annoying imho.

If a libsecret integration for Bitwarden existed, I’d could finally ditch Gnome-Keyring.

SlowNicoFish · March 20, 2025, 2:46pm

Is this comment saying that libsecret is already implemented?

github.com/bitwarden/clients

Automatically unlock vault with native password manager

opened 11:42AM - 17 Jan 19 UTC

closed 01:39AM - 17 Feb 21 UTC

AndreasBackx

On Linux you've got Gnome Keyring and KDE Wallet (if not more), on MacOS you've …got the MacOS Keychain, and on Windows I don't really know. Many of each OS' features plug into these along with Git, GPG, VS Code, etc. to store their credentials. So most of the time when you're logged in, your keyring/keychain is already unlocked because you either unlocked it during login or another application already unlocked it. That's why I think most people are still using a password manager like the one that's built into Google Chrome, or the iOS and MacOS keychain. So I came here to ask whether it's possible to use Google Chrome's (and perhaps others as well, I haven't looked that much into it) credentials API (which integrates with Gnome keyring, KDE Wallet...) to automatically unlock the vault. I've also wondered whether the desktop app could offer this feature if it does not do so already: replace Gnome Keyring and KDE Wallet on Linux. (I'm unsure whether it's possible on MacOS, but I think it might be possible because it's possible on iOS). Though, a respective issue would have to be made there as well. Then, in the end we'd be able to use Bitwarden from end-to-end.

I’m not having any problem on gnome but in kde, kwallet complains about multiple attempts at access which leads me to believe the implementation is not rock solid.

1ace · March 20, 2025, 4:30pm

No, this is the other way around.

What you linked is about having another password manager manage the bitwarden password.

This request here is about adding support to bitwarden to be the password manager that other apps can use.

nawan · June 4, 2025, 2:09pm

Here is relevant discussion:

1Password used to use the libsecret-dbus API to store Secret Key, but they reverted this change (at least when running in GNOME). This was likely due to design limitations in the libsecret-dbus API that allow unsandboxed, malicious processes to steal secrets from the secret service provider.

Tulkas59 · September 26, 2025, 4:27pm

Hello everyone,

A short message to announce you (and avoid any race condition with someone who would have the same idea in mind :-]) that I am doing my best to develop an async dbus-daemon implementing the Secret Service API with Bitwarden (bw) as the backend storage.

What is done:

all anticipated operations between the daemon and bw, and related abstractions (tested);
org.freedesktop.Secret.Session and all the stuffs related to transfer of secrets, including encryption operations and org.freedesktop.Secret.Service.OpenSession (tested);
org.freedesktop.Secret.Item; supporting both text and binary secrets.

Next steps towards an alpha release:

org.freedesktop.Secret.Prompt;
org.freedesktop.Secret.Collection;
org.freedesktop.Secret.Service;
tests: unfortunately, it will be hard to test all dbus interfaces until almost everything is done… but let’s stay optimistic!

My top priority is now to develop the prompts, because it is now the last obscure part on my path. I still only have little idea on how I’ll do this in a both easy/maintainable and portable way. My first try may rely on GTK (since I use Gnome). Your suggestions are welcome!

Misc:

I interact with bw through the Vault Management API (see the bw serve command): it is easy and, thanks to a very recent commit [[PM-20220] feat: Add support for fd and unix socket bindings by Game4Move78 · Pull Request #14262 · bitwarden/clients · GitHub], it should be secured as well (we can create and listen a unix socket in the user space);
I run my own Vaultwarden instance; hope this cannot generate some incompatibilities with the official bw servers;
Hope nobody loves bw item’s string custom fields; I use them to store dbus item’s attributes…; the two worlds are not 100% aligned and I need to find compromises;
Hope you love Rust too…

I sincerly hope that I did good choices until now and that I will eventually be able to deliver something…

I keep you in touch. Be patient: it’s my first experience with dbus, I am still quite a noob in the Rust world, I have a demanding job and a family…

See you soon (fingers crossed!),

martijnboers · October 17, 2025, 8:19am

Perfect timing, I’d urge you to build in public so that I and maybe other can help test and/or implement features. At least have a way to track your changes that doesn’t rely coming into this thread every now and then

Tulkas59 · October 17, 2025, 1:12pm

Thank you for your support!

I have managed to implement the prompts with GTK and I am currently finishing the collections. Then I will work on the service and, hopefully, start the tests.

Don’t worry. I am planning to make all the sources publicly available as soon as a very first, more or less functioning, version is ready. I just still don’t know under which license I’ll do that.

I keep you in touch!

Tulkas59 · November 15, 2025, 7:59am

Hello everyone,

I am very happy to give you a glimpse of a very first solution!

SearchItems (attribute-based lookup), GetSecret and item properties’ readers, at least!, are functional. I have identified an issue with the prompt.

Just give me a few weeks more to fix this, conduct more preliminary tests and eventually to publish the code. I will then count on you for more exhaustive tests

Best regards,

Tulkas59 · November 21, 2025, 10:04pm

I finally managed to package something usable. Everything seems functional to me.

Feel free to test it! Since I cannot guarantee that everything is 100% safe, you may want to use a dummy vault for this

The next step is to properly integrate this tool into standard Linux desktop environments (autostart and so on).

See you!

jmylchreest · March 4, 2026, 12:21am

Hello all.

I just stumbled across this thread so I thought I’d share.

I too got annoyed by this, and wrote a service called rosec/rosecd. You can find it here - GitHub - jmylchreest/rosec: A secrets daemon implementing the freedesktop.org Secret Service API with Bitwarden backend · GitHub .

I’ve yet to package it for anything except arch (i’ll push it to the AUR shortly) but in short:

It’s a secure rust based daemon/client. It sits on the secrets dbus endpoints and an additional rosec.Daemon IPC. It has a built in prompter and fundamentally does the following:

Supports n+1 different backends: local vault (RW), bitwarden password manager (RO), bitwarden secrets manager (RO), and soon a direct RO way to access gnome-keyring files directly too for migration.

It has an SSH Agent, and it also exposes the ssh keys via a secure fuse mount - these are across all unlocked backend providers. If you add an ssh-host (or several) attributes to your ssh keys it’ll also create the ssh configs you can just include within that fuse fs too, and ssh-user to set the username.

It supports prompt, search, get, create etc with writes being made to the RW vault options (currently only an encrypted local vault).

It’ll support PAM unlock and MFA vut I’ve not tested these much, and with the rosec client supports pretty rich search functionality.

Collections can be mapped, so writes/reads can be specifically routed but right now, and primarily because of the spec, it only works on the default collection.

Ther eis also a concept of opportunistic unlock, whereby a password will be attempted to unlock across all providers when entered, so if you do happen to share a password, it’ll unlock them all.

Theres a few other things, such as auto lock via logind or a timer, a max unlock period, etc.

most providers are written as WASM guests, they are truly isolated and fully destroyed, and they share no content persistently to disk.

I’m sure there is plenty it needs, but i’ve been using it for a week or so and I have been improving it throughout - maybe it’s useful to you as well.