Please continue on T7041. This ticket is going to be closed (as the problem described was fixed already).

Yes I have pcsc-shared in my scdaemon.conf.
I've just tried removing both pcsc-shared and disable-application piv and PIN caching worked as expected.

Are you using PC/SC shared mode? If so, it may be the case of T7041.

I just wanted to report that I'm having this issue on Fedora 39, with GnuPG version 2.4.4.
I'm being asked for the PIN for every operation (Sign, Decrypt, Authenticate) I'm having this issue on 2 different laptops using YubiKey 5C NFC and YubiKey 5C Nano (Firmware version: 5.4.3).
I tried disabling PIV (disable-application piv) and then PIN caching started working again, so I just wanted to report this as it's marked as resolved.

See also rG40b85d8e8cecadf35e51e84b30de4fac820d714b for gnupg 2.4.

We need to test the PIN, PUK and reset code stuff in 2.2

For the particular issue reopened for GnuPG 2.2.41 is fixed in GnuPG 2.2.42.
Please note that we can't fix the cause itself, the hardware problem.

It would be good to apply this to 2.2, so adding "backport" tag.

Thank you for the bug report. Although it's a corner case, it is a discrepancy in the implementation which results unrecoverable situation of the device.

Applied a patch from 2.4/master to 2.2 for SEGV when card gives bogus data. rG600e69b46149: scd:openpgp: Fix a segv for cards supporting unknown curves.

@desultory Thank you for your report.
Please open a new ticket for your problem. If you can, please show the result of https://dev.gnupg.org/T5963#157724

This is still an issue for me:

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

I never made a threat model. But definitely *any* cracker, should be out of my system, either from governmental agencies or from a kiddo in Russia.
I know that I have someone that is remote accessing my machine, since I got some tells. And that this cracker have used my Emacs text editor.

Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.

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 am very sure that this is resolved and we support that in Kleopatra.

In T6229#163870, @werner wrote:

The other key slots are claimed to be used for expired or archived keys as you rightfully mention. We need to figure out the real world semantic behind this before we can repurpose such keys.

Pleaee have a look at https://dev.gnupg.org/T5790, i added a patch.

The other key slots are claimed to be used for expired or archived keys as you rightfully mention. We need to figure out the real world semantic behind this before we can repurpose such keys.

And 2.3.7.

Fixed in 2.2.36.

Glad to hear. I've also now had time to manually apply the patches and have not seen any issues so far! Thank you! If anything does turn up later down the road I'll let you know.

No, no apologize needed. You did your best for the bug report, and it helped us a lot to identify the issue, and it certainly helped resulting the fixes. Moreover, your report kicked another fix of T5979 (thanks to the valgrind output).
Thank you.

I apologize, you seem to be right. Even though the package build log shows that all patches were applied, it seems there are some hunks missing in the generated sources.
I've attached my patches, but those are most likely correct. There seems to be an issue with my distribution's package manager. I will investigate this and report back afterwards. Maybe I'll just build it manually.

When compiling the package, I can see that all 4 are applied.

I think that it means that you only applied the last two patches.

Thanks again for your update.

Thanks a lot for your cooperation.

I put more fix for error handling of key algorithm attribute.
The change: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.

Thanks a lot for your cooperation.

Contrary to your expectations, all gpg --card-status fail after yubikey insertion:

Please do experiment again and give us the whole log of scdaemon.log for:

• insert Yubikey initially
• run gpg --card-status (success is expected)
• remove Yubikey
• insert Yubikey second time
• run gpg --card-status (failure is expected)

In case you need any information, be sure to let me know. Maybe we can add some manual loggers to the patches, to confirm that everything is working as you imagine it to?

Umm... The problem is the last bogus octet from Yubikey. In the log, we see:

I'm certain I've applied the patches correctly. This is my current patchset:

The change improve error handling for possible other errors by device: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.

Thank you for the logs. It seems that scdaemon didn't detect the removal correctly.

I've uploaded the requested information with triple verbose and debug-all setting in the scdaemon.conf as scdaemon.log:

Applied to 2.2 branch, too.

I examined all log files you gave us, and I think that scdaemon with PC/SC fails to detect the removal of the USB device.

I've applied the linked patch, but still experience the error. Most of the times, I cannot access my yubikey at all and I am not sure what is blocking it.
I've tried to include as much debugging output as I could below. Please let me know if there is anything else I can do to debug this.

The patch rG054d14887ef8: scd: Add workaround for ECC attribute on Yubikey. fixes a particular problem of Yubikey implementation where it returns bogus octet for its data object of C1, C2, and C3.

With the patch and after starting a new gpg-agent, gpg --card-status now works immediately.
But when I re-plug the yubikey, gpg reports gpg: OpenPGP card not available: Card error until either gpg-agent is restarted, or pcscd is restarted.
pcsc-lite in debug mode reports no errors, but one log is obviously much shorter as gpg fails early (I've attached both, same pcscd and gpg-agent instance).

I pushed a workaround.

Thank you.

This is related to the fix for T5100. We had to to remove the version number from the AID and gpg --card-status takes the version number from the AID. gpg-card was fixed for this but gpg --card-status not.

You mean Gpg4win. The solution for Gpg4win 3.1.x is to install the latest GnUPG LTS installer for Windows on top of the latest Gpg4win version. See
https://lists.gnupg.org/pipermail/gnupg-announce/2021q3/000464.html
Noet that there will very soon be a 2.2.32 to fix a problem with Let's encrypt protected keyservers (T5639).

Just for everbody else who might be waiting for a new release. Workaround is to simply use the previous version: https://www.gpg4win.de/change-history-de.html (3.1.15)

For 2.3, when you use PC/SC, please use the disable-ccid option in your .gnupg/scdaemon.conf.

Thanks for helping out @werner.

You can write your own pinentry script instead of the loopback thing. The use the envvar PINENTRY-USER_DATA to communicate with the pinentry.

It must be fixed in 2.3.2. If not, please report.

In T5436#148656, @cnp1234 wrote:

I added "disable-application piv" to ~/.gnupg/scdaemon.conf and the behavior went back to pin caching working as before. Since I don't use PIV, this is an acceptable workaround for me.

Based on the info about this being caused by the added support of PIV, I poked around on the docs at https://gnupg.org/documentation/manuals/gnupg/gpg_002dcard.html and noticed the disable-application stuff. I added "disable-application piv" to ~/.gnupg/scdaemon.conf and the behavior went back to pin caching working as before. Since I don't use PIV, this is an acceptable workaround for me.

Works for a long time now (unless we broke it again;-)