Fri, Sep 11
Thu, Sep 3
It's a different issue: Gnuk doesn't support length of 3072, only 2048 and 4096.
Wed, Sep 2
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:
Tue, Sep 1
I should add a test with Gnuk to my Windows quick test after a release.
Thanks a lot. Applied and pushed.
Fri, Aug 28
Thu, Aug 27
0.2.0 was just released with support for GCM. Tested against openpgpkeys.pm.me
Tue, Aug 25
Mon, Aug 24
Aug 19 2020
For GNU/Linux, it's done.
Aug 10 2020
Aug 9 2020
We won't do that for 2.2.
Aug 7 2020
Aug 5 2020
Jul 31 2020
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.
Jul 30 2020
Patch backported to 2.2
Pushed modified patch to master and 2.2.
Jul 29 2020
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.
Jul 17 2020
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..
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.
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.
Jul 16 2020
This fix reveals the problem of: T4994: Windows: assuan_sock_init or WSAStartup by main/_init_common_subsystem
Jul 15 2020
Jul 13 2020
Pushed fix to master and STABLE-BRANCH-2-2.