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.

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.

The change rG60963d98cfd8: gpg: Detect already compressed data also when using a pipe. for T6332 introduce IOBUF_IOCTL_PEEK.

Implemented in rA9110945ce625: Implement timeout in assuan_sock_connect_byname..

Actually, it's not 'connect' system call, but 'CONNECT' request which matters. The use of SOCKS in libassuan is that it always connects to SOCKS server at localhost.
So, other than the special case of erroneous configuration of TOR, introducing timeout handling to the initial connection to the SOCKS server makes less sense.

The root cause might be that the "DEVINFO --watch" command causes ...

I see the point of use of int.
For backward compatibility, the semantics of 0 should remain as default timeout (let kernel decide == 120 sec, usually), -1 would be meaning immediately (only success when local).

Thank you for your report. Good catch.

The fix is in 2.4.1.
It's not perfect fix, but it catches the problem when it's not encrypted secret key.

assuan_sock_connect_byname may be extended to change the third argument (now int reserved) to unsigned int timeout.
It's a kind of API change, but ABI wise, the impact is minimum.

I learned that Unix build environment needs Wine emulation (with winepath) for MinGW host (when uninstalled executable should run correctly).
https://www.gnu.org/software/libtool/manual/html_node/File-name-conversion.html

Fixed for libgcrypt, updating copyright notices and license files.

@ikloecker Thanks for your comment. I put a comment in the commit.

So, here are fixes. I'll apply soonish.

Sorry, the comment above is my misunderstanding.

For importing key/subkey case, it doesn't matter if the smartcard is connected or not. The data in the file will be overwritten by import.

I understand the issue that you don't see an important message of the error.
Possibly, for this particular case, it would be changed to tty_printf instead.