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.

There are two code paths to generate key: gpgsm_genkey and gpgsm_gencertreq_tty. Latter is partially supported with card key.
Firstly, I'm going to work for T4888.

I think that what you want is adding --batch option. In the gpg manual, we have:

--passphrase-file file
       Read  the passphrase from file file. Only the first line will be
       read from  file  file.  This  can  only  be  used  if  only  one
       passphrase is supplied. Obviously, a passphrase stored in a file
       is of questionable security if other users can read  this  file.
       Don't use this option if you can avoid it.

Hello Team,

This should work well with libksba master and gnupg/sm master.

The commits in 2019 (for libksba and gnupg/sm) handles the problem (of key generation using card).

For operations which require private key, it is needed to unlock private key.

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

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:

The return value that was mapped to invalid value was "SW_WRONG_LENGTH" so I tested using the codepath for the SW_EXACT_LENGTH sw return value, too and it worked for readcert.

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?

Done in master

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?

Thanks for the quick fix, @werner!

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

Fixed.

Hello,
Sorry for the late reply but with your help we found a bug in our code and it has been fixed. Thanks for your assistance!

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.

You forwarded me an email, which said it went well.

Created https://dev.gnupg.org/source/gnupg/history/gniibe%252Fscd-watch/