Google Chrome (and Firefox as well I assume) support libsecret’s dbus API which allows it to use KDE Wallet and Gnome Keyring on Linux as a password manager instead of the built-in one. If support for it was added, BitWarden would be the first password manager to have native browser support for password/secret completion. Additionally it would allow for BitWarden to be used elsewhere on Linux:
Git
VS Code Live Share, it supports gnome-keyring and it depends on libsecret. I haven’t looked in depth, but it could just as well use the libsecret dbus API.
GnuPG, using pinentry-libsecret afaik.
Display managers (programs that handle the login on Linux): GDM, LightDM, LXDM, SDDM
You get the gist, it would make BitWarden a possible replacement for Gnome Keyring and KDE Wallet. It could make the browser extension mostly unneeded for Linux.
The API specs are found here: secret-storage-spec I assume that 0.1 stable is used in Chromium and others. I haven’t looked that deep into it.
I would personally be up for helping this become a reality (though atm I’m having exams at university for another month). What is your opinion on adding support for this?
That’s good to know. But that’s not what I’m suggesting. I’m suggesting that BitWarden can be used like GNOME keyring. Other clients can store secrets in BitWarden using the same process as GNOME keyring. This would allow the replacement of GNOME keyring and KDE Wallet in many places. Do you get what I mean?
I would have to explore how the GNOME keyring is used for Linux users since I am not familiar with it (I am on Windows). Is it just a built-in password manager for the Linux desktop environment?
You could compare it with MacOS Keychain, however it’s not very user friendly as it’s a pretty basic application. Some use cases:
When I commit something it is signed with my PGP key, but my PGP key has a passphrase. So it asks GNOME keyring for that passphrase and GNOME keyring will give it to Git when it’s unlocked. If it’s locked, it will ask for the GNOME keyring password. This could instead be BitWarden that keeps the PGP key passphrase stored and Git could ask BitWarden (this is configurable).
When you login on Linux, you can enable a fancy display manager. A display manager is what you see on Windows when you’re asked to login. Normally without a display manager, it’s just a terminal that asks you for your username and password. The login manager can provide a fancier way and allows for customisation, most Linux distros have a default one like Ubuntu uses GDM3 iirc. These display managers can automatically unlock the GNOME keyring or KDE Wallet when you login so you no longer have to. It can then be locked again when you lock your screen for example.
VS Code Live Share stores its authentication token from your GitHub/Microsoft account in GNOME keyring. The same thing applies as with Git.
GNOME keyring is included in most GNOME desktop environments, but it can also be installed separately without using the GNOME desktop environment.
This is probably not something I will invest any time with in the near future, so feel free to explore some of it on your own if you’d like to see what is possible.
I’m open to review a PR on anything really. I can’t promise I’ll accept it any time soon (mostly depending on how large of a change it is), but I am happy to review whatever you uncover, if only a POC.
I made a proof of concept and I’ve outlined that issues that I’m facing. I only did this in 2 evenings time, which shows that it shouldn’t be an immense undertaking. Most of it is solely wrapping the API to the BitWarden internal API of the application. Though it is most likely that we’ll need to create our own DBus library, see my reasoning in the README.
What are your priorities for BitWarden in terms of adding features like this? Do you have any experience in adding a daemon to Electron projects as this is something that would need to remain running from the moment that you login to your Linux machine.
Also I’m curious as to why feature requests were moved to a separate forum. I feel like many people who would like to support BitWarden are software developers and many of them are not going to create an account so that they can “vote” for a feature request. I’d love to try and show that there is an interest in this, but no one is going to create an account to voice that opinion. Only the people that are very vocal about their opinion are going to do that, which is why I created this account. Because this is something I badly want to see happen on Linux.
Thinking about this more, honestly it seems out of scope for Bitwarden at this time. Would it make more sense to just use the CLI tool to sync the Bitwarden vault to the Gnome Keyring? That way you are not limited by Electron or TypeScript environments and you can do it however you like.
That seems like a hacky way to go around it. Could the API perhaps be documented so I could write my own Linux client that supports this? I’d rather just write an entire client in my own language that I can maintain and that way I also don’t have to use Electron. Electron just uses way too much RAM for something like this when you want to support low-end devices, which there are many of on Linux.
Yes, that is what I suggested. As others have done, you can use the CLI to power that client, which is documented here: https://help.bitwarden.com/article/cli/
Why is it not meant for public use though? I feel like there’s a fear that people will create their own clients and work around the current premium features. Just know that these people wouldn’t have paid for BitWarden in the first place and aren’t the consumers you want.
What do you mean with encrypted as well? If the API is documented, then that’s a non issue.
I also don’t mind having to do more work, as long as there is a well documented API. To me it feels like you are avoiding the subject here and at the issue requesting for a documented web API.
The latest comment on there is also referring to the low amount of votes. There are only a few outliers with a large amount of votes. Many people don’t create an account to just have a vote.
To me it feels like you are avoiding the subject here and at the issue requesting for a documented web API.
I don’t mean to come over as rude, but I think the lack of response from your end on issues like this speaks louder than words? I still stand by my previously made points where I’ve got the feeling that you are afraid of people stealing your cake when they make their own clients. Then using those clients to circumvent features currently only available to premium subscribers. But I’m just repeating my own words when I say that those people are not your customers. They do not intend on paying in the first place and you are only harming your existing customers.
Lastly I feel like the move to a community forum, away from GitHub, is just making an echo chamber as most people aren’t going to make an account to vote for something they like.
I too wanted D-Bus integration, so I’ve started writing a client daemon that implements the secrets D-Bus service. See https://github.com/mvdan/bitw - contributions are welcome.
I was a bit disappointed when I’ve discovered that Bitwarden doesn’t fit with the Linux desktop environment despite of the opensouce library
I hope that the project of these guys will be integrated soon.
I don’t think it would make sense to integrate bitw into bitwarden-cli or the desktop app - for one, the official clients are written in Node, and bitw is written in Go. The Go client is also standalone, so it reimplements login, storing data on disk, etc.
It would certainly be possible for the official clients to implement the D-Bus service, like bitw does - even copying some of the design. Though upstream has expressed that this is not part of the roadmap, hence the alternative client with the different scope and purpose.