Before making subtickets for each application: I wonder if it is not all Kleopatra anyway? Isn't the security approval dialog basically Kleopatra?

The equivalent for invalid S/MIME certificates are not-certified *PGP certificates.
(Valid/invalid are not ideal as technical terms as they have a broad general meaning, too. I hope my usage here is correct ;-) It is what I gathered from an explanation given by Werner.)

Invalid certs (as stated in the status column in Kleopatra) are mainly S/MIME certs (e.g. with missing root cert, CRL check failed, etc). I haven't seen invalid pgp certs yet (might be e.g. very old ones with missing self signature).

Invalid and expired are different cases.

Pushed: rG8b6de59ad880: agent: Raise GPG_ERR_BAD_SECKEY when p >= q for RSA key.

Pushed the change: rG533bcc265e9c: common:dotlock: Clean up for error/info/warning message.

While I pushed the change of libgcrypt, I'd like to apply following change to GnuPG.
This is more kind than GPG_ERR_BAD_PASSPHRASE by gcry_pk_testkey failure.

I retract my patch in T8171#215603

@m.eik gave us this link: https://github.com/ProtonMail/go-crypto/issues/184

It had already fixed in: rG55b5928099ba: dirmngr: Change the default keyserver.
And then in: rGa2f2523b99ff: Remove the default keyserver.

Setting to low because this has never been a problem in the last 30 or 35 years. A check to help pinpointing bad keys is however a good idea.

I sent a patch to gcrypt-devel mailing list for the preparation of the change of RSA secret key checking.
If enabled, wrong RSA secret key (wrong means: under the Libre/OpenPGP specification) is rejected at import when gpg-agent calls gcry_pk_test_key.

BTW, LibrePGP also demands p < q in "Algorithm-Specific Part for RSA Keys".

For OpenSSH, ssh-agent spec. defines p, q, and qInv.
FIPS has: FIPS 186-5 and SP 800-56Br2.

existing standards

CRT is used with GnuPG. In libgcrypt, pk_sign and pk_decrypt don't require P, Q, and U in a key (it's optional), but pk_test_key does.

Du we have any information on whether the CRT is used and whether u et al. is also wrong? For example due to an OpenSSL generated key?

I don't understand how to reproduce this. When a key is deleted then nothing referencing this key should remain in the key ring. I don't see why it should matter whether the deleted key was a card key or not.

Also applied to 2.4 branch.

Libraries have been fixed (as well as GnuPG itself), so, closing.

Cool. Works for me now.

rG62b8bf2f introduced the regression. The intent of the fix was about comparison of -----END , which has nine characters.
But it also added afx->buffer_pos ==1, that affected.

Using --enarmor and removing the checksum I sometimes get

AFAICS all conditions are protected by isascii(3) which

Current state in gpg4win-5.0.0:

It seems this broke the self tests (and gpgme, and notmuch) on NetBSD: https://dev.gnupg.org/T8065

This is a security update

@werner I added an implementation https://dev.gnupg.org/D622
that matches Linux behavior and avoids the message about secure memory not being supported on Windows. The change is scoped to the pinentry tool and intentionally follows Linux behavior. Does this approach look reasonable to you?

I think "O" is a better key:

We need to change the accelerator. Right now gpg-agent uses

I don't think that we will implement that any time soon. Today we too often require more mlock-able memory than available and in this case Libgcrypt resorts to allocating new memory arenas which are not locked. This is not as worse as one might think: the majro advantage with secmem is that a free() on secmem allocated memory will also wipe that memory. A better solution has always been to use an encrypted swap/paging file. 25 years ago, it was not easy to configure but today there should be no problem and hopefully already the default.

While key generation works now with an expiry date up to 2106-02-04, the representation on the command line is a bit ugly.

On 2026-01-20, I found the message to security@gnupg.org of:
Message-ID: 4e708880-04ac-45bc-8d16-6b585f2652a1n@aisle.com
in may spam folder. It has a 10MB long attachment. That might be one of reasons to be identified as a spam.

Considering the current implementation (tpm2d doesn't support keyinfo like scdaemon), it would be good to check the buffer size.
(If key information is accessible easily, we can check with a specific key.)

Looks good to me on gpg4win-5.0.0 @ win11. Tested with 20 starts of each combination:

• with / without keyboxd
• quitting kleopatra / killing all processes

I think this has been resolved in Gpg4win 5.

Will be in the next release.

it does not make sense to have a workboard item for this parent ticket.

Looks good to me on gpg4win-5.0.0-beta479 @ win11:

This does not happen any more, tested with Gpg4win-5.0.0-beta479