For the record, we've removed the SRV record for keys.gentoo.org for now, to work around the problem. Without the SRV record, everything works as expected.

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.

Should be fixed now; see commit above.

FWIW: WriteFile and write are more different than in using a HANDLE vs. a libc file descriptor. Despite that a HANDLE might be a 64 bit pointer, it is guaranteed that the value fits into a 32 bit variable. But they still index different objects. The return code and error values are also different.

Much simpler: write is only used in the callbacks and over there gpgme_io_writen[n] shall be used anyway.

Hmm, for the latter this:

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

Kleopatra test case (similar to gpg):

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:

At least the first part seems to be identical behavior to that described in T6488 for USB devices.

it's not hard to fix that header to actually provide a sensible write(), avoiding the issue listed on the mailing list, where there was no return to check:

Seems it gets a record but is not able to parse it (gnupg/dirmngr/dns-stuff.c:getsrv-standard) in your setup. Not sure why it loops - need to debug it.

Ok, it seems that my reproducer isn't correct after all. The user just confirmed that the SRV lookup succeeds on their system, so it seems GPG hits some loop repeating that for no apparent reason.

On the command line it works. It seem's to be a problem of Kleopatra.

Can you try on the command line, errors might be more specific there. This can be caused for example by a wrong system clock.

This is not really what the issue here is talking about. This issue was about "merging" multiple keyrings into a single view. If I understand you correctly you want to have matching pubrings and secret key directories for different applications. That is fully covered and what many users do by setting GNUPGHOME through the environment, the --homedir option or the windows registry.

Did anything get implemented to handle this? We have a central network file share where we store our public and secret key rings. We have several different applications that access these key rings. I'm trying to convert one of them from using gpg.exe via the command line with the --keyring and --secret-keyring paramters to using gpgme, but I don't see a way to specify the keyrings. Any help would be appreciated.

Absolutely, I'll prioritize looking at this.

Fixed in 2.4

Moved this on the workboard to have a better overview.

Before you ask: I can write on that device and it works with gpgtar on the commandline:

I see the problem: The Qt Pinentry does not implement the BUTTON_INFO status and thus we don't get a fully canceled error back (gpg-agent maps the cancel error to fully-cancel if the close button was used). Should be easy to fix in pinentry (set pinentry->close_button in the close eventhandler).

For me it works if I fully cancel (i.e. close the Window at the first prompt):

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.