Thank you all for the help. I thought this was a bug with pinentry itself but appears to be dbus related based on the above command.

To set DISPLAY, dbus-update-activation-environment is your friend.

FYI, for me, on a machine with Debian GNU/Linux, I use Sway, it works fine with pinentry-gnome3.

I have installed the Gnome keyring prompter and there seems to be a problem using the Wayland display

Apr 27 17:33:09 mbagnara-pc org.gnome.keyring.SystemPrompter[1952]: Unable to init server: Could not connect: Connection refused
Apr 27 17:33:09 mbagnara-pc gcr-prompter[1952]: cannot open display:

Please install the Gnome Key Ring prompter tool or use the plain GTK pinentry.

Fixed in rP7f7fd8bcfd74: tty: Fix error return paths and its resource leaks.

Actually, calling do_tuch_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.