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:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 17 2020
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):
Apr 14 2020
Apr 9 2020
There are no betas; either you apply the patch mentioned above ( rG2f08a4f25df7) to a stock 2.2.20 or you build from the Git repo (STABLE-BRANCH-2-2, see https://gnupg.org/download/git.html).
Could you guide me to where I find the beta or snapshot, so I could test it and give you feedback? I seem to be unable to find it on my own.
Push the change to master.
Apr 8 2020
That's odd. :-)
FWIW, the code was written by the author of the specs and he note in his original patch (rGe0972d3d96) :
Thanks for your report. The problem of GnuPG was that it mandated padding length < 16 bytes, which is wrong.
Apr 7 2020
Apr 6 2020
Apr 3 2020
Pushed the changes.
Apr 2 2020
It runs like:
$ gpg-connect-agent "scd devinfo --watch" /bye S DEVINFO_START S DEVINFO_END S DEVINFO_STATUS new S DEVINFO_START S DEVICE generic D276000124010200F517000000010000 openpgp S DEVINFO_END S DEVINFO_STATUS removal S DEVINFO_START S DEVINFO_END OK $
Push the change to master.
Mar 24 2020
This should work well with libksba master and gnupg/sm master.
The commits in 2019 (for libksba and gnupg/sm) handles the problem (of key generation using card).
Mar 20 2020
Mar 19 2020
Mar 18 2020
Backported to 2.2
Mar 13 2020
I am not sure whether this is related but when using Libgcrypt master and verifying a signature created with an ed25519 key, I get the error below with valgrind. Both with 2.2. current and 2.3. It does not happen with the current Libgcrypt 1.8.
Mar 12 2020
Mar 11 2020
Fixed in master.
Feb 28 2020
I pushed the change to master.
Feb 19 2020
I can confirm that the problem is gone from a build from the master branch. It indeed retries the search.
Jan 17 2020
Implemented in master.
Jan 16 2020
BTW, I just pushed some new features to maste for the gpg-card tool. You can now do
The first "SCD SERIALNO" command let scdaemon re-scan smartcards/tokens.
With new "KEYINFO" command in scdaemon, a list of card keys can be retrieved by:
Dec 23 2019
Dec 18 2019
Dec 17 2019
Many cards have some printed information and I consider them important to avoid testing one by one all the cards from my pocket.
This I am really in favor of beeing asked to insert the respective card. The new text format private key files make it much easier to maintain this info
Dec 6 2019
In 2.2.18, this fix is not included. (partial fix was reverted)
Nov 25 2019
Nov 18 2019
This will be in 2.2.18, closing.