This works now. Thanks.

Backported.

We need another patch, because there are two places for gpg --card-edit and gpg-card to check OpenPGPcard's version number if it's >= 2 or not.

In T2291#139821, @lopter wrote:

if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

Thank you for all the work! Does it mean that, if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

I think that T5150 was also not fixed completely.

So, I'm going to push D513 to both of 1.8 and master (to be 1.9).

Works now. Thanks.

Sorry, I realized this myself this morning and did couple of fixes. rG7113263a00d8 does this all however I forgot to mention the bug number.

Argh. The following patch replaces the previous patch. It fixes the calculation of the display serial number.

I think the calculation of the OpenPGP s/n is not correct. As you write, "Yubico seems to use the decimalized version of their S/N as the OpenPGP card S/N." This matches my observation for my Yubikey:
s/n printed on Yubikey: 9074582
Yubikey s/n (with our prefix): FF020001008A7796
OpenPGP AID: D2760001240102010006090745820000

Great. Please apply the patch.

Okay, I now got such a patch:

I found a good enough solution: I changed the code to compute the OpenPGP s/n from the Yubikey s/n right after a Yubikey has been detected. Later, and if OpenPGP enabled on the YK, the S/N is already there but we use the S/N from the 0x4f DO. That is needed because we can't compute the OpenPGP version number ahead and use 0.0 in the S/N.

Stable now and works as expected. Thank you!

Its done for 2.2 thus changing the tag.

How about distinguishing CARDNO and application specific SERIALNO?

Yes, it is due to a backport from master: rG1049f06c6d2e: scd:openpgp: Allow keygrip to be used to reference a key
Fixed in rG84020385be19: scd:openpgp: Public keys should be available for check_keyidstr..

The problem seems to have returned in 2.2.24.

Thanks again for your report.

I'm still having problems with 2.2.24. Now the card removal is detected correctly, but the initialization fails.

BTW, the idea is to fade out support for gpg --card-status and --card-edit. Thus no new features there. New features shall only go into gpg-card.

Fixing --card-status is definitely a good idea. gpg-card shows almost the same information as gpg --card-status except that it shows the correct "Version" and "Serial number". It would probably make sense to unify the code of --card-status and gpg-card's list command.

Let me describe current situation.

I just noticed that gpg --card-status now prints a bogus OpenPGP version number for my Yubikey. And it prints an empty serial number.

# gpg --card-status
Reader ...........: 1050:0407:X:0
Application ID ...: FF020001008A7796
Application type .: OpenPGP
Version ..........: 77.96
Manufacturer .....: Yubico
Serial number ....:

For 2.2, rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN. fixed this problem.

For SPR532, we need following.

We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.

Fixed in 2.2 branch.
Also, I found another issue of libgcrypt master, which is fixed in rC361a0588489c: ecc: Handle removed zeros at the beginning for Ed25519..
Further, I found different issue, and created T5116: GnuPG master shows an error when importing Ed25519 keys generated.

I have tested this with Kleopatra. The good news is that SCD GETATTR $DISPSERIALNO now works for the piv app even if the openpgp app is enabled.

I observed that the card reader's going erroneous state when I removed a card during its communication.
In this state, it never reports the card removal by the interrupt transfer.
I applied rG920f258eb601: scd: Internal CCID driver: More fix for SPR532. for this problem.

The patch rG684a52dffa8b: scd: Change handling of SPR532 card reader. makes me happier. It is more stable.

It's a different issue: Gnuk doesn't support length of 3072, only 2048 and 4096.

Hi,
I have tested a GnuPG Token with Gpg4win-3.1.12 and generating a key with Kleopatra did not work
With 2.2.23-beta4 that contains: 0a9665187a7cbf68933b7162fb5f974177684a50 I have repeated the test on Linux and first the key-attr change that Kleopatra sends fails:

I should add a test with Gnuk to my Windows quick test after a release.

Thanks a lot. Applied and pushed.

0.2.0 was just released with support for GCM. Tested against openpgpkeys.pm.me

For GNU/Linux, it's done.

We won't do that for 2.2.

I realized that it fails with GPG_ERR_INV_ID (with gpg master) when it's on smartcard.
It can't be decrypted if it's on smartcard, that's true, but more relevant error would be good for this case.

Patch backported to 2.2

Pushed modified patch to master and 2.2.

I just saw that there is related discussion and a patch for this in T4994 so I will close again here.

This change broke for me the compilation of GPGME which I fixed with: 52f930c1ed7eee6336a41598c90ef3605b7ed02b I found that fix there OK because GPGME explicitly uses ws2_32.

That could also be the reason for some strange behaviour I have sometimes with my bunch or readers. I have not had the time to look into this and thus opted for a gpgconf --kill scdaemon which fixes things quickly but of course this is a bad workaround.

I am happy that your use case will be supported, and the bug was fixed before the release.
It's me who say "thank you" to you!

46d185f60 doesn't segfault and does prints the YubiKey card information, even without reader-port configured. Perfect! That will fix the issue for me. Looking forward to seeing it released. Thanks again @gniibe!

Thanks a lot.
I pushed a fix as rG46d185f60397: scd: PC/SC: Don't release the context when it's in use..

Thanks again @gniibe! In case it's still useful, I bisected to 1080e91ef. The output with --debug-all --debug-level guru is:

Ah, I identified an issue.
While it's in a loop of trying readers (in select_application in scd/app.c), it should not deallocate resources to access readers, even if reference count == 0.
I'll fix.

Thanks for your testing.