I agree that the "future" won't come, ever. (for libgcrypt)

I found that for EdDSA other than pure Ed25519, it can supply context.
I changed the semantics and API for adding context and input data, as we need to support both simultaneously.

I changed the lg-input-data.diff patch not to break the ABI, reusing the published symbol of gcry_pk_random_override_new.
With this approach, if/when needed, backporting may be easier.
Drawback is debugging internal of libgcrypt will be a bit confusing.

Before adding FIPS support flag and tests, we need to modify implementation:

• Adding PCT check for EdDSA
• Adding support of gcry_pk_hash_sign/verify API for EdDSA

Thanks. I think that it was the oldest one: FSF used to be there in Cambridge, then moved to Tremont St. in Boston, and now it's in Franklin St.

To summarize, here is the situation:

• Ideally, it would be good to modify GnuPG and Emacs EasyPG to implement status handling and input handling in better way.

I'm going to add selftest of EdDSA with test vectors from RFC 8032.

With the fix of T6523, make check goes all well (on Wine emulation and on Windows, for i686 and for x86_64).

Fixed in master.

I modified ffi.c, to have renamed process-spawn-io function doing I/O by C.

Calling assuan_release before kbx_client_data_release is the best (and we join the thread).

tests/openpgp/import.scm hangs with 4096*4.

Test with Wine (i686) emulation, I encountered another hang at: Checking armored_key_8192

It looks like having the datastream_thread may be not worth.
One possibility is to implement synchronous read from pipe in kbx_client_data_wait, instead of datastream_thread.

The problem of hang of tests/openpgp/multisig.scm is solved by rGef4f22b9d98b: gpg: Graceful exit for signature checking with --batch.
But the problem itself is not yet solved.

It is reproducible by testing tests/openpgp/multisig.scm with keyboxd enabled (it hangs), with the modification of following.

Possibly, it may consider the case where errno==0 when failure.

Since it's ABI change, I created a branch: https://dev.gnupg.org/source/libassuan/history/gniibe%252Ft6487/

I conclude that adding two public functions for pipe connection of client will be useful (and solve the pid_t issue, by successfully hiding those use cases).

I pushed the change which keeps old status report behavior to master.
Let me test the change.

looks simpler to me.

Orthogonally, here is possible change for GnuPG, if we need to support the workaround of compress-level 0 in ~/.gnupg/gpg.conf.

OK, here is my changes which always use make-temp-file (to avoid confusion between data input and passphrase input).

I use epg.el with the change of removing the wait:

For (2-2), there are two use cases in GnuPG.
(A) In call-daemon.c (for SCD and TPM2D), wait_child_thread cares about daemon termination to clean up resources. In this case, it calls waitpid/WaitForSingleObject.
(B) In call-pinentry.c, watch_sock cares about dangling pinentry. When it detects client's EOF on the socket (between the client and gpg-agent), it kills pinentry process. In this case, it calls kill/TerminateProcess.

Finished the step to have cleaner semantics of the implementation by: rA6350f796fdd1: w32: Cleaner semantics for PID and Process handle.
Clarified the fact (1-1).
And as a bonus, when it's "cygwin" mode, peer (client) process ID is now available.

Pushed changes for those libraries.

On a terminal, please invoke:
$ gpg-connect-agent UPDATESTARTUPTTY /bye

My use case is using Wine, like this:

• having different bindir (/usr/local/i686-w64-mingw32 and /usr/local/x86_64-w64-mingw32)
• but I was too lazy to have different configurations for 32-bit and 64-bit, but to have shared configuration with
  • PATH adding both of /usr/local/i686-w64-mingw32 and /usr/local/x86_64-w64-mingw32

Pushed to GnuPG master. Let us test. For my machine of Debian GNU/Linux, Wine emulation (Windows 32-bit, Windows 64-bit), make check goes all well.
After confirming the implementation, I'd like to put it into gpgrt.