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.

Notification when trying to enter empty passphrase:

I propose the following patch to inform the user about the obsolete --secret-keyring option. The same is done for many other obsolete options.

Thank you! But let me mention, that my older smart cards (Version 2,2) holding also RSA-4096 keys. They could be generated on card without any problem. I had the problem only with OpenPGP cards version 3,4. This I would like to strenghten.

Thank you for the information.

My setting is RSA-4096 key. Also it showed "pipe was broken", but it disappeared too quickly, so I do not have a screenshot from that.

I checked with my OpenPGP card v3.4.
It works for me with GnuPG 2.2.x and 2.3.x.
My setting is for RSA-2048 key.

This is very saddening and alarming from a respected member of the community whose opinion matters.

Hmm, do we need a backport?

Please try 3.1.16 and make sure that you don't have other variants of gpg4win installed or Outlook plugins also using parts of gpg4win or its libraries.

You should have read the release notes of 2.1 (first point). We can't keep a bug open because you had a wrong understanding of GnuPG properties. Sorry.

Hi, I have the same problem, in Italian Language becouse this is the system language!
Kleopatra 3.1.16 on Windows 10

bug has been closed as Wontfix [..] I see no reason to continue the discussion in the bugtracker.

Can confirm this problem still exists in version 3.1.16. The context menu in Windows Explorer and some menu entries in Kleopatra are in the wrong language, while most of the application is in the correct language. This looks very messy.
Gpg4win and Kleopatra should not look at the date/format locale settings for the language, but at the actual Windows display language.

This bug has been closed as Wontfix more than a year ago. I see no reason to continue the discussion in the bugtracker.

Well, the keys are not generated but public keys are imported. @gniibe's key has meanwhile expired but we keep it because it will allow users to verify some older source packages. An expired signature key is not an error but merely means that one should evaluate the meaning of the signature with more diligence.