Mailing List Archive: pinentry-qt hangs when pressing Menu key then Esc

pinentry-qt hangs when pressing Menu key then Esc

Jun 15, 2005, 11:02 AM

Post #1 of 4 (3422 views)

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.)

This bug manifested itself to me as kmail hanging after I accidentally
mistyped my passphrase (by hitting the Menu key instead of Shift, which
is right above it) and then hitting Esc to get a fresh start. At this
point the context menu was showing, and it hung as described, and kmail
hung too because it was still waiting for a response.

(Note that if you get the context menu for the line edit using the right
mouse button instead of the Menu key, this bug does not appear.)

Also, other apps that use a line edit do not behave this way; for
example, to see the expected behaviour, do this:
1. run kdialog --inputbox test
2. follow steps 3-4 above

Re: pinentry-qt hangs when pressing Menu key then Esc [ In reply to ]

kloecker at kde

Jun 15, 2005, 1:22 PM

Post #2 of 4 (3309 views)

Permalink

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.)
>
> This bug manifested itself to me as kmail hanging after I
> accidentally mistyped my passphrase (by hitting the Menu key instead
> of Shift, which is right above it) and then hitting Esc to get a
> fresh start. At this point the context menu was showing, and it hung
> as described, and kmail hung too because it was still waiting for a
> response.
>
> (Note that if you get the context menu for the line edit using the
> right mouse button instead of the Menu key, this bug does not
> appear.)
>
> Also, other apps that use a line edit do not behave this way; for
> example, to see the expected behaviour, do this:
> 1. run kdialog --inputbox test
> 2. follow steps 3-4 above

This problem is very likely due to pinentry-qt grabbing the keyboard (in
order to prevent what exactly?). 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.

Regards,
Ingo

Re: pinentry-qt hangs when pressing Menu key then Esc [ In reply to ]

marcus.brinkmann at ruhr-uni-bochum

Jun 15, 2005, 5:18 PM

Post #3 of 4 (3348 views)

Permalink

At Wed, 15 Jun 2005 22:22:36 +0200,
Ingo Klöcker <kloecker@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

Re: pinentry-qt hangs when pressing Menu key then Esc [ In reply to ]

wk at gnupg

Jun 16, 2005, 1:40 AM

Post #4 of 4 (3311 views)

Permalink

On Thu, 16 Jun 2005 02:18:47 +0200, Marcus Brinkmann said:

> 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 :)

and to make it harder for other applications to snoop the PIN by
grabbing the keyboard. Only one application may grab it and thus the
hang is actually on purpose. This is the usual countermeasure on X to
avoid such attacks. In the dark old times of xhost it used to be
popular to read what co-workers typed on their keyboards.

Shalom-Salam,

Werner