Applied to 2.4 branch.

@mwalle Thank you for your testing.
Applied to master.
After testing, I'll also apply to 2.4 branch.

FWIW, I've tested this patch and it works fine with both KDF as a constructed tag and as a primitive tag.

I'm considering applying the following patch. With this change, scdaemon will works well with a card implementation which consider F9 (wrongly) as primitive data object, as well as correct card implementation.

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 26ac91ea2..09223ce33 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -410,6 +410,10 @@ get_cached_data (app_t app, int tag,
   size_t len;
   struct cache_s *c;
   int exmode;
+  int do_constructed = 0;
+
+  if ((tag < 0x0100 && (tag & 0x20)) || (tag >= 0x0100 && (tag & 0x2000)))
+    do_constructed = 1;

Please keep also in mind that the OpenPGP card specification has always and is still developed along with GnuPG . Thus if there are any uncertainties in the specification GnuPG's way of handling thing is the way to go. If there is a way to chnage things without risking any breakage we can of course fix that. In all other cases we need to continue wit the current way. For larger changes in the spec we can of course cleanup stuff - Achim is currently reworking on a revision.

Please keep in mind, that it is not only about GnuPG and the OpenPGP card, but also between GnuPG and other PGP applications. I'm not really sure what the recent commit is doing, if it only affect the reading or also the writing of the data. But IMHO GnuPG should stick to the standard also if writing the KDF DO data because eventually, it will be used for authentication with the card.

Given the situation where GnuPG works well with existing OpenPGP card implementations, what we should do here is, perhaps:

There are multiple problems described in your report. Let us handle one by one.

But only if you can figure out in a transaction or locked sytate whether the card needs a verify. Otherwise we have a race between changing the PIN and verifying a PIN.

This rejection could be relaxed.

See also rG40b85d8e8cecadf35e51e84b30de4fac820d714b for gnupg 2.4.

See also: https://gnupg.org/blog/20240125-smartcard-backup-key.html

It looks like hardware problem or card reader problem.
Please test with debug-ccid-driver line in scdaemon.conf to see lower-lever (driver debug) message.

The solution seems to be a newer libccid version. If that is the case we may want to include the fix also in our own ccid driver.

Got this from my card vendor. Sonoma had a buggy CCID driver; compile one yourself and the bug's gone: https://forums.developer.apple.com/forums/thread/732091?answerId=768462022#768462022

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.

Also fixed in the fortgcoming 2.2.43

Fixed in 2.4.4 and 2.2.43 - see above for affected versions.

Works for the two sample RSA cards. Ticket may eventually be re-opened if we run into problems with ECC cards.

We need to fix 2.2.42 too. This because we backported the responsible patch.

We tested with Kleopatra:

• Only gpg4win 4.2 is affected (the current version) but 4.1 is not affected.
• No vsd version is affected.

FWIW, I am already working on this.