pinentry-qt hangs when pressing Menu key then Esc

[Marcus Brinkmann]

At Wed, 15 Jun 2005 22:22:36 +0200,
Ingo Klöcker <kloecker at kde.org> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; iso-8859-1 (quoted-printable)>]
> On Wednesday 15 June 2005 20:02, Peter Eisentraut wrote:
> > A Debian user reported (bug #303508) the following, which I can
> > confirm:
> >
> > To reproduce this bug, you must have a keyboard with a Menu key (or
> > some other key, I suppose) that is mapped to open a context menu.  I
> > believe this is the default mapping for this key, if you have it. 
> > (On my keyboard, the Menu key is between the right Logo key and the
> > right Ctrl key.)
> >
> > 1. from a terminal, run pinentry-qt
> > 2. type getpin<Enter>  (a pin entry dialog box should appear)
> > 3. in the dialog box, press the Menu key  (a context menu should
> > appear) 4. press Esc
> >
> > At this point, the dialog box will dissappear, but no response will
> > be returned to the terminal.  (If you omit step 3, you will get the
> > response "ERR 111 canceled", which is what we want.)

Oh, well.

> This problem is very likely due to pinentry-qt grabbing the keyboard (in 
> order to prevent what exactly?).

pinentries like to grab keyboard and mouse to prevent you from
accidentially typing your PIN or passphrase into a terminal window or
your IRC input line :)

If you don't like it, there is a --no-grab option.  pinentry doesn't
parse any config files, but the option is passed through by gpg-agent
if you put it into .gnupg/gpg-agent.conf, I think.

This would also be a work around for the menu key problem, I'd guess.

> I had to add some hacks to KMail to 
> prevent it from decrypting a message when a context menu was shown 
> because otherwise X would hang and the only way to fix it is to kill 
> pinentry-qt by remotely logging in. Obviously the context menu and 
> pinentry-qt both tried to grab the keyboard and deadlocked or whatever.

Can we disable this conflicting grab in pinentry-qt somehow?

Mmh.

Marcus