So we need a way to launch scdaemon via userv and make sure that the scdaemon user gives proper permissions to its socket file. gpg-agent also nees to check for a proper version of scdaemon and gpgme needs to be aware of this as well (if it want to directly connect to scdaemon).

Fixed in rG01fa318be0f8: scd: Fix how scdaemon pipe server finishes.

Asking a change of gpgme would need more time... So, I decided to change gpg-agent side.
gpg-agent part was done in: rGb3f1f2cd192b: agent: Handle SCD DEVINFO --watch command in a special way.

scdaemon part was done in: rG36d8cffc6cd2: scd: Finish DEVINFO --watch command on input close.

Maybe we can support this directly in gpgme's assuan API.

Did some experiment and I concluded (for now) that new command for gpg-agent would not be needed.
Instead, it might be better doing following in GPGME.

Thanks for your answer, @werner

Do not use the pcscd but the integrated CCID driver. This is actually the default form Unix. Or are you on Windows?

Hello all. I think I am affected by this problem (I get asked for the yubikey PIV pin every time I make a git commit).
Is there a known workaround?

Pushed the fix: rGbb57c808b2ad: scd:openpgp: Fix PIN pin2hash_if_kdf.

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.

Currently, there is no support for gpg-agent to keep private key not on disk, but only on memory of gpg-agent. Given the situation,
I think that it is good to:

The extra option --debug-allow-pin-logging was implemented with commit rGe43bd2a7a78.

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

GnuPG 2.2 and 2.4 now have --pcsc-shared option for a user who can control his action in detail.
So, closing this bug report.

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.

It's true that for KEYTOCARD command, there is optional argument for ECDH.
My point is that for PKDECRYPT command, it will be needed to add mechanism for getting such a parameter (when we use KEM API in gpg-agent).

We already have the ECDH parameters for OpenPGP in the gpg-agent API. The question is how large the data for PQC will be - likely we need to use an inquire already for this reason.

Considering the design of gpg-agent which focuses on private key operations and data, it would be better to enhance the gpg-agent protocol to inquire public key data of any format defined by the client (including ECDH KDF parameters of OpenPGP). I mean, instead of storing data in the key file (originally designed for private key + some additional data), we will enhance the protocol.

Pushed the changes for ...sc_op_failure routines to master/2.4.

We would need to revise tools/card-call-scd.c:status_sc_op_failure and g10/card-util.c:write_sc_op_status to catch GPG_ERR_PIN_BLOCKED and GOG_ERR_NO_RESET_CODE.

I found two places in scdaemon which return GPG_ERR_BAD_PIN. GPG_ERR_PIN_BLOCKED is relevant here.

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 66ec9f4a9..77d428786 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -2859,7 +2859,7 @@ build_enter_admin_pin_prompt (app_t app, char **r_prompt, int *r_remaining)
   if (!remaining)
     {
       log_info (_("card is permanently locked!\n"));
-      return gpg_error (GPG_ERR_BAD_PIN);
+      return gpg_error (GPG_ERR_PIN_BLOCKED);
     }

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:

The second retry counter is used by current cards for the Reset Code error counter. It is zero if no reset code has been set. It was used by card specs 1.x for the CHV2 only available there.

This may be related to the output PIN retry counter : 3 0 3, i.e. the PUK counter is 0. No idea what this means.

The same is true for trying to unblock the card with the PUK. Again I have to enter 3 PINs in 3 windows before being informed that the entry in the first window was wrong. Additionally, the text in window 1 is borked

If you try "Change PIN" next, you will be asked for the PIN and 2x for the New PIN in altogether 3 pinentry windows before being informed that the PIN is blocked.

After the 3rd entry of the wrong PIN, this is exactly the same.
Here I would wish for not only the popup "wrong PIN" but additionally this popup should declare "PIN blocked".