Control: reassign 930062 pinentry-gnome3 Control: retitle 930062 pinentry-gnome3 grabs keyboard and mouse input despite --no-global-grab or 'OPTION no-grab' Control: forwarded 930062 https://dev.gnupg.org/T4587
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…
On Thu 2019-06-06 12:44:30 +0200, Emmanuel Revah wrote:
> I opened Thunderbird and selected an encrypted message. Or, I opened
> Thunderbird and the first message on the list is encrypted.
[…]
> A dialog window pops up and asks me to enter my gpg passphrase, and
> takes over the desktop.
[…]
> 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
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.
--dkg
signature.asc
Description: PGP signature
