As long as we can't replicate this, it does not make sense to keep this bug open. Please re-open it if you run into it again in a replicatable way.

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

by the way when the applet is selected, I return
D2760001240103045343000000010000
this can be used to detect the manufacturer number

Card ATR at the cool reset
Card ATR is : 3B 9C 95 81 01 50 53 43 50 2D 53 43 53 56 31 2E 30 8E
Historical Byte is 53435356312E30
CARD ATS-to-ATR is : 3B 8C 80 01 50 53 43 50 2D 53 43 53 56 31 2E 30 0A
CARD ATS is : 11 78 80 B8 02 50 53 43 50 2D 53 43 53 56 31 2E 30
Historical Byte is 53435356312E30
This can by detected for the card type.

Is there another way to to detect your card (I assume a Javacard) without relying on the openpgp card application vendor-id like we do it with the Yubikey? I want to avoid a possible early but expensive AID selection just to get the vendor-id.

Fixed in 2.3.2.

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

This rwlock guarantees access with ctrl->card_ctx is always valid.

FWIW: We have always refused to support shared mode because we anticipated such problems. However, we have a customer using their own cards along with card maintenance software of them. For their purposes PCSC_SHARED works just fine makes and this is why I decided to add --pcsc-shared along with a warning that it is in general not a good idea.

You need to protect only 2 critical set of ADPU sequence Sign and Decrypt. All other can be done not safely and have a minor impact. Get generation and cards unlock can be profitable with the transaction mode... but is very rare user makes another use of the card in same time he start that’s command. The check external interference can protect from a bad start. I have started this ticket because my card suffer in exclusive mode render the use of openpgp not really usable. When my card is an pcsc-shared mode, all it's OK but the daemon not able to restore after external interference. The correction proposed is OK but I have made recommendations because this can cause a bad applet switch... if the state does not restore before trying to switch applet all it's OK. I am not actually able to set directly differential code but I have described in the patch the change I have made and this make my card very happy. Not problems and the pin was queried if another application makes interference.

There are multiple issues here.

OK I have finally success to test... the master version has a problem with opening pcsc readers on windows I revert back on older version to able to correct this problem. For the current patch without yubikey reference. I suggest validating the interference in the first task for the maybe_switch app function.

In fact, the trigger is not yubikey but the pcsc-shared flag... If the pcsc-shared flag is enabled, you do check for interference because you are in shared condition. It is not really a race condition because you can put the driver in transaction mode. It’s more a turn-by-turn games but you can lose the card context status between turn.
If you lock the patch only for yubikey I’m not able to test with my device. You can add my manufacturer ID in the test please.

Thank you for your explanation.

It's not a device is a card. NXP P71 security chips on the card in the 250Kb Rom with GlobalPlateform 2.1.1 It is not possible for a card to change CCID by applet. Card depends of reader CCID. When the card is on NFC readers, the FIDO applet is accessible not when it is on contact readers. But, when I am in NFC FIDO share the CCID. For the user point of view having multiple card for each applet is a bad thing to devices for one user. User search presently for multipurpose devices. DOOR, Login, Email-crypt, ledger. Actually for app is not recommended to use a reader in exclusive mode. By designs the card is stateless and for memory management deselect applet free mem from other applet. Presently in the best case the card has 144-255 KB of eeprom and 2k or ram.

If your token/card is not Yubikey and when it is possible to improve your token/card implementation, I would suggest not follow what Yubikey does for multiple applications; No multiple applications, but each feature with independent access (card+CCID, another card+different CCID, FIDO+HID, ...).

i'am not able to test... i can't build for win32. i have some trouble with my mingw32 installation and the miss match with library for build a functional version of gnupg for win32.
seem missing dll after make install folder. do you have instruction to setup dev environment for build win32 binary ? I use a ubuntu with minwg32. ntbtls seem missing ksba but libksba is already install verion 1.6.0 other project detect correctly ksba. it's seem is a little bit complicated juste for building scd project. a make it working correctly on windows environements.

Ok i have seen a problem with a double check here

Ok, I test this, this seem can be corrected 90% of all possible interference with another application on multi-applet smartcard in shared readers context. I left you the feel back when have tested… thank for the prompt response.

For the problem of external application switch, please test this:

diff --git a/scd/app-common.h b/scd/app-common.h
index dffe1200d..d6e6f4c0a 100644
--- a/scd/app-common.h
+++ b/scd/app-common.h
@@ -194,6 +194,8 @@ struct app_ctx_s {
                       void *pincb_arg);
     gpg_error_t (*with_keygrip) (app_t app, ctrl_t ctrl, int action,
                                  const char *keygrip_str, int capability);
+    gpg_error_t (*check_aid) (app_t app, ctrl_t ctrl,
+                              const unsigned char *aid, size_t aidlen);
   } fnc;
 };

Here is the reference to GID specification:
https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn642100(v=vs.85)?redirectedfrom=MSDN

Let me add the tag "yubikey".
I think that it could be solved in different level, if I were the device manufacturer; And it would give users the best solution.

If something more user friendly is required, it could be possible for higher layer (SCDaemon's command handling) to check verification status beforehand, and do error recovery there.

I don't think we should do automatic error recovery from 6982 to retry decryption/signing, inside CMD_PSO (0x2A) operation.

I have tried the case 1 with log activated
Windows switches applet for signing Adobe Acrobat doc.
This is the log from agent - Say Bad NIP but he never tries to use the nip SCDaemon have tried to decrypt only.
gpg-agent[8496]: DBG: agent_put_cache '1//'.-1 (mode 6) requested ttl=-1
gpg-agent[8496]: DBG: chan_0x000001c0 <- S SERIALNO D2760001240103045343000000010000
gpg-agent[8496]: DBG: chan_0x000001c0 <- OK
gpg-agent[8496]: DBG: chan_0x000001c0 -> KEYINFO BBD342CA5B0F978DA17F2AD9F5A1E95FF50C129E
gpg-agent[8496]: DBG: chan_0x000001c0 <- S KEYINFO BBD342CA5B0F978DA17F2AD9F5A1E95FF50C129E T D2760001240103045343000000010000 OPENPGP.2
gpg-agent[8496]: DBG: chan_0x000001c0 <- OK
gpg-agent[8496]: DBG: chan_0x000001c0 -> SETDATA 4F0E7600C2C497A06288DF49B7EA1BC723E04FAC360D6D6C4F4DC1B48DEC13A53556229CDC4562E349C9B5E71365561A941761D1D2C709A16488903AA60925A7B103DEF6B6AE46814370AE815BFBE4A30EC443904C1D63E21ABF5B0B39B8484F3CB4235AEDA04F78F14308AE3DEF52309FB745BC65E3075D19C01C789C8F58931D957D7C26BE7DCEF6B880B362251246FA4E1A2830A13AD94635CC4CE14B0F253481F38C39BA5CC748FDF03F9D936B9C8DE6BF7E49AFF4BE3A84A4E4547FADD4C9F1634416641FF804F3503CC924098F1C4CAA908FD272737312A4D5BE59C644EE1633AA248DC996EF67BA5E087DB6312BD2014BFAFD62FD08C7D45E3AFD431C
gpg-agent[8496]: DBG: chan_0x000001c0 <- OK
gpg-agent[8496]: DBG: chan_0x000001c0 -> PKDECRYPT BBD342CA5B0F978DA17F2AD9F5A1E95FF50C129E
gpg-agent[8496]: DBG: chan_0x000001c0 <- ERR 100663383 Mauvais code personnel <SCD>
gpg-agent[8496]: smartcard decryption failed: Mauvais code personnel
gpg-agent[8496]: command 'PKDECRYPT' failed: Mauvais code personnel <SCD>
gpg-agent[8496]: DBG: chan_0x00000270 -> ERR 100663383 Mauvais code personnel <SCD>

When a card sends 0x6982 in general rule is not really an error is a warning to say, your security environment was not correctly initialized.
This is true with almost applet. (PIV – GIDS – OPenPGP)
The instruction 0x2A to perform security operation return 0x6982 when pin is not authenticated or key is badly selected. This not decrement pin counter.

Possible way would be: (for newer card/token of OpenPGPcard 3.4 or later) before crypto operations, we can ask card/token if authentication state is consistent to the one of scdaemon and if not reselect AID.

I'd like to support your use case. Could you please tell me about: How can we distinguish normal failure of 6982 and unusual failure of other application interference which results 6982?

Funny thing is that I can't replicate it anymore with the current version (2.2.18-beta77). I tested it on two machines and things just worked. One machine had just one reader and the other had several virtual readers in addition to the scr3500. After adding --reader-port for the latter it worked as well. I don't think I had a Windows update in the meantime.

I am testing with rGccfb5e0a7dc6: scd: Use SCardStatus for pcsc_get_status. on GNU/Linux.

On Windows, smartcard is also used by logon/logout and certificates handling. Those may be related.

Applied in rG32baa9acfb15: scd: Serialize READER_TABLE access for PC/SC..

Please note that we don't use lock in apdu_dev_list_start/finish any more.
Use of lock is narrowed, only within apdu_open_reader function.

(I disabled the account of this boor)

I don't think that it is --pcsc-shared related; Andre reported that he noticed such a behaviour before we introduced this.

We should add a comment at the caller side, that this takes a lock in apdu.c.

Make the lock holding narrower, and it allows no exposing reader_table_lock.

Exposing reader_table_lock would be better.
I found a dead-lock condition when apdu_close_reader is called during apdu_dev_list_start/finish.

I wonder if PCSC_SHARE_SHARED is related or not.

And if the coding style of hiding mutex_lock/mutex_unlock inside different functions matters, we can expose the mutex to its user.

Last commit will be:

The second commit is replacing a use case of close_pcsc_reader by clearing pcsc.rdrname and calling release_pcsc_context.
This makes the use of close_pcsc_reader to its original purpose only (== closing PC/SC reader as a method of close_reader).

OK. As I pointed out a commit having multiple things may make analysis difficult, I should have been careful.
So, let me fix the problem by multiple commits.

Ah, great. Thanks!

Keeping the lock over the call to the function does not look very robust to me. This is why I removed it. And since then PC/SC worked on Windows for me. Modulo this:
All these changes don't tackle the real problem that windows gets struck in a removed-card state.

Technical commentary on smartcard operation and/or Windows is going to be over my head, so I can't help (just in case you're looking for anything from me). But always happy to drive-test another build. (I've still had no issues, personally, with the build above.) I'll assume you don't need me unless you link another binary build to test or tag me. Thanks again, all.

The problem is accesses to reader_table by
(1) scanning reader(s) to open new one
(2) closing reader

I'm testing D531: Keep holding READER_LOCK_TABLE and make clear distinction among close/releasing_PCSC_context/nullify_rdrname, but I'm not sure about the impact on Windows.

The commit rGbb8e3996e44f: scd: Fix problem with reader list becoming empty. removed READER_TABLE_LOCK holding between apdu_dev_list_start and apdu_dev_list_finish, that opens possible stale resource access for CCID driver: reader_table[slot].ccid.handle

I am also a MacOS Big Sur user who recently upgraded to 2.3.1 and had problems after upgrading. In my use case, I use the yubikey as the authentication for pass password manager which uses gpg under the hood.

Thanks for testing. I hope to get 2.3.2 out in two weeks.

After upgrade:

Meanwhile we did some more tests on Windows and so you many want to try our betas at

I'm referring to this: https://www.gnupg.org/howtos/card-howto/en/ch02s03.html

@colemickens We don't maintain any ccid udev rules in GnuPG. What do you refer?

@gniibe can you provide any commentary on why the gnupg ccid udev rule is so much smaller than the one debian maintains? Is the debian one considered authoritative these days?

Thanks @gniibe, that's very helpful advice and pointers. Very appreciated, cheers.

Perhaps, if a distro haven't offered setting of USB, it would be better to configure GnuPG build with --disable-ccid-driver and only support scdaemon with PC/SC. GPG for Windows does so.

1. It's a breaking change for system with both of PC/SC and CCID. T4673 due to T3300
   • If you configure with no libusb, users don't need 'disable-ccid' option.
2. I don't know how "wide".
3. In Debian, it is maintained here: https://salsa.debian.org/debian/gnupg2/-/blob/debian/main/debian/scdaemon.udev
4. Yes.

Hi, as a contributor to NixOS I'd also like some guidance. I'm testing the 2.3 upgrade ahead of 2.4, and it "breaks" Yubikey UX that I know many of us use. This might be because we appear to not yet install gnupg's CCID udev rules installed. A few questions:

Thank you for the suggestion of disable-ccid that seems to have solved the problem.

I can confirm disable-ccid works, thank you!

Please have a look at the log: