I also experienced hang on shutdown with GPG 2.4.1 and bisecting reveals that the first bad commit is rG2ccbcfec121f.

Closing. A small change in Kleopatra (T6472) should help to avoid using this hack in common cases.

The workaround works.

Not easy to fix because gpg --card-edit/-status has some support form other cards. Eventually these commands will be replaced by gpg-card. In the meantime we can use this hack:

The generate keys etc. actions in the keys part of the view are debatable. At least for VSD I think they should not be shown or greyed out for not VS-NfD compliant cards -> see T6786
(I think there were even algorithms offered for generation on card which would result in an error, but I won't investigate further at the moment.)

isn't T3456 the same issue?

works. tested with VSD 3.1.26 (gpg 2.2.41) and keyserver entry in dirmngr.conf only.

Closing this one - see T6378

There is actually a regression wit Yubikeys. The fix for 2.2 is in T5100: rG08cc34911470 - for 2.4 I need to check

The application probably doesn't support this curve, the changelog only mentions Curve25519 and NIST P-256. Also Kleopatra lists only these two curves when generating a key from the card. Upon further inspection, the 0xFA DO listing the supported algorithms only has RSA 2048, RSA 4096, nistp256, ed255519 and cv25519

This is a Nitrokey 3A with the firmware 1.2.2-alpha.20221130. I'll check with the vendor.

Sure that you specific card/implementation of Nitrokey supports this curve? The card application uses a vendor from the test card range - this it is likely that it is some Javacard implementaion or it is an old gnuk firmware on the nitrokey basic.

Changing the key attributes didn't help unfortunately:

There must be some regression in the code which changes the key attributes. Please try
"gpg --card-edit" admin, key-attr
and switch to nistp384.

I also tried to import the key with the gpg-card writekey command and I got the same error.

Same error message but probably a different cause, in this case the card was factory reset before importing.

I try experiment using Python PKCS#11 (https://python-pkcs11.readthedocs.io/en/latest/index.html)

• with SoftHSM https://github.com/opendnssec/SoftHSMv2
• with Scute

I concluded that (at first, for the initial try) it's not good to start this under scdaemon, because of two different abstractions for accessing the device (the way of scdaemon and the way of PKCS#11).
It's good to start with something like tpm2d. The goal would be integration into scdaemon or tpm2d.

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.

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.

We need to do this also for CHANGE REFERENCE DATA - however, there should be an extra option so that we can debug this despite of the redacting.

Will be released with 2.3.9

is there any news for gnupgp 4.0.4 release with gnupg 2.3.8?

In T5790#163980, @manonfgoo wrote:

@margirou:

Can you test the Patch, does it work for you ?

Kind regards,
Manon

In T5790#163886, @werner wrote:

[Merging didn't work]

Can you test the Patch, does it work for you ?

Here is the patch as file:

The patch applies with -p1 to the master brach, alternatively I could push a commit, but my user does not seam to be allowed to do so:

[Merging didn't work]

Attached you find a patch to this issue. This Patch sets the "keypair" attribute to the keys 0x82 to 0x95 unconditionaly.

In T6218#163787, @gouttegd wrote:

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

Yes. Scute relies on those to interact with the token.

Does the latest Scute require an instance of gpg-agent and/or scdaemon running to work?

That sounds quite cool.

Actually we developed PIV support to allow the use of PIV X.509 certificates and OpenPGP keys with Yubikeys. In fact, GnuPG is able to switch between the Yubikey PIV and OpenPGP applications on-the-fly while keeping their PIN verification states.

I was indeed using version 1.5.0 for testing, but I wish to clarify the purpose of Scute in my setup before proceeding.

Which version of Scute are you using?

Using Scute as a drop-in replacement doesn't currently work. Perhaps my config needs more adjustments than just:

module = /usr/lib/x86_64-linux-gnu/scute/scute.so

Yes, I meant to use Scute as pkcsc11 module for pam_pkcs11. Thanks for explaining more verbosely what I meant.

I think Werner may have confused pam_pkcs11 with gnupg-pkcs11-scd. :)

I'm not sure what you mean with using Scute as PKCS#11 provider instead of pam_pkcs11, as pam_pkcs11 is not a provider but a user of PKCS#11

There is a reason why pcsc-shared is not the default ;-). Please try using Scute (best the t6002 branch until it has been merged) as pkcs#11 provider instead of pam_pkcs11. And you should of course use the stable version of GnuPG and not the LTS (2.2).

Testing gpg-auth : There are two different use cases

• test with xsecurelock for screen lock
• test with pam-autoproto for login / gdm / etc.

Here are pam_authproto.c with Makefile, so that you can compile it with libpam:

Here is a PAM module, which interact a spawned process using authproto protocol of xsecurelock.