Add support for rbw, Bitwarden CLI alternative

[justbispo]

I've seen that this tool already supports the Bitwarden CLI and mentions the con:

Session token expires (need to unlock regularly)

rbw solves it by holding the keys in memory. There is also no need for the user to run the commands to login or unlock directly:

Commands can generally be used directly, and will handle logging in or unlocking as necessary. For instance, running rbw ls will run rbw unlock to unlock the password database before generating the list of entries (but will not attempt to log in to the server), rbw sync will automatically run rbw login to log in to the server before downloading the password database (but will not unlock the database), and rbw add will do both.

So it'd be nice to also support this tool.

[jdx]

sounds good to me

[empjustine]

Session token expires

Is this really true? I have kept my BW_SESSION opened for literally weeks a time, I only need to regenerate it if I accidentally generate a second BW_SESSION, as that ends up re-encrypting data on the ${BITWARDENCLI_APPDATA_DIR:-$HOME/.config/Bitwarden CLI)/data.json file

[justbispo]

I think you're correct, but isn't that kinda defeating the purpose? I suppose you export the token as an env var in some file like .bashrc.
Sure, the session never expires but it's way less secure, if some malicious program reads the token, they can access your passwords.

[kafendt]

I would also welcome support for rbw. For me the bitwarden CLI is extremely slow which leads to fnox taking a long time. I have tried fetching via bw and via rbw. bw takes about ~1s whereas rbw is ~10ms.

So even just for performance it would be great.

[nilleb]

I was uberly curious about rbw (given its stateful support and speed) - so I added support while testing rbw. You can give it a try here: nillebco:feat/bitwarden-rbw-support #91

Any (constructive) feedback is welcome, thank you!

[justbispo]

Seems like this was implemented, albeit experimental, in 1.5.0 (which doesn't show up in the releases page) with @nilleb's PR #91.