Page MenuHome GnuPG
Create Task
Maniphest T5036

pinentry won't launch when gpg is invoked by Firefox when Firefox runs with native wayland support in a wayland DE
Closed, DuplicatePublic
Actions

Description

This one is complicated but I've been putting a lot of effort trying to debug this.

There's this web extension called gopassbridge which is a bridge that uses the browser's native messaging API to talk with [[ https://github.com/gopasspw/gopass | gopass ]] which is a password manager that uses gpg. Firefox eventually launches gopass-jsonapi listen which in turn calls gpg in order to decrypt the passwords.

Here's a link to upstream's issue:

https://github.com/gopasspw/gopassbridge/issues/158

And the steps to reproduce, copied from my own comment:

  1. Start a Gnome Wayland session (it could be that other wayland based WM will work).
  2. Start a terminal that works natively with Wayland - such as gnome-terminal.
  3. Run from that terminal the command env MOZ_ENABLE_WAYLAND=1 firefox.
  4. Go to about:support
  5. Use <kbd>Ctrl-F</kbd> and search for _"Window Protocol"_ to make sure native Wayland support is used - it should say wayland/drm See Arch Wiki article.
  6. Now try to use gopass' Web extension.

A note on step 1: I recently switched to using Wayland for my Gnome session and it occurred to me that I had to clear all dconf settings in order for it to launch - see this thread.

Launching Firefox either from an X based terminal or with env -u MOZ_ENABLE_WAYLAND firefox, even in a wayland based DE / WM, doesn't reproduce the issue. Also, launching gopass directly via gnome-terminal also doesn't reproduce the issue.

In fact, it's possible to reproduce the issue even without Firefox and the extension / gopass installed and setup. Launch a Wayland Gnome session and use Gnome's "run command" (<kbd>Alt-F2</kbd> is the default keybinding IIRC) and run there gpg --decrypt file.gpg.

In order to debug this, I run gpg-agent with these debug options enabled:

pinentry-program /home/doron/.bin/pinentry
debug-pinentry
debug 1024

I've also used ~/.bin/pinentry which's a script that wraps my distro's pinentry-gnome3 but logs some information about the environment.

Here's a journal log of gpg-agent with these debug flags set, given a gpg invocation inside gnome-terminal which successfully invoked pinentry-gnome3:

https://gist.github.com/doronbehar/1ee1bf18060b541c473f9d7bb10910a7

Here's another journal log, with a similar setup only that gpg was invoked by Firefox & gopass-jsonapi:

https://gist.github.com/db92e1c5e8defbf7868bcf004c4d0ae7

Here's another firefox journal log I ran when the script that called gopass also included gpg-connect-agent UPDATESTARTUPTTY /bye > /dev/null:

https://gist.github.com/15636485db8a798fa164473072f2bb70

Details

External Link
https://github.com/gopasspw/gopassbridge/issues/158
Version
2.2.20

Related Objects

Event Timeline

doronbehar created this task.Aug 25 2020, 5:41 PM
doronbehar created this object in space S1 Public.
doronbehar added a comment.Aug 25 2020, 6:21 PM

I take some of my words back - using or not using MOZ_ENABLE_WAYLAND=1 doesn't make a difference eventually - If Firefox is launched by Gnome and not gnome-terminal, pinentry fails to launch with and without MOZ_ENABLE_WAYLAND.

• werner added a subscriber: • werner.Aug 26 2020, 9:40 AM

Without really looking at your report: May it be that this is because Pinentry does not get the WAYLAND_DISPLAY variable as reported in T5016? This will be fixed in 2.2.22 which I hope to release this week.

doronbehar added a comment.Aug 26 2020, 2:44 PM

Unfortunately I've had some trouble compiling the latest git version of GnuPG for NixOS - I got this warning which turned out to be a blocker:

***
*** The config script "/nix/store/dxi5i0gwd5c8dakqvdcwmjvqc8mcblpp-libgcrypt-1.8.6-dev/bin/libgcrypt-config" was
*** built for x86_64-unknown-linux-gnu and thus may not match the
*** used host x86_64-pc-linux-gnu.
*** You may want to use the configure option --with-libgcrypt-prefix
*** to specify a matching config script or use $SYSROOT.
***

So I applied this patch:

diff --git i/common/session-env.c w/common/session-env.c
index c1eb1d959..463053104 100644
--- i/common/session-env.c
+++ w/common/session-env.c
@@ -70,6 +70,7 @@ static struct
   { "XAUTHORITY","xauthority"},  /* Xlib Authentication.  */
   { "XMODIFIERS" },              /* Used by Xlib to select X input
                                       modules (eg "@im=SCIM").  */
+  { "WAYLAND_DISPLAY" },         /* For the Wayland display engine.  */
   { "GTK_IM_MODULE" },           /* Used by gtk to select gtk input
                                     modules (eg "scim-bridge").  */
   { "DBUS_SESSION_BUS_ADDRESS" },/* Used by GNOME3 to talk to gcr over

On the 2.2.20 version which NixOS ships currently, (2.2.21 should reach us shortly) . It didn't solve the issue. But I think it's observable that this environment var is seen by gpg-agent according to this yet another gpg-agent journal log:

https://gist.github.com/fd78b77ca960b0eb0ce332af515386fc

• werner added a comment.Aug 26 2020, 3:05 PM

The warning above is harmless. Both strings are actually the same but stem from different versions of the autotools helper scripts

According to your log there is no ttytype set; check that $TERM has been set.

• werner added a comment.Aug 26 2020, 3:11 PM

Ah wait. This has been fixed in master a year ago but was not backported to 2.2; see T4137. I'll add it to the forthcoming 2.2.22. Thanks for the report.

doronbehar added a comment.EditedAug 26 2020, 3:13 PM

But @werner what's the value $TERM *supposed* to have? When gpg is invoked straight by Gnome? I can run the command sh -c 'env | grep TERM > ~/gnome-term.env' in Gnome's "Run Command: interface and then the file ~/gnome-term.env says TERM is set to nothing (It is set, but the contents is a "" string).

• werner added a comment.Aug 26 2020, 3:16 PM

Mails crossed ;-)

doronbehar added a comment.Aug 26 2020, 3:17 PM

I see. Thank you @werner . For clarity could you please link the patch that was not backported to 2.2.?

• werner added a comment.Aug 26 2020, 3:19 PM

rG4c8d5eb0bdd3: agent: Allow TERM="".

• werner closed this task as a duplicate of T4137: IPC syntax error when `gpg` starts `gpg-agent` without `$TERM` variable.Aug 26 2020, 3:19 PM
doronbehar added a comment.Aug 26 2020, 3:20 PM

Thank you for your prompt help. It's much appreciated.

doronbehar added a comment.Aug 26 2020, 3:31 PM

It worked! You were right!

THANK YOU :)

• werner added a comment.Aug 26 2020, 3:48 PM

I am always glad to fix such bugs before a release (I am about to prepare 2.2.22).

doronbehar added a comment.Aug 26 2020, 4:12 PM

I am always glad to fix such bugs before a release (I am about to prepare 2.2.22).

Great :)

You know, there are lots of password managers out there, and I think I never used GnuPG for real emails encryption. One feature that truly lacks in all of these systems is what gpg-agent and the pinetry programs provide - a single systemd service that runs for all of the user's sessions, and a pinentry program that's configurable, using PINENTRY_USER_DATA. This convenience is irreplaceable and I thank you dearly for not leaving me no choice but to switch a password manager :).