I wonder if it is an encoding problem.

There is no encoding at all for passphrase - GnUPG uses whatever the user types.
Thus if the passphrase was originally entered on a Latin-1 TTY and later a GUI
with UTF-8 input is used, you run into problems.

We can't cange that because that breaks existing passphrases. For new
installations it should not be a problem becuase modern systems are all UTF-8
(modulo Windows)

if there is a behavioral change regarding the encoding a difference between qt4
and qt5 this would be a bug. Both convert the input to UTF-8, I think GTK does
too. I've just tested it and it worked.

So they should be the same. Can you provide an example test case by starting
pinentry from the command line and using "getpin"?

So, found it why trying what you asked me for.

It has to do with Input Method. GTK3 is working because it’s the only toolkit
that properly recognize all the dead keys on my setup (some of the characters I
use are only available through dead keys). QT4 was working because of this line
in my .xprofile:

export QT4_IM_MODULE=xim

Replacing QT4 with GTK makes pinentry-gtk-2 work too. However, this seems not
supported by QT5 (the correct var is QT_IM_MODULE), because xim seems to be
obsolete so they don’t support it. But some of my dead keys are not working, so
this is most likely a bug on QT/KDE side…

And since I run a QT5 terminal, -curses and -tty don’t work.

So, I think this can be closed, and that it’s time to open/search a bug
regarding this on QT/KDE side.

Actually there is something more.

While using pinentry-gtk-2 in a terminal does work, it still fails in
Thunderbird/Enigmail (passphrase not recognized).

And pinentry-gnome3, that works in the terminal too, doesn’t work in
Thunderbird/Enigmail as stated before (it fails just like if set to pinentry-tty
or pinentry-curses).

So, regarding Qt, the issue has been acknowledged
(https://bugreports.qt.io/browse/QTBUG-56452). Using IBus as suggested in
https://bugreports.qt.io/browse/QTBUG-49438, I know have dead keys working
properly in most apps. But…

Previously, the situation was as following:

— pinentry-qt4 was working everywhere.
– pinentry-qt was not working properly for me because I wasn’t able to input
some characters.
– pinentry-gnome3 wasn’t showing up in Thunderbird/Enigmail, but worked OK in a
terminal (GETPIN).
– pinentry-gtk-2 was working properly in a terminal (GETPIN), but not in
Thunderbird/Enigmail (deciphering failed, with the right passphrase obviously).

And now:

– pinentry-qt4 doesn’t exist anymore.
– pinentry-qt is as pinentry-gtk-2 was before: works OK in a terminal (GETPIN),
but not in Thunderbird (fails to decipher). Sighs…
– pinentry-gnome3 does show up in Thunderbird/Enigmail, and works correctly. I’m
currently using this one, even if that’s not totally satisfying.
– pinentry-gtk-2 doesn’t take my dead keys into account anymore.

For the last one, honestly I don’t care, gtk2 is being phased out, and it’s
probably not an issue on pinentry side.

However, the fact pinentry-qt doesn’t work correctly in Thunderbird/Enigmail is
strange. Do you think this is an issue with pinentry-qt or these programs?

Little update with latest 1.0.0 release:

– nothing new regarding pinentry-gnome3, still working nicely;
– nothing new regarding pinentry-gtk-2, but I know why it doesn’t take into
account my dead keys anymore and it’s not an issue on pinentry side;
– thanks to the new “show passphrase” button, I’ve been able to figure where the
issue lies with pinentry-qt: while invoked in the terminal, it does take into
account my dead keys, but while invoked via Thunderbird/Enigmail, it does not
(altought pinentry-gnome3 does).

So I suppose this is in fact an issue with Enigmail… Any hints on what they
could be doing wrong so that I can report this to them?