I*m sorry, but I haven't found a way to determine what version of gnupg I am running. Just in case things got confused, I am not the thread opener, my version of gnupg is not whats been stated in the opening post but rather whatever is current on Arch Linux: Linux 6.0.11-arch1-1
I ran gpgsm --version though which returns this:
gpgsm (GnuPG) 2.2.40

Please update to a recent gnupg versions. 2.3.3 or if you really need the LTS version use 2.2.40. Instead of using a log you can import on the command line:

After years of using S/MIME I ran into a strange situation importing my new S/MIME certs to Kleopatra yesterday which ultimately led me to this thread.
My case is slightly different because my original passwords were short (2w7g9r1e and 2y8m7i5t), but it feels related so I thought I'd share nevertheless.

I also reproduced this bug. I am using a PIV configured YubiKey 5C NFC for GNOME Smartcard login, which uses pam_pkcs11, and pam_pkcs11 uses opensc to read it via pcscd.

I've hit that issu on downloading two times so I think that there are two nodes behind LB :P

Just checked those two commits and I see in autoconf output:

checking for gpg-error-config... no
checking for gpgrt-config... /usr/bin/gpgrt-config
configure: Use gpgrt-config with /usr/lib64 as gpg-error-config
checking for GPG Error - version >= 1.36... yes (1.46-unknown)
configure: Use gpgrt-config as libassuan-config
checking for LIBASSUAN - version >= 2.4.2... yes (2.5.5-unknown)
checking LIBASSUAN API version... okay

So looks like there is more use of *-config scripts and those detections takes longer time so it would be good to move that as well to pkgconfig.

External projects should have been using pkgconfig since a long time. The *-config scripts are for systems which lack pkgconfig.

I cannot find the commit which fixes this issue.

Thank you for your report.
Please look T6204.
Closed as duplicate.

Thanks !

A real fix will be in the next gpgrt release

Support for multiple smart cards has been vastly improved in the last few years. I will tentatively close this as resolved because it's very likely that the problems have been resolved.

Wild guess: Since creating a local certification seems to work, but creating an exportable certification fails, maybe the problem occurs when trying to promote an existing local certification to an exportable certification.

This has been fixed some time ago when the UI for generating OpenPGP keys was rewritten.

In T2671#158357, @werner wrote:

It seems that editing a pre-created revocation certificate on Windows with Notepad doesn't let Kleopatra detect this correctly as OpenPGP file and thus refuses to import. Works on the command line but needs more testing.

Thanks for reporting. We usually test by moving the <keygrip>.key files around ;-)

works

Actually we should switch from putenv to SetEnvironmentVariable et al. because that avoids problems wit different Windows libc versions, for example in DLLs.

Fixed in rG8e8971403f75: w32: Fix gnupg_unsetenv..

Sure, but this will need adaption in FIPS mode as it fails with:

Patch using SHA1 instead of MD5.

There are other uses of MD5 and thus we can't disable it. For example gpgsm also lists the MD5 fingerprint of certificates because they are still in use at some places.

Well, the modern way, recommended by the FSFE, for license notices in source files is SPDX instead of verbose license notices. https://reuse.software/

In T6285#165459, @gniibe wrote:

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Modern way for license notice seems use of URL: https://www.gnu.org/prep/maintain/maintain.html#License-Notices-for-Code
https://www.gnu.org/licenses/gpl-howto.html

works

This is now ready for testing.

You are using the basic pinnentry which comes as part of the basic installer. Almost everyone does not use this but Gpg4win which has a real pinentry. See http://gpg4win.org You don;t need the program statement then because gpg is installed in the PATH.

Sorry, it looks like no problem.

Thank you for the bug report and your suggestion.

To test this you need a key with a subkey (including the primary key) that is marked for signing and authentication, but not for encryption. Open the Subkey dialog, insert an OpenPGP smart card, right-click this subkey and select Transfer to card. Select the Authentication slot when you are asked which card slot the key should be written to.

Here is the patch which will go into the next release

From f61a5ea4e0f6a80fd4b28ef0174bee77793cf070 Mon Sep 17 00:00:00 2001
From: Werner Koch <wk@gnupg.org>
Date: Tue, 22 Nov 2022 16:36:46 +0100
Subject: [PATCH] Fix an integer overflow in the CRL signature parser.

thank you, works for me.

Thank you, looks good to me.

Please use gpgme.pc to configure your build. Your options are:
(1) With Autoconf:
(1-1) Use pkg.m4 and PKG_CHECK_MODULES (which uses pkg-config to access gpgme.pc)
(1-2) Use gpgme.m4 and AM_PATH_GPGME (which uses gpgrt-config to access gpgme.pc)
(2) Or... use pkg-config to access gpgme.pc.

In T6282#165263, @werner wrote:

It turned out that the reason for the problem is the use of the --ignore-cert-with-oid option in gpgsm.conf.

It turned out that the reason for the problem is the use of the --ignore-cert-with-oid option in gpgsm.conf.

great hack

I updated gpgme.m4 to include configuration of GPGRT_CONFIG.
Using this new gpgme.m4, it should work.
Using this new gpgme.m4 plus old gpg-error.m4, checking GPGRT_CONFIG is duplicated.
Using this new gpgme.m4 plus new gpg-error.me, no problem.

I overlooked the use case of gpgme programming not using libgpg-error. This use case should be supported.