Bitwarden starts using the OS password manager service, and it's breaking
Hello,
As this thread has a lot of history, we felt it would be good to summarize the current status of the issue and the options available.
Summary of current behavior
The current version (2024.5.0
) uses libsecret
to communicate over D-BUS with the org.freedesktop.secrets
Secret Service implementation (e.g. gnome-keyring
) in order to store persistent authentication tokens if your vault timeout action is "Lock". If there is no such service configured (or the application has issues communicating with the service), the current version does not have any built-in fallback to disk storage for the tokens, which is what is causing the errors experienced in this ticket. The mechanism for fallback will be introduced in the next release of our desktop application, as we are doing extensive internal testing to make sure that we do not introduce any regressions in behavior across all of the affected OSes.
As there are a lot of different parties involved in that communication path, we have seen some issues arise and raised on this thread. We'd like to highlight them below and make sure that the solutions are documented. We will also be updating our Help Center documentation to reflect this in more detail as we release the next update.
🗒️ Issue 1: The application doesn't have permission to communicate over D-BUS to the Secret Service
For our Snap sandboxed deployments, it is necessary to grant the application permission to access the service via D-BUS. This can be done with sudo snap connect bitwarden:password-manager-service
.
🗒️ Issue 2: There is no Secret Service configured
As some have noted, configuring gnome-keyring
will satisfy this requirement. It was an oversight on our part to not provide documentation for those users who would not have such a provider configured by default.
For those using kwallet
, additional configuration may be required, as @Caligatio called out here:
[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/kwalletd6
In addition, there is a recent bug reported with Flatpak and kwallet
that would potentially affect Flatpak users who are attempting to use kwallet
as their secret provider.
If you do not have a Secret Service configured, and prefer not to do so, this build is available to install. This is the build currently under test for our next release. This is a development build and we recommend backing up your vault before use.
Once again, we thank you for your patience as we work through this issue. If there are any problems that do not conform to these assumptions, please raise them so that we can make sure that we take them into consideration.