I thought i'd try with other certificates. I started with the one from this website. It also fails to validate unless i supply --disable-crl-checks, apparently because the immediate issuer (the Let's Encrypt CA) doesn't offer CRLs, only OCSP responders. Perhaps --disable-crl-checks should be the default, or at least if there is no CRL available there shouldn't be a failure by default:

Aha, i can get it to say f if i use --disable-crl-checks:

i didn't know that, thanks. i'm now seeing i (which i think means "invalid") in the same configuration:

Add --with-validation to check the validity of a certificate in a listing.

Backported to 2.2

Okay, in 2.2 the output now looks like this:

This is closely related to T3465 which was fixed in master. Running a gpg-agent 2.3 agent and using gpg 2.2 it works; however, using a gpg 2.3 bails out with an error message that we are in batch mode. I will look at this.

Won't happen for 2.2

Given that we may move to yet another format in 2.3 I now doubt that we should add such a feature to 2.2.

@gniibe: I am not sure we really continued by mail - do you have any updates on the status?

Sorry, I have not yet followed you test plan but given that we have the patch in master for a long time now I think it is okay to port it to 2.2.

Thanks. I applied your patch to 2.2 and master. I had to do a minor fix because the function does not return anything. Also extended on master with another patch for v5 keys.

The newlines are not percent escaped because that could lead to very long lines and thus break parsers. Another reason is that the error messages are easier to read this way. An empty first field is anyway not valid and parsers should skip that.

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