This has been changed by listing the other Add-Ins only if debugging is actually enabled.

This string comes from the Windows API and thus it is a Windows bug. It maye take some decades until this get fixed but at least they have meanwhile sfxed the "Westeuropäische Zeit" zu the correct "Mitteleuropäische Zeit" - Modulo Umlaut problems.

Let us mark this as a feature requests. gepwnam(3) is a standard libc function and if glibc does not support it; this is more likely a glibc bug than a bug in an application.

Do you remember wether you had the same problem also with 2.5.14 or 2.5.16? Or can you test with these versions? Which version of libgpg-error are you using?

My actual plan is to rework the imp[ort/export of secret keys to gpg-agent. Right now gpg-agent has knowledge of OpenPGP for import/export. This is not good and the required conversion should be moved to a helper tools for easier testing and to have this out of the gpg-agent process. For Kyber we right now don't use any conversion mut store the secret keys in gpg-agent's native format. Thus the passphrase is not necessary. We need to figure out why we have this problem here.

This is a security update

Gpg4win 5.0.0 (2026-01-14)

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.

We should keep in mind that we set an arbitrary limit for the [un]hashed areas. They are actually allowed to be larger. At some point in the future we might want to lift that limit again or add another algorithm. We need to take care that we don't drop the signature packet but merely don't use it. The packet needs to be storable in our keyring even if we cannot parse it now correctly. This is different from a broken packet, which is better dropped.

I definitely prefer 0004. I am not so sure on the use of -1 as return code. I know that we use it for legacy reasons but it does not feel correct. Maybe add an arg int *skipme to the function so that we can selectively skip this packet. Note that I have not fully evaluated the patch; the -1 might just be right.