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:

Fixed in GnuPG 2.3.1, so, add the tag for GnuPG 2.2.

Making this task up to HIGH priority, so that people can easily find this change in 2.3.0.

The PKCS#15 support has meanwhile received a major update. Thus we need to test with the other cards again. If there is something special for to do for a certain task, a new subtask should be created.

Thank you.
Applied both to STABLE-BRANCH-2-2 and master (changing new function name).

Looks good to me, it no longer returns immediately with the error when there are no readers and the command itself seems to work. Thanks.

Ah, I see that when there is no card reader, it returns "Service is not running" with PC/SC.
Let's fix that.

When testing under Windows "scd devinfo --watch" returns immediately with ERR 100663614 Service is not running <SCD>
Probably also if you would use PC/SC on Linux but I have not tested this.

So far -- unlike the previous patch -- this seem to help (but since the issues are infrequent I can't be entirely sure yet).

The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.

T4702 is our release info task for 2.3.0

@gniibe Hi! Can you estimate, when this feature will be released?
I have not found this patch in the latest GnuPG release tags (in the Git repository) either by the name or the commit hash.

Lowered priority because in reality it is not possible to get a certificate for an arbitrary SigG key on the card. Only accredited CAs may issue certs and they want to keep full control over the key generation.

do_sign() calls find_fid_by_keyref() which does a switch_application(). So, I think the SigG application should already be active. But, yes, please have a look at it.

We need to switch to the SigG application. Shall I look at it?

It seems you have a pretty good understanding and also test cases at hand. May I ask you to apply the suggested pacthes to master?