I tried to replicate that with my ~3000 keys on master and I don't see any difference. Did you tried it several times? It might be due to the signature verification cache.

I checked the code and your patch looks right. I am going to apply it.

I am not able to replicate my own bug. At least since the introduction of --locate-external-keys the code paths are identical. I am nut sure why I filed this bug.

Related the changes, before we did the changes, we received two independent reports.

It is my confusion. The API is available. I only looked for symbols in the library.
It is #define-d macro to pthread_cond_*.

For Windows, it is available. I don't know the reason why it has not been available for POSIX.

It is easy to explain:

I think that this chnage is useful enough to be backported to 2.2. Done that.

You can test it now out using GnuPG master: Just add --include-key-block and you can then verify using an empty keyring. Currently --auto-key-retrieve is not needed but we need to think on how we can enable or disable this during verification.

I am not sure whether this is related but when using Libgcrypt master and verifying a signature created with an ed25519 key, I get the error below with valgrind. Both with 2.2. current and 2.3. It does not happen with the current Libgcrypt 1.8.

For reference, here's an error message from openssl smime when it is trying to verify an e-mail message with no embedded certificate at all (despite it knowing about the relevant certificate):

There are likely some bugs in the new code and I also want to do some improvements; see rGb4f1159a5bd7. But things should basically work as before and thus I set this again to testing

This is now implemented

Fixed in master.

A program like tests/t-mpi-point assumes gcry_mpi_print can do that.
We have a sort of regression with --debug option with t-mpi-point, the point q is not printed out correctly.

ftr, here is the thread I had in mind but couldn't recall above. @aheinecke is that your thinking, or a more pgp/mime bound mechanism as @dkg assumed?

"log" and "lock" are easy typo/confusions to make, @aheinecke was just trying to understand your report better, since there wasn't much information in it.

This requires re-evaluation of Libgcrypt to match the current FIPS specs.

@wiktor-k, "just extend the spec" doesn't necessarily work with existing clients, which might be surprised to find unexpected packets in the signature section of an e-mail. It seems more likely to me that they'd be able to handle (meaning: ignore) an unknown subpacket (as long as it's well-formed) than to handle additional packets. But all of these surmises require testing with existing clients, of course. Has anyone done any of that testing?