#930062 pinentry-gnome3 grabs keyboard and mouse input despite --no-global-grab or 'OPTION no-grab'

Package:
pinentry-gnome3
Source:
pinentry
Description:
GNOME 3 PIN or pass-phrase entry dialog for GnuPG
Submitter:
Emmanuel Revah
Date:
2025-04-13 05:42:03 UTC
Severity:
normal
Tags:
#930062#5
Date:
2019-06-06 10:44:30 UTC
From:
To:
Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I opened Thunderbird and selected an encrypted message. Or, I opened Thunderbird and the first message on the list is encrypted.

   * What was the outcome of this action?

A dialog window pops up and asks me to enter my gpg passphrase, and takes over the desktop.

   * What outcome did you expect instead?

I expected to be able to leave that window on the side and use other programs (Pidgin, volume control, etc). I can see other windows and mouse actions seem to work, but anything keyboard related does not work. I can navigate in Firefox, but I can't enter a new url, I can't edit text in Vim or type something in Pidgin, but I can clock the volume controle in the task bar

I'm using KDE/Plasma, it seems this behaviour is also present on Gnome and possibly other desktops.


Thanks for any possible help and/or explanations to help me understand what's up.
:]

#930062#10
Date:
2019-06-26 18:03:09 UTC
From:
To:
Hi Emmanuel--

Thanks for the report!  An explanation follows, along with some
diagnostics and an upstream bug report.  But as a caveat, i should warn
you that i personally prefer the system-modal prompting, because as i
understand it:

 a) it ensures that i don't accidentally type into another window when i
    think i'm typing in the prompter

 b) it keeps other X11 clients from sniffing the keyboard input

All that said, there are still some weird bugs in here…
 […]
 […]

The thing that's taking over your keyboard and mouse is pinentry.
It's doing that because (sorry about the long chain here):

  * thunderbird wants to read a message
  * enigmail notices that the message is encrypted, and asks gpg to
    decrypt it
  * gpg notices that it is encrypted to a secret key, which it does not
    control directly, so it asks gpg-agent to use the secret key on its
    behalf
  * gpg-agent checks its passphrase cache and realizes that it doesn't
    have the a passphrase so it needs to ask the user by invoking
    pinentry
  * pinentry (implemented by pinentry-gnome3) in turn invokes gnome's
    gcr service via dbus, to prompt the user for a password.
  * gcr prefers to grab the desktop inputs, to avoid other
    processes snooping on your password as it is typed.  it's not clear

whew!

Note that gpg-agent's configuration has a choice of "grab" and
"no-grab", with "no-grab" being the default.  This choice is (i believe)
supposed to change whether pinentry receives the "OPTION no-grab"
directive or "OPTION grab" (see
https://salsa.debian.org/debian/gnupg2/blob/debian/master/agent/call-pinentry.c#L423
)

but that doesn't seem to have any effect on gcr, as tested by:

   printf 'OPTION no-grab\ngetpin\n' | pinentry-gnome3

Furthermore, pinentry-gnome3 appears to ignore its documented
--no-global-grab option:

   printf getpin\n' | pinentry-gnome3 --no-global-grab

still does a global grab.

This is because gcr's prompting is by definition system modal, i think:

https://developer.gnome.org/gcr/3.20/GcrSystemPrompt.html

As a workaround, since you're using KDE and plasma anyway, you could try
uninstalling pinentry-gnome3, but leaving pinentry-qt installed.  This
should make the system fall back to using pinentry-qt, which i believe
doesn't have the same behavior.

I've opened https://dev.gnupg.org/T4587 to try to address the
contradictions between the documentation and behavior of
pinentry-gnome3.

#930062#23
Date:
2019-06-26 18:26:47 UTC
From:
To:
sorry, this last sentence got cut off.  it was:

   it's not clear to me how to use gcr in a non-system-modal
   (non-grabby) way.

#930062#28
Date:
2019-06-27 08:00:12 UTC
From:
To:
Thanks Daniel for the detailed explanations.

I (apt) removed pinentry-gnome (and as you guessed, I already had
pinentry-qt installed), and now Enigmail cannot open any encrypted
emails, it displays the error message "GnuPG cannot query your
passphrase via pinentry."

I tried adding the option "pinentry-program /usr/bin/pinentry-qt" to
.gnupg/gpg-agent.conf, which doesn't change anything. I then reinstalled
pinentry-gnome which does not restore previous behaviour.

I've no access to encrypted emails via Thunderbird for now. I will not
be able to do much because I'm on a very bad connection for the next few
days/week.


cheers,

#930062#33
Date:
2019-06-27 08:28:43 UTC
From:
To:
I managed to get things back to normal, perhaps this can help (at least
someone).


In .gnupg/gpg-agent.conf I went from "pinentry-program pinentry-qt" to
"pinentry-program pinentry". After each edition of that file, I did
`killall gpg-agent`, and to test (from Enigmail troubleshooting doc) :

gpg-connect-agent <<EOT
GET_CONFIRMATION Hello
EOT

When "pinentry-program" set to "pinentry-qt" (with or without the full
path), I get the error "ERR 67108949 No pinentry <GPG Agent>". However,
with other tests, such as:

pinentry-qt <<EOT
SETDESC Hello World
CONFIRM
EOT

I can see the QT Pinentry prompt.

I have to either comment out "pinentry-program" or set it to "pinentry"
and everything is back to "normal".

I'm not sure where to go from here, for now, I can at least read emails
as usual.



Cheers,

#930062#38
Date:
2019-06-27 15:41:09 UTC
From:
To:
"pinentry-program pinentry" is probably the same as no line at all (it
is the default).  I strongly recommend sticking with the simplest
default configuration possible, so removing that line is good.

but note that pinentry-program expects the full path
(e.g. /usr/bin/pinentry-qt), not the unadorned program name.  I think
that's an unnecessarily broken behavior that only gets in the way of
debugging. i've just documented that concern upstream at
https://dev.gnupg.org/T4588 (this is a separate issue from the current
discussion, of course).

You can also use "gpgconf --kill gpg-agent"

this can also be run as:

     gpg-connect-agent 'GET_CONFIRMATION Hello' /bye

Is pinentry-gnome3 still installed?  If you don't want a grab, it should
not be installed.

So:

 * You should have only pinentry-qt installed (and no other `pinentry-*` packages)

 * You should have no `pinentry-program` line in your gpg-agent.conf.

 * "readlink -f $(which pinentry)" should point to /usr/bin/pinentry-qt

 * You should terminate your running gpg-agent after making all of the
   above changes, with "gpgconf --kill gpg-agent"

if all of these conditions are met, then the following should give you a
QT-based, non-grabbing confirmation prompt:

    gpg-connect-agent 'GET_CONFIRMATION Hello' /bye

If this doesn't work for you, then something else is more seriously
wrong, and i'd like to understand it better.

#930062#43
Date:
2019-07-09 09:58:46 UTC
From:
To:
Le 2019/06/27 17:41, Daniel Kahn Gillmor a écrit :

I did have the full path (I tested both). I've removed it altogether
now.

[...]

I've followed these steps carefully, on 2 computers, both on Debian
Buster, 64 bit. The only thing that seems logic to me is that there
might be an issue with pinentry-qt itself.

If I remove all pinentry-* except for qt and clean gpg-agent.conf file
(remove pinentry conf) I get the error "ERR 67108949 No pinentry <GPG
Agent>".

Any combination of either, only having pinentry-qt installed, or the
config file pointing to it, will result in this error.

I installed pinentry-fltk and then pinentry-gtk2, and things work as
expected. Even if I have multiple pinentry-* things installed,
gpg-agent.conf is read and will use pinentry-fltk (or gtk2) as expected.
If the config file doesn't have `pinentry`, then whatever `readlink -f
$(which pinentry)` points to is used. This seems to be the expected way
of behaving (install one or more pinentry programs, have a system
default, override-able in user config).

I can use pinentry-qt to get a dialog window, it just does not work with
GPG in my case.

If this isn't a bug (PEBKAC is always an option for me) or can't be
fixed, I will just use fltk or gtk2 and I'll be fine. If you'd like me
to try out more things, let me know.


Cheers,
: ]

#930062#48
Date:
2019-07-12 12:17:12 UTC
From:
To:
this sounds very frustrating, i'm sorry to hear it.

I just ran the following test that uses an empty GnuPG homedir:

    GNUPGHOME=$(mktemp -d)
    cat > "$GNUPGHOME/gpg-agent.conf" <<EOF
    pinentry-program $(which pinentry-qt)
    log-file $GNUPGHOME/gpg-agent.log
    debug 1024
    debug-pinentry
    EOF
    export GNUPGHOME
    gpg-connect-agent 'GET_CONFIRMATION Hello' /bye

And it works for me -- i get a graphical QT popup window.

Could you try out the test above?  Once you run it, if it gives you an
error, could you look at $GNUPGHOME/gpg-agent.log ?

#930062#53
Date:
2020-05-29 09:09:07 UTC
From:
To:
Hi,

I'm in a similar situation as the original reporter; I want to use my
password manager to enter my GPG passphrase but pinentry-gnome3 is fully
modal, so I installed pinentry-qt but it doesn't appear to work. I'm using
Ubuntu 20.04 (yes I know this is a Debian bug report, but I hope this might
help get this issue fixed).

I tried the test and I see this in my terminal:

gpg-connect-agent: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established
ERR 67108949 No pinentry <GPG Agent>

Content of gpg-agent.log:

2020-05-29 16:20:23 gpg-agent[1772766] listening on socket
'/run/user/1000/gnupg/d.xsj3tnu6mn6647naay7ouamr/S.gpg-agent'
2020-05-29 16:20:23 gpg-agent[1772766] listening on socket
'/run/user/1000/gnupg/d.xsj3tnu6mn6647naay7ouamr/S.gpg-agent.extra'
2020-05-29 16:20:23 gpg-agent[1772766] listening on socket
'/run/user/1000/gnupg/d.xsj3tnu6mn6647naay7ouamr/S.gpg-agent.browser'
2020-05-29 16:20:23 gpg-agent[1772766] listening on socket
'/run/user/1000/gnupg/d.xsj3tnu6mn6647naay7ouamr/S.gpg-agent.ssh'
2020-05-29 16:20:23 gpg-agent[1772767] gpg-agent (GnuPG) 2.2.19 started
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK Pleased to meet
you, process 1772764
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- RESET
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- OPTION
ttyname=/dev/pts/14
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- OPTION
ttytype=xterm-256color
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- OPTION display=:0
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- OPTION
xauthority=/run/user/1000/gdm/Xauthority
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- OPTION
putenv=XMODIFIERS=@im=ibus
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- OPTION
putenv=GTK_IM_MODULE=ibus
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- OPTION
putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- OPTION
putenv=QT_IM_MODULE=ibus
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- OPTION
lc-ctype=en_CA.UTF-8
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- OPTION
lc-messages=en_CA.UTF-8
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> OK
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- GET_CONFIRMATION
Hello
2020-05-29 16:20:23 gpg-agent[1772767] starting a new PIN Entry
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_11 <- [eof]
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_11 -> BYE
2020-05-29 16:20:23 gpg-agent[1772767] can't connect to the PIN entry
module '/usr/bin/pinentry-qt': End of file
2020-05-29 16:20:23 gpg-agent[1772767] DBG: error calling pinentry: No
pinentry <GPG Agent>
2020-05-29 16:20:23 gpg-agent[1772767] command 'GET_CONFIRMATION' failed:
No pinentry
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 -> ERR 67108949 No
pinentry <GPG Agent>
2020-05-29 16:20:23 gpg-agent[1772767] DBG: chan_10 <- [eof]

(I should add that I tried this test in a VM using the Debian 10.4.0 live
iso but I wasn't able to reproduce the error. I suspect if I tried this in
a Debian install instead of a live iso session I would get a similar
result.)

When I try this with the default (systemd-managed) gpg-agent, I see this in
my system log:

May 29 16:38:50 computer gpg-agent[1794812]: Unable to init server: Could
not connect: Connection refused
May 29 16:38:50 computer pinentry[1794812]: cannot open display:

There is a similar bug report for Ubuntu[1], where the last comment[2]
suggests a workaround by adding keep-display to gpg-agent.conf. Connecting
this with the above system log messages, I tried adding keep-display and it
appears to work.

(Someone else had posted to Ask Ubuntu[3] about what looks like a similar
issue. While the poster wasn't sure what the exact fix was, keep-display is
among the options for gpg-agent.)

Hope this helps,
Jeff

[1]: https://bugs.launchpad.net/ubuntu/+source/pinentry/+bug/1509699
[2]:
https://bugs.launchpad.net/ubuntu/+source/pinentry/+bug/1509699/comments/5
[3]:
https://askubuntu.com/questions/127213/files-e-mail-not-signed-with-kleopatra-kmail-gpg-agent