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.

Thanks for the detailed explanation, I'm glad to hear it! Out of curiosity, I tried running echo 'serialno openpgp' | ./scd/scdaemon --log-file - -v --server built from 43000b043 and it printed:

Thanks for your report.
Major reason was multiple card readers/tokens were not supported by PC/SC handling of scdaemon, only a single reader was assumed, so, user had to specify one if it's not the first one.
Multiple reader by PC/SC support was added in master (to be 2.3), so, I think the problem is solved in master.

This fix reveals the problem of: T4994: Windows: assuan_sock_init or WSAStartup by main/_init_common_subsystem

Pushed fix to master and STABLE-BRANCH-2-2.

Fixed in rM1b840a151ad7: python: Fix how to generate documentation..

It's in master (to be gnupg 2.3).
Enjoy.