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.

I have not checked but I guess that the certificate is marked as ephemeal and kleopatra either lists ephemeral certificates or the ephemeral flag got removed to to a validation process,

I have this fix committed to my working directory:

We have no CVE yet. However, CVE is also a good tag for security bugs,

See the gnupg-devel mailing list for more discussions. Subject: libgcrypt P256 signature malleability via weak DER enforcement"

Windows7 has long reached end-of-life. Do not use it unless you have a fully air-gapped system. In this case, continue to use gpg4win 4.4.1 or resort to the command line of 5.0.0 which should still work.

Two historic integer encoding glitches from Peter Gutmann's style guide:

Am I right that for VSD we use:

Thanks Ingo. It seems 2.5.17 is not too far away.

So w/o the new option we have:

I updated the rendered form of the English GPH with a warning and a link to the blog.

Thanks for the hint.

Will be in the next release.

it does not make sense to have a workboard item for this parent ticket.

Independent of keyserver order in dirmngr.conf, --search-keys still offers keys from the upload server, but the download fails:

For "Although the upload server is used for upload, the gpg message still displays the first keyserver" see T8025

I am using that version and key daily. No problems seen.

I think we won't fix that for 2.2

That was also fixed in gnupg 2.2.50 and thus vsd 3.3.3

That was fixed with 2.2.52 which fixed a bug in the fix done in 2.2.50 (see rG31fef13df1). Note that 2.2.48 to 2.2.50 had only internal releases.

Given that the 2.2 fix has been tested and resolved and we don't have another ticket for 2.6, we can close this one.

Okay, let's backport this.