Should now work for pinentry-qt on Wayland even if DISPLAY is not set.

This has been fixed with rP9dd46926f8d5: qt: Fix showing of pinentry window on Wayland.

Notification when trying to enter empty passphrase:

@aheinecke Please test this on Windows

Huh, can't believe I somehow missed that this actually got a reply three years ago...

It's worth noting that this issue is particularly impactful for devices with small screens whose sizes cannot be changed. A Raspberry Pi with an Adafruit touchscreen would almost certainly have issues, for example.
This also applies to mobile devices. For context, I use Termux on my Android phone, and this issue manifests there. I can enter the passphrase for an existing key and decrypt/sign with it, but any attempt to create a new key throws me into the same loop that the OP describes. (Interestingly, this happens whether or not I actually supply a new passphrase.)
Since I am on a mobile device in this scenario, my terminal dimensions are 56x115. I'm not familiar with the implementation details of GPG, but is there any chance we could fall back to a single-line, sudo-style password prompt if pinentry fails (or have pinentry fall back to that internally if the normal mode fails)? That should work on terminals of just about any size.
(As an additional note, I've also tried flipping into landscape orientation, hoping that would increase my screen width sufficiently. However, my keyboard then occupies most of the screen, and I receive the expected error message, gpg: agent_genkey failed: Screen or window too small.)
EDIT: I'm running GPG 2.3.1 and pinentry 1.1.1.

Implemented for X11 and Windows.

For formatting there are four modes: Formatting forced off (the default)/force on/on/off. The latter two modes allow the user to change the option.

That might depend on your pinentry version. With a pre-1.1.1 pinentry and 2.2.28 I get this:

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

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