In T5551#148510, @werner wrote:

I would prefer to see a fix/hack in pinentry-qt instead.

I see. Thanks!

To minimize the risk of regressions.

Not to be bothersome, but why? DISPLAY seems like the universal method of selecting a display to put things on, where a lot of applications don't support --display or equivalent, especially now there's no equivalent for wayland. It's especially confusing to me when the keep-display option will pass DISPLAY instead of --display. This would also prevent other such scenarios with 3rd party qt/gtk plugins or alternative pinentry implementations.

I would prefer to see a fix/hack in pinentry-qt instead.

Proposed patch:

--- gnupg-2.2.27.orig/agent/call-pinentry.c
+++ gnupg-2.2.27/agent/call-pinentry.c
@@ -202,13 +202,14 @@

Here is the documentation of the new way of single-threaded execution:
https://www.gnu.org/software/libc/manual/html_node/Single_002dThreaded.html

We also need to update m4/threadlib.m4.
Now, it's maintained in gnulib.
See the changes in:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=12b5b00f93c6433c3df8176fc9674d7600f8b268

AllowSetForegroundWindow did not work but the code from pinentry works even without the minimize / raise. The minimize raise is only required for the proper input focus and a nice animation for pinentry but the QWindowsWindowBehavior is already sufficient.

I am pretty sure that an AllowSetForegroundWindow in the kuniqueservice_win implementation in Kleopatra will alleviate this issue. Since we pass a double click on a file which has foreground window permissions to the existing process which at this point may not have foreground window permissions. If this still does not help we can do the minimize / maximize trick.

Ingo, I have tested this on Windows with NV Access and was able to symmetrically encrypt and decrypt a file with closed eyes. I went through the windows explorer context menu to select sign & encrypt on selected files.
Can you also do some more tests on Linux ( I do not know how to properly enable a screenreader there ) and if you find anything ugly fix it.

As far as I understood, $WAYLAND_DISPLAY does not need to be set because there is a well-defined default, but I guess most of the time it's set anyway.

Ah, I understand the point (at least, partially); My understanding is: With FIPS mode, at the module boundary (== libgcrypt), it ensures that all cipher/digest/etc. operations are done under the standard compliance, and it is considered wrong (violation) when non-FIPS mode operation (such as SHA-1) and FIPS mode operation are mixed.

QGuiApplication checks $XDG_SESSION_TYPE maybe to find out whether to use X11 or Wayland if $DISPLAY and $WAYLAND_DISPLAY are both set.

The fix in gpgme fixes the progress when encrypting/decrypting large files with Kleopatra. At least, on Linux.

In RHEL, we do not have anything about PCT so the PCT requirement is not completely clear to me: https://git.centos.org/rpms/libgcrypt/blob/c8s/f/SOURCES

Cool

I tried a fresh card reconfigured it to use 3 4k RSA keys:

Okay, the problem with run-encrypt (and maybe also Kleopatra if it also uses gpgme_data_... and sets a size hint) is that gpgme_data_seek casts the result of seek(..., 0, SEEK_END) which is of type gpgme_off_t to int to accommodate as tracing macro/function:

return TRACE_SYSRES ((int)offset);

Changing this line to a simple

return offset;

fixes the progress reporting of run-encrypt.

Hmm, nope. gpg outputs

[GNUPG:] PROGRESS largefile5G ? 0 5120 MiB

if I run

$ gpg --symmetric --enable-progress-filter --status-fd 1 --output /dev/null largefile5G

I gave it a try and it works here now with $DISPLAY unset, thanks!

I have added some debug output to _gpgme_progress_status_handler. For the 5G file gpg seems to output

-&11 ? 0 1048576 KiB

for PROGRESS. So, the value of total is already wrong in gpg.

Ah, of course, the solution for T2368 does not work for archives. So Kleo would need to stat all files first to get an idea of the size of the tar archive to set a size hint.

See T2368

This can be easily reproduced with run-encrypt from gpgme/tests:

$ fallocate -l 1G largefile1G
$ fallocate -l 2G largefile2G
$ fallocate -l 3G largefile3G
$ fallocate -l 4G largefile4G
$ fallocate -l 5G largefile5G
$ ./run-encrypt --progress --loopback largefile1G >/dev/null
progress for '-&11' 0% (0 of 1048576)
progress for '-&11' 0% (64 of 1048576)
progress for '-&11' 6% (66816 of 1048576)
progress for '-&11' 16% (172928 of 1048576)
^C
$ ./run-encrypt --progress --loopback largefile2G >/dev/null
progress for '-&11' 0
progress for '-&11' 65536
progress for '-&11' 56896
progress for '-&11' 155776
progress for '-&11' 249344
^C
$ ./run-encrypt --progress --loopback largefile3G >/dev/null
progress for '-&11' 0
progress for '-&11' 65536
progress for '-&11' 105216
progress for '-&11' 212480
^C
$ ./run-encrypt --progress --loopback largefile4G >/dev/null
progress for '-&11' 0
progress for '-&11' 57856
progress for '-&11' 168768
^C
$ ./run-encrypt --progress --loopback largefile5G >/dev/null
progress for '-&11' 0% (0 of 1048576)
progress for '-&11' 0% (64 of 1048576)
progress for '-&11' 11% (115840 of 1048576)
^C

The progress callback of run-encrypt looks like this:

static void
progress_cb (void *opaque, const char *what, int type, int current, int total)
{
  (void)opaque;
  (void)type;

SUSE has patches and version 3235 of cavs_driver.pl, bud it seems that it doesn't support DSA with Q+HASHALGO yet.

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.