This is inconsistent, as usually a separate window would pop up for pinentry errors.

as this really bugs me, I raise the prio.
And add the Kleo tag, as Werner said it might be that Kleopatra is responsible.

With VS-Desktop-3.1.90.258-Beta I ran again into the last issue with "Wrong PIN". I had not realized that I had entered the PIN wrong before (as you have to enter the PIN several times anyway when generating a new key on a card and you do not get an error message on wrong PIN but instead only a new pinentry window...).

Please excuse my question but this issue has been WIP for 8 months. I think it was forgotten a bit. Especially since we are not shipping Okular for general signing of PDF documents this issue might help as a stopgap for Smartcards which we do not yet support natively and reduce the pressure a bit to add more PKCS#15 smartcards which can currently be used with Adobe and Mozilla NSS through their proprietary PKCS#11 modules. So I would like to raise the priority for this a bit. But I don't think high is appropriate. That would be for werner to decide.

Funny error description from macOS. Looks that there is no device - your PC/SC test programs confirms this. Thus I don't think this is a bug in scdaemon.

I am wondering a bit about the gpg: DBG: chan_3 <- ERR 100696144 Operation not supported by device <SCD> which is not the string I expected for this error:

Changing debug options unfortunately didn't change much.

Eva and me tested this using our 2.2.42 release candidate on Linux and
on Windows and were not able to replicate your problem.

Eva can you please try to reproduce this? I can't really imagine that this is true since we have soooo many users with yubikeys and do a lot of internal testing on them. To be fair please try with your standard devuan GnuPG and not just with an up to date version.

Dear Werner, have you had any toughts about this ?

If it were the case, I think that graceful shutdown of the system would need to terminate the client of scdaemon at first.

The root cause might be that the "DEVINFO --watch" command causes ...

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: