FS#74175 - [bitwarden-cli] Login to Vaultwarden instances with email and password is broken

Attached to Project: Community Packages
Opened by Guruprasad L (lgp171188) - Sunday, 20 March 2022, 17:24 GMT
Last edited by Toolybird (Toolybird) - Thursday, 18 May 2023, 23:22 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Alexander Epaneshnikov (alex19EP)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

The 1.22.0-1 version of the Bitwarden CLI package in Arch Linux is breaking logging in to a Vaultwarden (an API-compatible Bitwarden clone) instance using email and password. Logging in using this method returns an error that says that the username and password are incorrect, even though they are verified to be correct (via the Bitwarden app login and the web vault login). This was reported on the Vaultwarden issue tracker and confirmed to be an issue specific to the Arch Linux package. The upstream and the snap versions of the CLI do not exhibit this issue at all.

Vaultwarden bug report - https://github.com/dani-garcia/vaultwarden/issues/2378#issuecomment-1073286147
Comment with the relevant details from a Vaultwarden contributor who verified that this is an issue with the Arch package - https://github.com/dani-garcia/vaultwarden/issues/2378#issuecomment-1073286147

Additional info:
* package version(s) 1.22.0-1
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:
* Install the affected version of the Bitwarden CLI.
* Configure it to connect to a self-hosted Vaultwarden instance - `bw config server <self-hosted instance's domain>`.
* Login using the bitwarden CLI - `bw login`. Enter the correct email address and password.
* The backend and CLI report that the credentials are invalid even though they are.

The Vaultwarden developer mentions the following as the potential reasons for this bug.

> This either is because Arch is using a newer version of NPM, or it is not using the correct jslib commit which uses a different API endpoint.
This task depends upon

Closed by  Toolybird (Toolybird)
Thursday, 18 May 2023, 23:22 GMT
Reason for closing:  No response
Comment by Guruprasad L (lgp171188) - Sunday, 20 March 2022, 17:27 GMT
> The Vaultwarden developer mentions the following as the potential reasons for this bug.

I meant to write 'A Vaultwarden contributor mentions ...'.
Comment by Guruprasad L (lgp171188) - Monday, 21 March 2022, 04:52 GMT
According to an upstream contributor, this seems to be the issue.

> Great. I just looked at the commits of jslib and it looks like it is a change that is for the future. And looking at the PKGBUILD file, it seems to always pull the latest jslib in instead of using the commit-hash linked to the tagged cli version.

The package should be using the '9aad63f' commit of 'jslib' linked to the 1.22.0 version instead of pulling in the latest changes always.
Comment by Alexander Epaneshnikov (alex19EP) - Monday, 21 March 2022, 23:01 GMT
> Great. I just looked at the commits of jslib and it looks like it is a change that is for the future. And looking at the PKGBUILD file, it seems to always pull the latest jslib in instead of using the commit-hash linked to the tagged cli version.

git submodules takes care that this doesn't happen. I think there is some other reason. probably too new version of nodejs... please can you check with community/nodejs-lts-gallium?

Loading...