In T7656#201519, @TobiasFella wrote:

Do I understand correctly that this bug is then automatically done/fixed?

I do not think that this is the only place where such an issue occurs. Maybe we should make the documentation clearer about context key reuse. But the context is specifically designed to cache information about a key, so as to avoid memory overhead. I learned early on that its best for each new operation to use a new context. A context is basically an instance of gpg or gpgsm. So you start one process, ask it for a keylist, keep the process running, start another process, modify the key database, and then ask the first process again about his worldview. Either the first process is a bit confused because it has read data and then that data changed (what happens here) or it has no idea about the change since it was efficient and only read the database once. But here in this example you should be able to reproduce this also by making any other modifications to the key, adding other subkeys, userids etc. That GPGME even notices the secret key is more of a side effect of how the programming works because the GPGME gpg process will ask the gpg-agent (so a third process).

The more I think of this, the more likely this appears to me as the source for all that random startup weirdness of GnuPG. Say you are on a large keyring and on a train, then that keyring is first passed through your enterprise malware protection for scanning or something like that. Then it works again until some metric, hash or something else changes.

My recommendation would at this point be to use procmon with a file filter for just "If path contains gnupg then include" I mean maybe go only for the locking dirs but this way you will not only see what the GnuPG processes are doing but what everyone on the system is doing to the locks. So you will see when my old friends, third party security software might interfere.
For example: You will see on a default Windows which files are checked through telemetry. And here in this example you see directly that the Microsoft Malware Protection Engine is accessing the agents socket.

Yes. If gpgconf could read that version directly from kleopatra it would be even better. Bit in cases of early crashes this might be sub-optimal; thus I will tell gpgconf to get some additional version info from an installed versioninfo.txt file (which gpg4win creates). Thanks.

@gnibee Thanks! I noticed this too but wasn't familiar with the test suite, and didn't see an ASAN error so assumed nothing harmful. This explanation explains it.

Is this what you had in mind @werner:

Note: The Kleopatra in upcoming versions of Gpg4win 5 will have AboutData::version set to gpg4win-5.0.0 (or gpg4win-5.0.0-beta190 for beta versions). See T7666: Kleopatra: Rework versioning.

Please remember to add a comment to the code describing the reason for this renaming.

The issue is the routines of regcomp, regexec, regerror and regfree are in C library and the sanitizer library replaces them (and it's not compatible for the use case of GnuPG).

Thanks, that was the only issue building there.

Note: The Kleopatra in upcoming versions of Gpg4win 5 will have AboutData::version set to gpg4win-5.0.0 (or gpg4win-5.0.0-beta190 for beta versions). See T7666: Kleopatra: Rework versioning.

Tools / Refresh OpenPGP certificates runs gpg --refresh-keys. I don't think that this command knows anything about WKD.

For vsd on Windows this will be solved due to the use of gnupg-vsd as default homedir. We already tested this with a beta MSI installer

This should compare the gpg4win version number:

I updated the github issue. The suggested change seems to have had no effect.

If you are experience problems with the test suite on NetBSD, please see T7634

Thank you @alexk

I made a comment on github.

Please re-open if you find other Cygwin related build problems.

You know that Cygwin is not supported but if that is the only place it should not arm to fix it.

Another possible change will be use of KEM interface for gpgsm.
Not high priority, but for long term code maintenance.

Thanks for the quick fix. I feel a bit silly for not notcing that macro myself...

Fixed in all branches but there is no potential for exploiting. See also gnupg-devel@ ML.

This should do the trick (master) but have not yet tested it:

Fixed. Thanks for the report!

The classic NIST P521 pitfall ;-)