There is a new --keyserver-option update-before-send which is enabled by default.

tested with Gpg4win-5.0.0-beta357 (GnuPG 2.5.11):

Note that 2.5.11 fixes a regression in 2.5.10 regarding the use of notations for 3rd party signatures. See T7743

The card returned these 32 bytes:

1883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286

agent_card_pkdecrypt however returned 33 bytes:

411883ba0d1cacda6f357ad9caa062ebd7b3a07291a7788565caf38973bf414286

Thus the indicator byte is 0x41. The specs (librepgp, rfc4880bis) say:

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.