Quick Access menu like in 1Password

[mufeedali]

Hi! Something I really like about the 1Password desktop app that I miss a lot in Bitwarden is the ability to just click "Ctrl+Shift+Space" and search for the account I want and then click "Ctrl+Shift+C" to get its password. It's great when the regular autofill misbehaves or something like that or if you want enter any credentials in a terminal.

Btw, few unrelated questions:

1. I installed the RPM and set it up as per the Getting Started, everything works as expected from the terminal, but how do I access the GUI from the RPM package?
2. Is there any way to check if my Notifications URL is working as intended (self-hosted)?
3. Is the flatpak now the recommended way to install? If so, how do I uninstall the RPM?
4. This project means a lot to me. It's everything that I'm missing to move back fully to Bitwarden again. I want to donate to keep the project alive. Is there any way to do that?

[quexten]

Awesome idea! The current "autotype" feature works somewhat like 1Password's quick access menu, albeit not as feature complete. You can enter the name of a credential (i.e "GitHub") and hit enter for autotype, "u" for copying the username and "p" for copying the password. But this can definitely be extended.

[quexten]

#76

[quexten]

I installed the RPM and set it up as per the Getting Started, everything works as expected from the terminal, but how do I access the GUI from the RPM package?

The RPM does not have UI support currently, you need to additionally install the Flatpak. You can use the cli tool from the RPM in conjunction with the flatpak, since neither version supports all features currently.

Is there any way to check if my Notifications URL is working as intended (self-hosted)?

Yes! Run: goldwarden vault status. This should show whether the websocket connection is established or not.

Is the flatpak now the recommended way to install? If so, how do I uninstall the RPM?

Yes and no. If you just need autotype and/or ssh key support it is enough, but not all features are supported yet. You don't need to uninstall the rpm, but if you want to, it should be rpm -e <rpm_name>

This project means a lot to me. It's everything that I'm missing to move back fully to Bitwarden again. I want to donate to keep the project alive. Is there any way to do that?

Thanks for the kind words! Sadly, I'm not sure if I'm able to accept donations for this project currently.

[quexten]

If you need both the cli features and the flatpak, just install the flatpak, and configure your environment variables as shown in: https://github.com/quexten/goldwarden/wiki/Flatpak-Configuration

and for ssh keys the flatpak section of: https://github.com/quexten/goldwarden/wiki/SSH-Login-&-Git-Commit-Signing

[quexten]

I think for your use-case, the auto-type menu is actually enough, since it supports copying username and passwords. Though discoverability of this feature could be improved, maybe by just renaming it to "quick access" and then labeling all the actions (auto-type, copy username, copy password, [yet unimplemented copy totp])

[mufeedali]

I think for your use-case, the auto-type menu is actually enough, since it supports copying username and passwords. Though discoverability of this feature could be improved, maybe by just renaming it to "quick access" and then labeling all the actions (auto-type, copy username, copy password, [yet unimplemented copy totp])

Yep you're right! I just didn't know the copy features existed as I saw no indication of it in the CLI.

If you need both the cli features and the flatpak, just install the flatpak, and configure your environment variables as shown in: Wiki: Flatpak Configuration ()

So I think I got all of it working:

I have the autofill working too but the flatpak can't seem to tell that. Is that a bug?

You don't need to uninstall the rpm, but if you want to, it should be rpm -e <rpm_name>

Oh yeah, I should have specified. I was talking about how to revert the changes done by goldwarden setup processes.

Run: goldwarden vault status

Looks like it's working! Thanks!

Thanks for the kind words! Sadly, I'm not sure if I'm able to accept donations for this project currently.

No worries, just super thankful for your work!

[quexten]

I have the autofill working too but the flatpak can't seem to tell that. Is that a bug?

It's hard-coded right now. It can't detect settings outside of the flatpak due to sandboxing. Ideally this will be changed when #39 is done.

[quexten]

Oh yeah, I should have specified. I was talking about how to revert the changes done by goldwarden setup processes.

For polkit, leave it as is. The flatpak benefits from that step. For systemd, it's systemd --user disable goldwarden.service --now, and optionally deleting ~/config/systemd/user/goldwarden.service.

[quexten]

Converted to a discussion, If you have a specific feature from the 1password quick access menu, please make a separate feature request, since this was more of a Q&A :)

[mufeedali]

If you have a specific feature from the 1password quick access menu,

I guess it would be configurable shortcuts for copying the username, password and totp (which ig isn't present yet) just because I'm used to the 1Password shortcuts, but then again, I can see myself getting used to this too.

Btw, is there any way for me to get rid of the pin? I want the lock and unlock to be only polkit-based and not require an additional pin.

[quexten]

Polkit an the pin serve two different purposes (somewhat). Since we do not want to expose the vault to someone having access to the disk on boot (unencrypted main volume, etc), the pin is required to derive a key to decrypt the vault. If this were not the case, anyone with access to your (unencrypted) disk, or an unfortunate backup that captured the config, could access your vault.

Polkit only does authentication, no key derivation. Thus, it is only useful once the encryption key is already present in memory.

The two (not great) alternatives are: storing the key in libsecret - which makes the disk image unproblematic at least, but exposes the key to the user's other running processes. And alternatively, using no encryption, but this is just really not great, due to the mentioned attack above. Maybe I will introduce an environment variable such as GOLDWARDEN_NO_PIN_THIS_EXPOSES_YOUR_VAULT_TO_YOUR_DISK=true, so that way the user is aware of the risk.

[mufeedali]

I don't understand why not just handle in memory? Both of the coolest apps I'm using right now for Bitwarden, one being Goldwarden and the Keyguard (for Android) both have external passwords protecting the locally stored vault. I don't understand why something like 1Password's model wouldn't work. Since the application is aware of Bitwarden credentials anyway, wouldn't it make sense to just ask for that when required?

[quexten]

But is this not what Goldwarden does? As the 1Password article states, instead of a pin, your account password is used to "encrypt" your vault [internally they most likely use a KDF derived key]. So as far as I can tell - without having used 1Password - on boot you have to enter your account password at least once. After entering the password on boot, the key is stored in memory - just like Goldwarden, albeit Goldwarden applies additional memory hardening to prevent other processes from accessing the key - and only polkit is required.

So, the workflow is - as far as I can tell - the same: Boot -> enter password/(pin) 1x -> use system auth (all the time)

The only difference is that Goldwarden expects you to set your own pin, whereas 1Password wants your account password. I suppose, we could add a mode to use your account password instead, but then you could also just set your account password as the pin and get the same behaviour.

[mufeedali]

So, the workflow is - as far as I can tell - the same: Boot -> enter password/(pin) 1x -> use system auth (all the time)

Something must be wrong with my setup then. For me, whenever the vault auto locks, i have to type the pin again. I'll test more thoroughly and let you know

[quexten]

Thanks, yes that's a bug then. The pin being asked again is expected to happen when the polkit is not working, but even then there should be a fallback to the "pkexec" policy. Might also test some weird conditions on my side and add better notification about this.