How about distinguishing CARDNO and application specific SERIALNO?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 20 2020
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..
Nov 19 2020
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.
Nov 18 2020
Nov 16 2020
Nov 13 2020
Nov 12 2020
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.
Nov 11 2020
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 ....:
Nov 10 2020
For 2.2, rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN. fixed this problem.
Nov 9 2020
Nov 5 2020
For SPR532, we need following.
Nov 4 2020
Nov 2 2020
We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.
Oct 30 2020
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.
Oct 28 2020
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.
Oct 27 2020
Oct 1 2020
Sep 30 2020
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.
Sep 28 2020
The patch rG684a52dffa8b: scd: Change handling of SPR532 card reader. makes me happier. It is more stable.
Sep 11 2020
Sep 3 2020
It's a different issue: Gnuk doesn't support length of 3072, only 2048 and 4096.
Sep 2 2020
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:
Sep 1 2020
I should add a test with Gnuk to my Windows quick test after a release.
Thanks a lot. Applied and pushed.
Aug 28 2020
Aug 27 2020
0.2.0 was just released with support for GCM. Tested against openpgpkeys.pm.me
Aug 25 2020
Aug 24 2020
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!
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.
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.
Jul 16 2020
This fix reveals the problem of: T4994: Windows: assuan_sock_init or WSAStartup by main/_init_common_subsystem
Jul 13 2020
Pushed fix to master and STABLE-BRANCH-2-2.
Jul 10 2020
Jul 9 2020
It's in master (to be gnupg 2.3).
Enjoy.
May 29 2020
May 28 2020
Is there a blogpost or similar where the use of several smartcards following this improvement is explained to n00bs like me? :) For now all I find is this thread and some SE answers saying it does not work yet (https://security.stackexchange.com/questions/154702/gpg-encryption-subkey-on-multiple-smart-cards-issue) . If somebody could post a new answer on SE / write a small blog post or similar that would be great. Useful would be to have 1) from which versions and over is that available 2) how this works / how to use.
May 21 2020
Fixed in master and applied to 2.2 branch too.
May 19 2020
Seems to be fixed now.
Finished if an existing key is used. See rG6dc3846d78192e393be73c16c72750734a9174d1 for examples.
May 14 2020
Apr 28 2020
I tested with this patch (which changes use of constant-time routine when it's secure memory):