Actually, calling do_touch_file when some error(s) are not good.
Let me fix all the things.

I hope last amendment is the following, which can happen if the tty can be opened only for reading but not for writing:

--- a/tty/pinentry-tty.c
+++ b/tty/pinentry-tty.c
@@ -583,7 +583,8 @@ tty_cmd_handler (pinentry_t pinentry)
   if (pinentry->ttyname)
     {
       fclose (ttyfi);
-      fclose (ttyfo);
+      if (ttyfo)
+        fclose (ttyfo);
     }

Done for gpa.
Please test.

Done for pinentry.

Thank you for applying the provided changes!

Applied and pushed.

Thank you. I'll take care of this.

Seems that it is not a coincidence that Wayland starts with a W like Windows. ;-)

pinentry-timeout is indeed used when it is not set to 0.

In my opinion this is also a problem. Especially if you think about it for a while. The one minute timeout is too short and pinentry-timeout which I would expect here to be the config value to adjust this is not used.

As suggested in the linked question on stackexchange, I think that even if the error comes from the pinentry program, GnuPG could echo a more informative error than gpg: decryption failed: No secret key, such as terminal to little to show the pinetnry program, or something similar.

Thanks for the report. Frankly the curses pinentries are not that widely tested.

Well, it's a (hard) requirement unless you explicitly disable efl, i.e. ./configure (without --disable-efl) fails with an error if elementary or ecore-x is not found.

I don't think the patch made elementary and ecore-x dev headers an absolute hard requirement; in particular, ./configure --disable-efl works fine to build pinentry without having these headers installed.

The following patch makes the efl requirements optional unless pinentry-efl is explicitly enabled:

diff --git a/configure.ac b/configure.ac
index bc67c14..ce170c9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -423,7 +423,24 @@ AC_ARG_ENABLE(pinentry-efl,
             pinentry_efl=$enableval, pinentry_efl=maybe)

rP19a18ba5fee0 makes elementary and ecore-x hard requirements for pinentry. I don't think that's intended.

Thanks for the verification, @wltjr. I've pushed 19a18ba5fee049aac87b5114763095aaeb42430f to the master branch for future releases.

Btw, ecore-x was also needed, so that should remain. Just to be clear, the final version should be

PKG_CHECK_MODULES(EFL,[elementary >= 1.18,ecore-x])

Give or take the >= vs >.

@dkg it was the 2nd one, the EFL vs efl. That worked fine after uppercasing it! The >= may not be necessary, but might as well. I am on a much newer EFL, 1.25.1, so not really able to test that part of it. I should be running one of the latest autotools,

[ebuild   R    ] sys-devel/automake-1.16.3-r1:1.16::gentoo  USE="-test" 0 KiB
[ebuild   R    ] sys-devel/autoconf-2.69-r5:2.69::gentoo  USE="-emacs" 1,438 KiB
[ebuild   R    ] sys-devel/libtool-2.4.6-r6:2::gentoo  USE="-vanilla" 951 KiB

hm, actually, maybe the efl should be EFL in order to produce and substitute the EFL_CFLAGS and EFL_LIBS variables.

@wltjr maybe it needs ecore-x as well as elementary > 1.18 in the PKG_CHECK_MODULES line? oh, and looks like i screwed up and used > where i should have used >= sorry! fixing those would make the PKG_CHECK_MODULES line be:

Looks like its missing an include

x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..  -pthread -I/usr/include/libsecret-1 -I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/lib64/libffi/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include    -I/usr/include/ncursesw -I../secmem -I../pinentry -Wall  -O2 -pipe -march=amdfam10 -mcx16 -msahf -mabm -mlzcnt -Wall -Wno-pointer-sign -Wpointer-arith -c -o pinentry-efl.o pinentry-efl.c
pinentry-efl.c:32:10: fatal error: Elementary.h: No such file or directory
   32 | #include <Elementary.h>
      |          ^~~~~~~~~~~~~~
compilation terminated.

@dkg for sure, I will test out the patch ASAP. Thanks for the ping.

fwiw, i think a patch like this ought to work with reasonably-modern versions of autotools:

@wltjr maybe you could take a look at this?

Thanks @aheinecke for fixing my fix with 2859edd! Closing here.

Modified and commited with: rev. 2859eddfb0c935d3f9eb9ccc1b42c121621123e9 I'm not sure if phabricator automatically does it when I mention the differential as GnuPG-Bug-Id

Thanks for noticing, I did not have Qt4 on my radar when writing this. The delayed raise with the timer might be only necessary on windows, on linux we don't have reports that just doing an activateWindow and raise does not work. So this is mostly for windows and there the Qt4 pinentry is not relevant.

• Please see T5262 if you want to build with Qt4.

There’s a patch to restore support for Qt4: D521.

My bad, prior to the release I tested only against Qt5.

Looking at the backlog of pinentry-related issues, I don’t think that would warrant delaying further the release of pinentry-1.1.1, especially given that the last release was 3 years ago already. Remaining issues (most of them being stalled anyway) or feature requests can be postponed for a future pinentry-1.2.0.

The fix will be part of the upcoming pinentry-1.1.1.

@gniibe I assume this issue has been fixed by the same fix as for T4585 and can be closed as well. Feel free to re-open if I am wrong.

No disagreement after more than a year, I think it’s fair to say that either everybody is fine with that feature being only present in the -qt, -tqt, -gtk, and -curses pinentries, or that nobody cares. :) Closing now, will be part of the upcoming pinentry-1.1.1.

Will be fixed with 3.1.14

There are two problems that might be mixed in here:
What I noticed sometimes is that pinentry-qt properly becomes the ForegroundWindow but the input focus is not set on the line, even though an active cursor is shown in the line.
This might be a pinentry-qt specific issue and I look into that.

I am always glad to fix such bugs before a release (I am about to prepare 2.2.22).

I am always glad to fix such bugs before a release (I am about to prepare 2.2.22).

It worked! You were right!

Thank you for your prompt help. It's much appreciated.

rG4c8d5eb0bdd3: agent: Allow TERM="".

I see. Thank you @werner . For clarity could you please link the patch that was not backported to 2.2.?

Mails crossed ;-)

But @werner what's the value $TERM *supposed* to have? When gpg is invoked straight by Gnome? I can run the command sh -c 'env | grep TERM > ~/gnome-term.env' in Gnome's "Run Command: interface and then the file ~/gnome-term.env says TERM is set to nothing (It is set, but the contents is a "" string).

Ah wait. This has been fixed in master a year ago but was not backported to 2.2; see T4137. I'll add it to the forthcoming 2.2.22. Thanks for the report.

The warning above is harmless. Both strings are actually the same but stem from different versions of the autotools helper scripts

Unfortunately I've had some trouble compiling the latest git version of GnuPG for NixOS - I got this warning which turned out to be a blocker:

Without really looking at your report: May it be that this is because Pinentry does not get the WAYLAND_DISPLAY variable as reported in T5016? This will be fixed in 2.2.22 which I hope to release this week.

I take some of my words back - using or not using MOZ_ENABLE_WAYLAND=1 doesn't make a difference eventually - If Firefox is launched by Gnome and not gnome-terminal, pinentry fails to launch with and without MOZ_ENABLE_WAYLAND.

To explain the use case, I've started coming up with a good passphrase and this took a bit of time with a pencil and paper in front of me. When I wanted to type it in, it was too late. Thus I guess that some people will look up good rules of passphrases or at least make sure they can remember the one they are typing in.

5 or 10 minutes are not reasonable in this case. Users are expected to attend the key generation. Your idea of having a countdown after, say 30 seconds, makes sense and should be easy to implement in the pinentries.

@aheinecke thanks for commenting.

I can reproduce this.

I keep it open as testing so that we keep it in mind for a release.

There was a patch for this by david faure which added an
#undef ttytype after including curses.h

I debugged some more.

It is the pinentry-curses, which is needed to reproduce the problem.
Using tab and Return to navigate the dialog.
After pressing ok, the password question dialog reappears. I tried 20 times to press ok, every time the password question dialog reappeared.
If I press cancel, the process aborts. So I'm sure, I hit the right button.

And yes: If I install pinentry-gtk2 and follow the steps, it works as excepted.

Perhaps I explain the steps, I'm doing.
I'm on a minimal debian buster instance.

1. gpg2 --full-gen-key
2. Insert stuff.
3. See Dialog:

Real name: Test1 Tester
Email address: test1@example.com
Comment: no pw
You selected this USER-ID:

"Test1 Tester (no pw) <test1@example.com>"

Ok. Renamed ist "ttytype_l" (l for local) and found the button to upload a file.
Hope it helps.

Using a double underscore in a symbol should be avoided because such symbols are reserved for system use.
(To include a diff inline, please intend it by two spaces so that it is not not considered as marked up text.)

I just tried and Pinentry ask me whether I really want to use an unprotected key. Take care that you hit the right button.

Yeah, this can be done.