Browserpass does not unlock GPG keys in Firefox + GNOME 3
nonnymoose opened this issue · comments
General information
- Operating system + version: Arch Linux
- Browser + version: Mozilla Firefox 68.0.1, Mozilla Firefox Developer Edition 69.0b8
- Information about the host app:
- How did you install it?
Installed via a package manager - If installed an official release, put a version (
$ browserpass --version): 3.0.6
- How did you install it?
- Information about the browser extension:
- How did you install it?
Installed via a package manager - Browserpass extension version as reported by your browser: 3.1.1
- How did you install it?
Exact steps to reproduce the problem
- Configure pass to use a password-protected GPG key (
pass init id_of_password_key) - Install
browserpassandbrowserpass-firefox - Create at least one entry in the pass store
- Do not unlock the GPG key, or, if you have already, kill the
gpg-agentprocess - Go to a website that corresponds to an entry in the pass store
- Attempt to autofill a login, copy a password, or copy a username
What should happen?
Note: this does happen in Chrome(ium)
The gpg-agent pinentry dialog should appear and allow the user to unlock the key. If they unlock the key successfully, browserpass should complete the requested action. Otherwise, it should report an error.
What happened instead?
In Firefox, browserpass simply displays e.g. "Filling login details" for a fraction of a second, and then fails silently and does not complete the action.
Hey, browserpass is not doing anything to unlock the keys, it simply calls gpg process to decrypt the file. Something must be off with your gpg or gpg-agent configurations...
try to launch Firefox from terminal, would that help?
I launched Firefox from the terminal and nothing changed. There was also no output on the terminal.
At first, I was certain it was a problem with my configuration, but I tested it on Chromium and it worked just fine. Does the native host connector do anything different with Chromium vs. Firefox?
Here is my personal gpg configuration:
dirmngr.conf:
keyserver hkp://jirk5u4osbsr34t5.onion
keyserver hkp://keys.gnupg.net
honor-http-proxy
gpg.conf:
keyserver hkp://keys.gnupg.net
cert-digest-algo SHA256
no-emit-version
no-comments
personal-cipher-preferences AES AES256 AES192 CAST5
personal-digest-preferences SHA256 SHA512 SHA384 SHA224
ignore-time-conflict
allow-freeform-uid
gpg-agent.conf:
default-cache-ttl 300
max-cache-ttl 1200
pinentry-program /usr/bin/pinentry-gnome3
Well, I found the culprit. It only doesn't work when firefox causes the native extension to call gpg and the pinentry program is set to pinentry-gnome3.
Does the native host connector do anything different with Chromium vs. Firefox?
No it's exactly the same code 🙂
Well, I found the culprit. It only doesn't work when firefox causes the native extension to call gpg and the pinentry program is set to pinentry-gnome3.
Nice job! Although I've just tried, and I don't reproduce the issue if I switch to pinentry-gnome3 (I'm also on Arch using latest Firefox). So I still think it's something related to your config...
Here are my configs btw: https://github.com/maximbaz/dotfiles/tree/master/.gnupg
uhh... Wow, our setups are really similar...
Are you using Gnome as your desktop environment?
Judging by the fact that you're using dmenu I would guess that you're using i3. ;)
Correct, I use lightdm + i3wm :)
I knew this issue was familiar to me! This is not the first time people are having issues with Firefox, and it seems pinentry has always been the culprit: browserpass/browserpass-legacy#281, browserpass/browserpass-legacy#266, browserpass/browserpass-legacy#303
Oh no...
So, this issue only happens
- If you're using Firefox,
- If you're using
pinentry-gnome3, and - If you're using the GNOME desktop environment
(I tested it on i3 and it worked)
Nice findings!! I hate to just tell people to switch to another pinentry, but I'm really not sure where to report this issue if we want this to get fixed... To Firefox? To GNOME? 🤔
I can't tell yet...
Here's what I've found so far through testing:
- There's no significant difference in the environment variables of gpg when called from firefox vs. when called by chrome
If firefox is in focus when pass is run from the terminal, the pinentry dialogue appears (so that means that it's not some sort of obscure window conflict issue between firefox and pinentry-gnome3)- There's no significant difference in the environment variables of pinentry-gnome3 when called from firefox vs chrome
Edit: I did an awful job of that 🤷♂️
So, I found the problem. Turns out it was an obscure windowing conflict. Firefox steals focus from all other programs (you can't even use the GNOME 3 hot corner) when you have an extension dialogue box open. If you steal focus from pinentry-gnome3, it interprets it as a cancellation. Therefore, a GNOME pinentry popup cannot display while you have an extension dialogue box open. Looks like it is a Firefox bug after all.
I submitted a bug on the Firefox bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1571259.
Blocked pending external resolution in Firefox. Reopening issue in order to keep track of it, as it seems likely other users will run into this.
@nonnymoose Thanks very much for your work in tracking this down. Rather annoying issue, although I must admit I'm not terribly surprised... Firefox's QA isn't terribly good in my experience, so this is just another implementation bug to add to a rather long list.
Thanks also for opening a bug against Firefox - will keep an eye on that :-).
I found a somewhat complicated workaround to only use the GTK2 pinentry program for browserpass, for anyone else having the same problem who wants to keep the GNOME 3 pinentry.
- Download these two files somewhere permanent and remove the .txt extension (really, github?)
gpg-fallback.py.txt
pinentry-gnome3_gtk2-fallback.txt - Make them both executable
- Set your pinentry program in
~/.gnupg/gpg-agent.confto the path ofpinentry-gnome3_gtk2-fallback - Set your gpg binary in the browserpass extension settings to the path of gpg-fallback.py.
The actual issue even isn't with pinentry-gnome3. I use sway as my DE (and it works with wayland, of course) and pinentry-ncurses/qt fails to work as well.
would you share that please on the bug @nonnymoose has created for Firefox?
Thanks for tracking this down @nonnymoose . I've been wrestling with this myself. I like your workaround.
A more straightforward, but less theme-appropriate workaround is simply using pinentry-gtk2 as a default by adding the line
pinentry-program /usr/bin/pinentry-gtk-2
to ~/.gnupg/gpg-agent.conf
Talked to @erayd, agreed to keep this issue closed since it's not actionable for us, it is labeled appropriately so that it is easier to find later.
strange that I'm not experiencing this with PassFF