I have updated the code and patch. It is ready for review, modification, and ideally inclusion

I have noticed some issues, minor code fixes, and a major issue with failing to fall back to tty/ncurses interface when a GUI is not available. I will make the changes, cleanup the code format, etc and re-attach patch.

The underscores on the Cancel and OK button come from Pinentry. Not sure if I am not handling Locale correctly, or something along those lines. The other stuff does not have it, and setting text the same way.

Sure thing, and it is "semi" animated. If you fail to enter a correct pin/passphrase. The error message is animated, it will slowly move back and forth from left to right. I can provide further screenshots of its various options, confirm, quality, double entry, etc. The quality bar changes color from red to green, with every shade in between based on quality, 0 red, 100 green, in between other colors/shades between the two.

For reference: D426: Initial patch for EFL based pinentry. Thanks for the explanations of the terminology in the E project!

I changed it back to EFL from Enlightenment. Enlightenment is a desktop/application coded using the EFL. Like Gnome is coded in GTK. This does not require Enlightenment at all. Just the EFL. Which can be used in GTK/Gnome, or KDE/QT based environments just the same. Also Tizen, etc. Thus I would not call it Enlightenment anywhere, as it really has no relation.

I created the requested differential. Please let me know what I need to do for inclusion. Thanks!

Ok I will do that soon as I am finished with refinements and it is ready for re-submission. Thanks!

@wltjr Please upload the patch here: https://dev.gnupg.org/differential/diff/create/ Thanks!

I got the patch from Mike. It does need some refinements. I will work on the modifications and re-submit. Do you accept PRs on Github? Or should I attach here? Or send to mailing list? Thanks!

I am interested in this, and can look into any needed polishing. Can someone please attach the patches to this bug or a link to where they can be downloaded. Unfortunately mailing list archives strip attachments. I spoke with Mike in IRC who informed me he made a EFL port of pinentry. I was working on that, and still have my code going in case I cannot get a copy of Mikes work. I am willing to do what ever is necessary to get this into pinentry sooner than later. Though I understand it can take some time. Hopefully not the 1yr it took the FLTK based pinentry to be added.

Merged in 6c45eed62214b44fcc11e642b19df7b6ca0da0bd.

Changed category to pinentry - this is a pinentry-gnome (ie. gcr) problem.

Testing this I noticed that the curses fallback did not work at all for Qt5
versions of pinentry-qt even if display was unset. This i fixed with cd7b35e

But the DISPLAY=:noexist case is more complicated. The GTK pinentry does a
gtk_init_check which Qt does not have. I don't want to mess with X directly and
would have to look into this more how to do this then only when X is used etc.

There is a similar question on stackoverflow and I don't find any answers there
acceptable:
http://stackoverflow.com/questions/28525435/qt-equivalent-to-gtk-init-check

I've changed the topic to reflect that this is a feature currently not available
in pinentry-qt but I don't see it as a high priority issue.

Andre, can you look at it?

So i'm left a little confused here about what the resolution is. neal added
documentation, but ueno suggested it was wrong and contributed a patch for it.
However, that patch hasn't been applied.

Some additional questions about pinentry-emacs and INSIDE_EMACS that came up in
discussion over on https://bugs.debian.org/854797:

    What's the best way to debug a problem when emacs pinentry
    isn't working?  do we look at gpg?  gpg-agent?  pinentry? emacs itself?
    all of those places?  What happens when the user has two separate
    instances of emacs running?  What if there's an instance of emacs
    running and someone uses tramp to connect to a remote ssh server, and
    gpg-agent is providing the ssh-agent interface?  What if someone uses
    ssh from *outside* of emacs and it talks to a gpg-agent that was
    auto-launched from within an emacs session?  What about when there's an
    instance of emacs running in a graphical session on a machine where the
    same user is also logged into the machine via ssh, and they're using a
    different graphical session?  how does pinentry-emacs interact with
    emacs --daemon and multiple emacsclient instances?

Another few questions:

Why does emacs use /tmp/emacs$UID for the ephemeral socket instead of

/run/user/$UID ?

If OPTION allow-pinentry-emacs is set, but the emacs process isn't

repsonsive (or nothing is listening at all) should pinentry do a second layer of
fallback, e.g. to curses?

anyone skilled in qt want to fix this outstanding issue?

Hi,

I can still see that qt[1] is using the simplified pkg macros[2], while the
configure.ac is using proprietary method[3].

We are still missing PKG_PROG_PKG_CONFIG macro in configure.ac to make pkg
macros happy, this can remove all AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
executions, see pinentry-0.9.5-build.patch, as you have PKG_CONFIG set.

The other changes to use PKG_CHECK_MODULES are optional but is there any reason
why not to use this macro instead of executing the pkg-config manually? This
macro has the advantage of allowing override via environment, and append proper
help.

If you like I can rebase this old patch set.

[1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=m4/qt.m4;hb=HEAD
[2]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=m4/pkg.m4;hb=HEAD
[3]
http:
//git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=configure.ac;hb=HEAD#l431

links removed as I got "Edit Error: not allowed (too many links).

Is that the gnome3 pinentry? if so please try the gtk-2 pinentry to see whether
it is the same problem.

Someone please check whether this is still the case and come up with a fix?

The Debian report is waiting since October for a reply from the orig. submitter.

justus: we recently talked about this. Would you like to work on this. I am in
particular interested to use it for Windows statically linked.

Fixed in 8e3aa3204e74e8d7a7538e0d0f04e555f140131b.

FTR: EFL == enlightenment foundation libraries. Calling this
"Enlightenment-based" is like calling the GTK pinentry "Metacity-based".

It does work, but contrary to my expectations it is rather unpolished. I'll
talk to Mike.

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?

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?

SETREPEAT is an optional feature - thus I changed this to a feature requests.

curses can't figure out the window size and thus it returns -1 for the size.
Pinentry's test for the required window size thus returns an error.

I have added new error codes to libgpg-error to either return
ERR 83886383 Screen or window too small <Pinentry>
or in our case:
ERR 83886383 Required environment variable not set <Pinentry>

That does not directly point to a problem with the TTY but it shows the cause
for the error (COLUMNS, LINES etc not set).

Can you please test if the following patch that has been committed recently

fixes your problem?

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commitdiff;h=2227f67af53f38d3d7f97760f2553d2c9ed05969

Cloning the git repository (commit id 2227f67af53f38d3d7f97760f2553d2c9ed05969)
followed by

autogen.sh
./configure --enable-maintainer-mode
make

works, i.e. the warning/error is not present any more.
So this patch seems to fix the issue.

The command line for gcc backs this observation (note the includes):

gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/ncursesw -I../pinentry -Wall -g
-O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k
-Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaratio
n-after-statement -Wno-pointer-sign -Wpointer-arith -MT pinentry-curses.o -MD
-MP -MF .deps/pinentry-curses.Tpo -c -o pinentry-curses.o pinentry-curses.c

Can you please test if the following patch that has been committed recently
fixes your problem?

https://git.gnupg.org/cgi-bin/gitweb.cgi?
p=pinentry.git;a=commitdiff;h=2227f67af53f38d3d7f97760f2553d2c9ed05969

(It is not NCURSES_INCLUDE, but NCURSES_CFLAGS should be set by
PKG_CHECK_MODULES.)

Thanks!

What operating system are you using?

I'm using Gentoo.

(referring to the discussion you linked):

pkg-config ncursesw --cflags returns "-I/usr/include/ncursesw", which is the
correct path. However, this include is not listed in the gcc command line (see
initial message).

I'm no expert in make nor autotools, but looking at pinentry/Makefile $COMPILE
uses $INCLUDES and $AM_CPPFLAGS. However $INCLUDES is not defined and
$AM_CPPFLAGS only adds -I../secmem. Also, nothing seems to use the variable
$NCURSES_INCLUDE (which is set to the pkg-config value "-I/usr/include/ncursesw").

This leads me to the wild guess that the pkg-config definitions for ncurses are
ignored by configure (or however sets up the Makefile). Instead the default
include directory /usr/include is used which has the wrong curses.h header. I
would like to submit a patch, but I sadly have no knowledge about make and automake.

Fixed in 2f1f1f06.

Grabbing the pointer might have unexpected repercussions though, e.g. one isn't
able to move windows around anymore. Let's see how it turns out.

What operating system are you using?

We had the exact same patch committed (21e83f42) and later reverted (f0db3192).
Discussion: https://lists.gnupg.org/pipermail/gnupg-devel/2015-June/030051.html

This is really weird. Merely not adding the password reveal button to the hbox
'fixes' this problem. Therefore, I don't believe that the patch introduces the
bug, it merely makes it manifest itself.

I looked around in the related gtk bits, but I believe the problem might be in
the X server, or the asynchronous interaction with it. I don't believe it is
worth digging further into X.

Workaround committed in ad390f29.

Ah, I misunderstood your problem. In the future, please paste all program interactions in one chunk
in the right order. We did merge some changes related to exporting of secret keys, so it may very
well be solved by that.

Thanks for caring :)