Here is a patch.

diff --git a/agent/divert-scd.c b/agent/divert-scd.c
index 1e5de4671..bb42dd3b4 100644
--- a/agent/divert-scd.c
+++ b/agent/divert-scd.c
@@ -517,6 +517,9 @@ agent_card_ecc_kem (ctrl_t ctrl, const unsigned char *ecc_ct,

Several releases since the last commit and no specific bug reports. We can close this task.

Should be fixed with 2.5.9. Given that secp256 is an esoteric curve for GnuPG it does not make sense to run the entire QA process.

Can't you just use file descriptors everywhere and use _get_osfhandle once you need a HANDLE. That is what I am used to seeing in Windows code in Gnulib (although I do not touch it much).

Regarding 64bit handles https://learn.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication
tells us:

This seems to be a good opportunity to replace paperkey with a new tool to take advantage of the smaller ECC keys which allow us to re-generate most stuff.

secp256k1 is an --expert option and not supported by other *PGP
implementations. We should actually hide this thing even more and not
even display it with --expert. Thus do no expect an immediate 2.5.9
release to fix this issue.

secp256k1 failure:
https://lists.gnupg.org/pipermail/gnupg-users/2025-June/067731.html

After several gpg4win-5 betas be can set this task to resolved.

I claim this resolved given several gpg4win-5 betas.

I claim this resolved given that we had several gpg4win-5 betas and no reported problems was related to this.

Reminder mostly to self: This is about the KDF parameters. In the light of PQC composite algorithms we may want to also prepare for PQC required stuff.

There should be a workaround by using

This was release with 2.5.7.

Funny old bug which shows up only if you don't have any keyserver configured. Note the FIXME in the commit ;-)

I stumbled into this problems myself yesterday. Time for a new release.

Once again, thank you for your reactivity @gniibe !

My test coverage was not good (even if I daily use Curve25519 on Gnuk Token).
Your analysis is correct.

We do this now also for gpg-wks-server. Further gpg-wks-client now sends the current language to the server so that the server can get back to the user with a proper translated text (if configured).

Alright. We use utf-8 in our template files and switch to QP encoding when needed.

Another possible change will be use of KEM interface for gpgsm.
Not high priority, but for long term code maintenance.

Done by T7649: gnupg: Use KEM interface for encryption/decryption

@werner I think these changes caused an ASAN failure that I reported in T7664. I think it would be good to get that sorted before a release.

Clean up finished by rG681d75404300: gpg,agent: Clean up around using ECC KEM.
Tested by make check and decrypting tests/openpgp/samplemsgs/pqc-sample-*.enc.asc.

FYI: I'd like to get a new release out after these changes.

Pushed all changes needed. Actually, agent side too.
Clean up will be done.

Meanwhile we have some support for an empty subject but gpgsm still prints an error notice. See the T7171 for more.

(2) Update the documentation of default-cache-ttl zero value disabling caching.

I think we have another report on this in the tracker. The problem is indeed the ugly Windows time functions to print a string. Let me only remind that until a few years, Windows had the opinion that Germany uses the Westeuropäische Zeit like Portugal or the UK.

I am going to do:
(1) Recover old behavior with max-cache-ttl = 0
(2) Update the documentation of default-cache-ttl zero value disabling caching.

I can't see any documentation that a value of 0 disables the cache. The user might have used some undefined behaviour. For example in the old code we did a housecleaning when we were idle but the new code uses a timer and another thread for flushing the cache. We could open a feature request to entire disable the cache but I bet that we will get a lot of new bug reports because users will then need to enter their passphrase too often for one operation.

It's not my intention. I didn't know the feature of disabling caching by max-cache-ttl to 0.
Well, it's a regression if a user intends so.

Lucas Mülling commented yesterday on gnupg-devel:

A brief update: This feature has not made it onto the roadmap of specific things to implement so far.

BTW, fingerprints for X.509 are not well defined because you get a different one when changing the *unsigned" attributes. Not a common case but one should be aware of it.

Done

Re-opening because I think rGaa36f6ae8bae needs to be backported to GnuPG 2.4 (see T7568). The fix for T7309 which introduced the regression has been backported to GnuPG 2.4.

I've offered https://github.com/bestpractical/gnupg-interface/pull/16 to GnuPG::Interface, and am testing it out in debian unstable.

I'll work on making a patch to offer a flexible test suite.