#930062 pinentry-gnome3 grabs keyboard and mouse input despite --no-global-grab or 'OPTION no-grab' #930062
- 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:
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. :]
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.
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.
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,
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,
"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.
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, : ]
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 ?
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