If you run into build problems on OpenBSD for gpg-wks-server, see T4886 for a required minor fix.

No info received; either really malware downloaded from a fraudster site without proper checking on bare coincidence with other updates.

@sarman: Your question is actually a support question and not a bug report. Please read the documentation, use the public help channels (so that other can also learn from the issue), or get in touch with a commercial support provider.

From where did you downloaded it? Did it show a valid issuer for the software (Intevation GmbH)?

After disabling the CRL check again in gpgsm.conf

OCSP can't be the default because it enables a web bug. The responder immediately sees when a signature is verified or a data is encrypted to a certificate.

That option does the same as --disable-dirmngr which in trun has the same effect as disable-crl-checks; see gnupg/sm/server.c#option_handler. If you want to check the validity of the cert you check the TRUST status lines. This is what gpgme does for you. An example is gpgme.tests/gpgsm/t-verify. You can run the tests also manually, I do this as follows:

I can see no bug here. See my comment over at T4881.

Fixed.

Arggh, this code is a whole mess (e.g. it uses its own logging code). I spent the last week to rework large parts of it for master. I am going to look into this case now.

If you want OCSP you need to enable it. CRLs or OCSP are a MUST under the profile we developed gpgsm. This is why --disable-crl-checks by default is not possible. There are lot of interesting things you will come across if you start to use S/MIME. For example you also need to care about the algorithms used for intermediate certificates used to sign CRLs - they need to comply to the policy as well. Or the rarely used PSS padding we encounter sometimes and which is not supported and will probably not be supported

Okay. Thanks.

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.

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.

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 requires re-evaluation of Libgcrypt to match the current FIPS specs.

Well, I misread the output. What you see is what is expected. From the gpgconf man page:

We don't consider this a security problem because the tool you used is a debug helper which we use during development (if at all). All real code needs to verify that it does not request a division by zero. The div-by-zero checks we added 8 years agot to other code paths (e.g. mpi_pow, rC2c54c4da19d3a79e9f749740828026dd41f0521a) are failstop measurements which should never be triggered.

You are providing invaldid data to this debug helper tools and run into a div-by-zero. I will add the usual test earlier in the code path so that a fatal error is triggered. Thanks for the report.