FWIW, We have a similar mechanism for the secure memory

That is a security feature of WIndows. We can't do much about it except for bad hacks. Checkout Kleopatra to see how you can improve this.

We talked today about the renaming the current "linux" entropy module to "oldlinux" would make sense.

Ok, I'll add.

@alexnadtoka, did you do what Werner wrote in T5639#150626?

Recently, I have encountered many problems in adapting the graphical interface interaction between Yubikey and gnupg. I am thinking about why some settings need to be manually added to some additional settings. I found that there are many such solutions on the Internet. Is there any way that scdaemon can automatically recognize these situations and add appropriate settings.

Things are not that easy. I actually introduced a bug in 2.3.4. Here is a comment from my working copy:

@werner Thank you for the answer. Please advise mailing list address.

For support please use the mailing list and not the bug tracker.

Seen. @jukivili can you please add it to the AUTHORS file?

GNUpg version 2.3.4 was installed but did not help

Is there a way to ignore SSL check during connection? This might work. We have internal server for our users only.

Guys I am facing similar issue but my Lets ecnrypt certificates are all ok. What is the problem with my gpg4win client? When connecting to openpgp server it says certificate is expired. Anybody can help me?

We can even remove the hexfingerrprint call. Will go into 2.3.4. Thanks.

It would be easier to educate gpgme about the 11.

So, this is the patch. Note that this is for master.

diff --git a/g10/keygen.c b/g10/keygen.c
index 7f15027a2..a452ab6d6 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -5619,7 +5619,7 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para,
           pk = find_kbnode (pub_root, PKT_PUBLIC_KEY)->pkt->pkt.public_key;

Actually, the "11" at the end of the "ERROR" status line means "bad passphrase". But I think gpgme ignores this status line.

Okay. gpgsm even logs "gpgsm: possibly bad passphrase given" internally.

Because, as a user, what do you do if you see "invalid object" you think that something is wrong with your data instead of trying to type the passphrase again.

As I understand it after the p12 decryption the output is just tried to be imported. With the wrong passphrase this is just garbage and can lead to different errors.

gpgsm 2.3.4 sends the result:

S ERROR import.parsep12 11
S IMPORT_RES 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ERR 50331713 Invalid object <GpgSM>

With Kleopatra 3.1.20.220370+git20211216T120053~68b4545e (22.03.70) using GnuPG 2.3.4-beta24 and Libgcrypt 1.9.4-beta152 I get the error message Invalid object when I import only berta-enc.p12 and enter a wrong password. I'll have to check with GnuPG 2.2.33.

I've uploaded my testcerts to: https://heinecke.or.at/div/testzertifikate.tar.gz.gpg

That KeyListJob returns keys which have fingerprint NULL is caused by keyservers returning just key IDs instead of fingerprints. The change for T5741: dirmngr does not ask keyservers for fingerprints should fix this. Still keyservers are only guaranteed to return key IDs, so we cannot assume that keys returned by KeyListJob have fingerprints.

The use of register_trusted_key in do_generate_keypair was a dirty hack utilizing a bug in --trusted-key ; it would be better to set the key as ultimately trusted.

I think that the change for T5685 introduced the issue.

Okay, sorry. In the first two cases (encryption), GnuPG 2.2.33 generates

[GNUPG:] INV_RECP 10 F3C987C36C5C6343C9A5D5A1A3F494F6028E4866
[GNUPG:] FAILURE encrypt 53
gpg: [stdin]: encryption failed: Unusable public key

and exits with error code 2, whereas 2.2.32 doesn't display these messages and exits with return code 0.

Please be so kind and describe the regressions you see. 3 log files from your software are not very helpful.

ikloecker: Please go ahead

IIRC, the problem is/was that this breaks some old keyservers. But there are no more old keyservers - if there are useful keyservers at all.

Thanks!
I will study it soon.

GnuPG needs to be fixed. Done by rGe08225030dfb: w32: Prepare for the case gcrypt.h will not include winsock2.h..