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.

I share your concerns about centralization of keyserver infrastructure. Rejecting this security fix doesn't help keep keyservers decentralized, though.

As a start, I applied your patches.

It is now over 10 months that the proponents of these additions have not followed up on the discussion.

Works for a long time now (unless we broke it again;-)

dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems.