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.

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.

Just let me note that we used to have such an API : the former gcry_ac_ functions. However, it turned out that they were more complicated to use.

FWIW, we should anyway move on Widnows to the gpgrt provided setenv and getenv which are directly based on the W32API. The problem here is only that we have a lot of getenv in out code and need a wrapper. That wrapper would then also need to provide a static string as getenv does. A first step would be to wrap all getenv into gnupg-getenv calls.

Was resolved, see T4457

The warning is now removed immediately, when the input field becomes empty.

In T6473#170571, @ebo wrote:

In T6473#170380, @ebo wrote:

And when I set the validity to never expire (works) and afterwards set it to a date again, the date is now only set for the main key

Update: This is as designed, see https://dev.gnupg.org/T6473#170299 point one.

This bothers me a bit, as I find it confusing. Werner suggested for subkeys without explicit expiry date we could show in Kleopatra the expiry date of the main key in grey to make it visually obvious that a subkey will expire implicitly when the main key expires.

What do you think?

closing, as setting a password on a key without password works (at least in current gpg4win version). For improvement of the user guidance see T6436.

In T6473#170380, @ebo wrote:

And when I set the validity to never expire (works) and afterwards set it to a date again, the date is now only set for the main key

Update: This is as designed, see https://dev.gnupg.org/T6473#170299 point one.

Pushed changes for those libraries.

GnuPG is and can't be FIPS-140-3 compliant due to the way it is implemented. We may eventually employ the new hash-and-sign API of Libgcrypt to move into this direction but that has not yet been done. However, this also requires the use of the new indicator API and the, well, a RedHat kernel.

--openpgp means the current OpenPGP standard as implemented by GnuPG. This was important in the first few years of OpenPGP but not anymore today. The option --rfc4880 might be what you want. Please keep also in mind that the preference list declares what a concrete implementation supports and not necessary what's in an RFC.