Browserpass does not unlock GPG keys in Firefox + GNOME 3

Question

Browserpass does not unlock GPG keys in Firefox + GNOME 3

nonnymoose opened this issue 5 years ago · 21 comments

nonnymoose commented 5 years ago

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
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

Exact steps to reproduce the problem

Configure pass to use a password-protected GPG key (pass init id_of_password_key)
Install browserpass and browserpass-firefox
Create at least one entry in the pass store
Do not unlock the GPG key, or, if you have already, kill the gpg-agent process
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.

Answer 1 · 2019-08-03T20:21:05.000Z

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?

Answer 2 · 2019-08-03T20:55:38.000Z

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?

Answer 3 · 2019-08-03T21:02:14.000Z

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

Answer 4 · 2019-08-03T21:06:40.000Z

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.

Answer 5 · 2019-08-03T21:11:56.000Z

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

Answer 6 · 2019-08-03T21:15:47.000Z

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. ;)

Answer 7 · 2019-08-03T21:17:02.000Z

Correct, I use lightdm + i3wm :)

Answer 8 · 2019-08-03T21:21:58.000Z

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

Answer 9 · 2019-08-03T21:31:41.000Z

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)

Answer 10 · 2019-08-03T21:35:33.000Z

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? 🤔

Answer 11 · 2019-08-03T21:48:00.000Z

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 🤷‍♂️

Answer 12 · 2019-08-04T01:58:54.000Z

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.

Answer 13 · 2019-08-04T02:27:13.000Z

I submitted a bug on the Firefox bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1571259.

Answer 14 · 2019-08-04T04:13:15.000Z

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.

Answer 15 · 2019-08-04T04:15:05.000Z

@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 :-).

Answer 16 · 2019-08-04T16:09:49.000Z

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.conf to the path of pinentry-gnome3_gtk2-fallback
Set your gpg binary in the browserpass extension settings to the path of gpg-fallback.py.

Answer 17 · 2019-08-05T04:13:37.000Z

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.

Answer 18 · 2019-08-05T07:00:03.000Z

would you share that please on the bug @nonnymoose has created for Firefox?

https://bugzilla.mozilla.org/show_bug.cgi?id=1571259

Answer 19 · 2019-08-21T23:46:27.000Z

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

Answer 20 · 2019-10-19T21:42:52.000Z

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.

Answer 21 · 2021-02-21T12:10:29.000Z

strange that I'm not experiencing this with PassFF