A quick check with passing ASSUAN_PIPE_CONNECT_DETACHED does not changed anything.

I wonder whether rA3bccb33ccd9028ff505d9979fd6c8a37393b892d which changes Assuan's waitpid function for Windows is well aligned with the my_waitpid in gpgme's assuan-support.c (which does nothing). gpgme creates a detached process in most cases but for gpgsm assuan_pipe_connect is used without the ASSUAN_PIPE_CONNECT_DETACHED flag.

Another data point is that the faulty versions use libassuan 3 with a slightly changed API. May one of the follwing chnages cause the problem?

Someone should test whether gpgol2 is able to reencrypt all subfolders of a given folder. The file reencrypt tool (current name "recipients" "hugh") does this already.

Thanks for testing.

That look s like a problems with logging to stderr in --server mode. On Windows fds 0,1,2 are special.

The advantage of using a fingerprint for referencing a key is that there won't be any collisions in the keyid. Further this unifies the schema with an LDS (Windows) installation where DNs must anyway be unique. But take care the client needs to support this new flag. This will be the case for gnupg >= 2.5.12 (cf. T7756)

1.11.2 has been release see T7642

Release done.

Test on Windows by overwriting gpgtar from gpg4win-5.0.0-beta357 and also tested on Linux. Debian packages with patches are already available.

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

But we emit a failure at the end of the gpg process; aren't we?

This might be related to the recent changes in now we spawn processes. Using gpgtar [...] --status-fd=3 3>a.log shows something different than directly using --status-fd=2. Do we handle the process termination correctly; i.e. wait for all status-fd output?

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

Urgs

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:

Noteworthy changes in version 1.3.2 (2025-07-28)

Fixed for gnupg22 and gnupg26