Thanks for the patch, applied!
You are correct the NEWS file states that this was added in 1.9.0

Taking a look at other GNU manuals, both GNU make and GNU Bison have a better phrasing,
so I suggest the Bison way (https://www.gnu.org/software/bison/manual/html_node/index.html):

This manual (7 December 2019) is for GNU Bison (version 3.5), the GNU parser generator.

Ah, okay, then the phrasing is missleading, the sentence looks like libgcrypt was released on this date and not the manual.

Nope, that is correct, the last update of the manual was

@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.

In T4883#133467, @werner wrote:

That option does the same as --disable-dirmngr which in trun has the same effect as disable-crl-checks

@werner wrote:

Sample how GpgOL handles this: https://dev.gnupg.org/source/gpgol/browse/master/src/keycache.cpp;6f5f48c3d60e0af52f1a9f0e51f60ee653eeeb31$269

I think what you're saying that there is *no way* to use GPGME in offline mode to validate x.509 certificates, and this is by design. Am I understanding that right?

After disabling the CRL check again in gpgsm.conf

I see no difference between the last two example stanzas that show you running ../run-verify. Are they supposed to have different output?

I'm aware of the metadata leakage risks of OCSP, and i share your concerns about them.

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.

If CRLs or OCSP are a MUST in a given profile, and the cert chain has OCSP but no CRL, it seems like that profile should then try OCSP, rather than failing.

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 think what you're saying that there is *no way* to use GPGME in offline mode to validate x.509 certificates, and this is by design. Am I understanding that right?

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

It is a feature not a bug. For symmetric encryption the gpg-agent remembers the passphrase used for the encryption and thus for some time or until /gpgconf --reload gpg-agent/ it tries that passphrase for decryption.

This seems to be closely related to T4319 and due to to some, ahem, interesting configuration.

I see. Thanks for your explanation.

I see. Thus the problem is that IPWorksOpenPGP does not create proper OpenPGP private keys. I guess they use OpenSSL with their different CRT parameter style and do not convert them correctly. RFC-4880 says this in 5.5.3:

The secret key is this series of multiprecision integers:
o  MPI of RSA secret exponent d;
o  MPI of RSA secret prime value p;
o  MPI of RSA secret prime value q (p < q);
o  MPI of u, the multiplicative inverse of p, mod q.

FYI, pEp annoyance was addressed and handled here: https://bugs.debian.org/891882
By this patch: https://sources.debian.org/src/enigmail/2:2.0.11+ds1-1/debian/patches/0002-Avoid-auto-download-of-pEpEngine-Closes-891882.patch/

Thank you for your response.

For GnuPG, the error is: you don't have run-able libntbtls.so in your environment (because of your wrong configuration, perhaps) but you have it to link.
For GPGME, the error is: your linked libgpg-error.so.0 and the one which runs are different (because of your wrong configuration, perhaps).

You need to update the public key and convey it to the sender. This will solve the problems. You should also ask the sender to update their software so that an MDC is always used regardless of the flag.

I can't see any bug here so I will close this bug now.

Hi Werner,

Please use one of the mailing lists to solve your problem. 2.3 is a development version, so I wonder from where you got this version of GnuPG.

Thank you very much for the analysis. I'll forward the info.

The creating software is broken in regard to non-ASCII characters in the UID:

ssh does nut support brainpool curves and thus GnuPG does not know how to map its internal name of the curve to the name as specified by ssh. GnuPG supports these curves:

So the output of this was

Thanks @werner I will do tonight when connecting to my team mates PC.
Btw meanwhile I actually felt like I need to open next issue where I explain all my details

Your home is under /dev/ - really? Please run

Okay I think I got the root of the issue

When I did

brew reinstall gpg2

I saw this today

In T2203#88661, @nuimk wrote:

/usr/local/bin/gpg-agent -v --daemon

I'm closing this issues as "Invalid" because it is not an issue of Gpg4win. You can still comment and discuss here.

First let me say that it is never a good Idea to use outdated / unmaintained security software. PGP Messages are external input and you pass that to unmaintained software.

Fair enough. Let's wait and see what others think.

Also consider that it is possible to change the key usage flags. Thus it will never be clear whether one has a fixed or unfixed public key. I'd like to close this bug because it is currently also discussed in the IETF WG.