This ticket is explicitly about Kleopatra included in Gpg4win.

In T8059#212270, @bernhard wrote:

Kleopatra is also run on GNU/Linux Distributions.

Kleopatra is also run on GNU/Linux Distributions.

This is a security update

Option works in Gpg4win-5.0.1 with GnuPG 2.5.17

works in Gpg4win 5.0.1 with GnuPG 2.5.17

Gpg4win 5.0.0 (2026-01-14)

To reproduce the hang, a loop will suffice (usually happens within the first 15 times, once it needed 50 runs):

This is still open. It cannot be tested because Gpg4win still doesn't use KIO::move on Windows (because the above patch has not yet been merged).

There's no other configuration, this happens with a clean gnupghome with one smime cert + root cert and the above gpgsm.conf (output on stdin/stderr):

I think this is still open (and requires T6537: Make KIO::move work on Windows when moving between different partitions).

This is not yet fixed. KDE still applies a patch to gpgmepp (and gpgmeqt) to ifdef a few GCCisms.

@werner I added an implementation https://dev.gnupg.org/D622
that matches Linux behavior and avoids the message about secure memory not being supported on Windows. The change is scoped to the pinentry tool and intentionally follows Linux behavior. Does this approach look reasonable to you?

Reconsidering this all I don't think it makes any sense to distinguish between (-1) and GPG_ERR_INV_PACKET. We use (-1) for a too short read of the hashed or unhashed area (premature eof). INV_PACKET is for unknown versions, too much data (arbitrary limit), bad parameters, and underflow. Let's forget my previous comment and always use INV_PACKET.

I think "O" is a better key:

We need to change the accelerator. Right now gpg-agent uses

I don't think that we will implement that any time soon. Today we too often require more mlock-able memory than available and in this case Libgcrypt resorts to allocating new memory arenas which are not locked. This is not as worse as one might think: the majro advantage with secmem is that a free() on secmem allocated memory will also wipe that memory. A better solution has always been to use an encrypted swap/paging file. 25 years ago, it was not easy to configure but today there should be no problem and hopefully already the default.

Please run with --debug 0 which should show you which confiration files are read in which order. Is there anything in a common.conf file? A log-file statement tehre would overwrite the command line option.

While key generation works now with an expiry date up to 2106-02-04, the representation on the command line is a bit ugly.

Current state needs to be tested