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;-)

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.

For KDF setup (00F9), setting it to '' (null, to reset the DO) doesn't work, but it raises 6a80.
Once KDF is enabled, only factory-reset can reset the feature.

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.

I set the priority 'High' as Yubikey NEO is the last one with source code available, IIUC.

@kianga
Thanks for your log.

I was just about to open a similar bug report, but I think this might be related. I’m also having trouble getting my Yubikey NEO to work with the latest update, however my log output looks different (see below) and this is on Windows (10 Pro, 21H1, build 19043.1055).

Thank you @werner I will apply the patch and recompile the .28 version for myself.

Fix will eventually go into 2.2.29. If there is enough public demand we will do a new Windows installer earlier.

For Reset Code (00D3), setting it to '' (null, to reset the DO) doesn't work, but it raises 6a80.
Once it sets by something, only factory-reset can remove the value.

While scd/app-openpgp.c assumes access of 006E composite data object to get its children objects like AID (004F), Card Capabilities (0047), etc., yubikey raises 6e82 error for the DO.

For the Data Object of serial number, what I read is this code: https://github.com/Yubico/yubikey-manager

FWIW: Actually the old code assumed that the s/n is at least 4 bytes. IIRC, I once checked the source of the Yubico tools to get this info.

The device with serial number 10000003, it is represented as three bytes: 00989683

In 2.3, the logic to identify Yubikey has been changed (to support PIV application).

In your log, it says:

usb_claim_interface failed: -3

Sorry, I was wrong.

I need to see how we can pass the check permission notice up to gpg. This is a too common problem and thus serves some special treatment.

GPG Version :

In T5442#146871, @gniibe wrote:

I see your situation

Could you please help me to analyze what's going on?
Please add following lines to your scdaemon.conf to see CCID driver's debug output:

debug-ccid-driver
verbose
verbose
verbose

And share the debug output.

Ah, I think that your problem was fixed in rG53bdc6288f9b: scd: Recover the partial match for PORTSTR for PC/SC. (to be 2.3.2).

I see your situation

In T5442#146869, @gniibe wrote:

If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?

If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?

In T5415#146808, @KasparEtter wrote:

Please excuse my late reply. I was busy with other things over the last few weeks.

Yes, putting disable-ccid into ~/.gnupg/scdaemon.conf works for me with GnuPG 2.3.1 under macOS Catalina (10.15).

I still don't understand what the problem is/was, so I cannot judge whether it's better to recommend this manual configuration for Mac users or to disable CCID by default on macOS.

Please excuse my late reply. I was busy with other things over the last few weeks.

So, has this issue been solved?

Please read also the report T5442 which is basically the same.

Thanks for the well written report. We had another already, and thus I merged it into T5415.

(I disabled this boor and restored the 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

That would required that we also add an option --enable-ccid-driver - better tell the macOS folks to put diable-ccid-driver into /etc/gnupg/scdaemon.conf

Or... we could add --disable-ccid-driver as default for macOS.

If it is built with LIBUSB enabled, please try adding the following to your scdaemon.conf:

disable-ccid

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

Also let me know if there are any daemons I have to kill/restart when switching between GnuPG versions by changing the $PATH. Whenever I have problems with my YubiKey, I run gpgconf --kill gpg-agent, which I also executed when I switched from version 2.2.27 back to 2.3.1 but I have no idea whether this is required or sufficient.

Run gpg --debug ipc --card-status to quickly see the communication with the scdaemon.

Already have set another, thanks gnibe! See ya!

Please change your passphrase for your card, BTW.

Good. The error recovery worked well.

Thank you for your testing.
May I ask more test, please?

Hi, I have applied both patch and appears Yubikey is now working correct. I have uploaded the log here.

In T5167#140229, @gbschenkel wrote:

Nice, I gonna apply the patch and see if resolves for me!

Nice, I gonna apply the patch and see if resolves for me!

With my Yubikey NEO, when I use OTP (touching the button to generate OTP output as key input), I observed "card eject" event:

2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: interrupt callback 0 (2)
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: NotifySlotChange: 02
2020-12-10 11:23:05 scdaemon[7254] DBG: ccid-driver: CCID: card removed
2020-12-10 11:23:05 scdaemon[7254] DBG: enter: apdu_get_status: slot=0 hang=0
2020-12-10 11:23:05 scdaemon[7254] DBG: leave: apdu_get_status => sw=0x1000c status=0
2020-12-10 11:23:05 scdaemon[7254] DBG: Removal of a card: 0

I checked the development log for the addition of:

libusb_clear_halt (handle->idev, handle->ep_intr);

In T5167#139966, @gbschenkel wrote:

I have another yubikey neo but its clean. Can it help it?

I have another yubikey neo but its clean. Can it help it?

In T5167#139964, @gbschenkel wrote:

Changing modes will I lose/change my OTP and FIDO codes?

Changing modes will I lose/change my OTP and FIDO codes?

Following device (a bit older than yours, I guess) works well:

DBG: ccid-driver: idVendor: 1050  idProduct: 0112  bcdDevice: 0334

When I configure it to OTP+FIDO+CCID, it also works for me, it is:

DBG: ccid-driver: idVendor: 1050  idProduct: 0116  bcdDevice: 0334