$AUTHKEYID use cases have been removed.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 13 2020
Jan 6 2020
Dec 23 2019
Dec 19 2019
Considering the concrete use case(s), it is more rational to support listing by capability.
Dec 18 2019
Nov 26 2019
This is actually unused code and it will never be called with ERR == 0. Will fix it in master anway.
[ Please do not post each compiler warning as a single report. That is just just too much overhead and we do see such messages ourselves if you would provide a bit more information. ]
Nov 18 2019
This will be in 2.2.18, closing.
Oct 29 2019
Sorry, it was simply my confusion (between GEMPC_PINPAD and GEMPC_EZIO).
Fixed now.
Oct 28 2019
Please test. When I can confirm that it is stable, I'll backport it to 2.2.
Oct 15 2019
@gniibe oh, I see thanks for pointing out precisely main the problem. I will check the hardware supply chain RoHS 2002/95/EC
@pow, thanks for a reference. But problem here is that there are multiple products with same name.
Oct 9 2019
Sep 25 2019
For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.
For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.
It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.
It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.
Aug 23 2019
Aug 22 2019
Note that rGd3f5d8544fdb needs to be backported to 2.2 but we will wait until we have better tested it.
Aug 21 2019
Aug 7 2019
Aug 6 2019
Jul 27 2019
The card was replaced by the vendor. It seems to be a problem with the specific card. All other cards so far worked well. The issue can be closed.
Jul 25 2019
I see your point (I am also the one who implements reader/token). That's reasonable argument.
Jul 22 2019
Thanks for clarification.
However, CCID_CMD_TIMEOUT should be then based on BWT value reported by the card/reader, as bulk_in() function will still timeout if BWT is longer than 5 seconds.
Thanks for pointing me in the right direction. I was confused by the hard-coded timeout value and got it all wrong.
I realized that it's a product of token. Then, I suggest that implementing time extension correctly, if some operation doesn't finish in BWT (block waiting time).
In general, if it requires more time, a reader can reply with time extension.
What's Trustica Cryptoucan?
In general, if it requires more time, a reader can reply with time extension.
FYI, we have "factory-reset" command in gpg --card-edit; It is not enough for a card to have admin locked state, but it requires normal user locked state, too.
Jul 20 2019
I applied the following with gpg-connect-agent --hex:
Jul 19 2019
I do not wonder, that you face difficulties to reproduce it. It happened only with one card from my six cards; so five cards working fine. Therefore, I thought that this particular card was may dead at arrival and I contacted the vendor. They refused to replace it with the comment, it would be a well known issue. Do you know a test where I can demonstrate that the card is dead at arrival?
It responds somehow, but the content has invalid data of (bChainParameter=0x04):
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_17 -> S LOGIN-DATA aheinecke 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 9 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 21 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bBWI ..............: 0x04 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: wLevelParameter ...: 0x0000 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0010] 00 40 05 00 CA 00 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0016] 6E 00 E1 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 4 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 21 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bStatus ...........: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bChainParameter ...: 0x04 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0010] 00 82 00 82 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 9 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 22 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bBWI ..............: 0x04 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: wLevelParameter ...: 0x0000 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0010] 00 40 05 00 CA 00 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0016] 6E 00 E1 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 4 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 22 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bStatus ...........: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bChainParameter ...: 0x04 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0010] 00 82 00 82 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 9 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 23 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bBWI ..............: 0x04 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: wLevelParameter ...: 0x0000 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0010] 00 40 05 00 CA 00 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: [0016] 6E 00 E1 2019-07-05 09:36:46 scdaemon[71407] DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT 2019-07-05 09:36:46 scdaemon[71407] ccid_transceive failed: (0x1000a) 2019-07-05 09:36:46 scdaemon[71407] apdu_send_simple(1) failed: card I/O error
After the cancellation, the card reader seems being screwed up:
It is canceled:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock: 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: dwLength ..........: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSlot .............: 0 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bSeq ..............: 19 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bStatus ...........: 64 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: bError ............: 239 2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: CCID command failed: PIN cancelled 2019-07-05 09:36:41 scdaemon[71407] DBG: dismiss pinpad entry prompt 2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 -> INQUIRE DISMISSPINPADPROMPT 2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 <- END 2019-07-05 09:36:41 scdaemon[71407] verify CHV2 failed: Invalid response 2019-07-05 09:36:41 scdaemon[71407] operation decipher result: Invalid response 2019-07-05 09:36:41 scdaemon[71407] app_decipher failed: Invalid response 2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 -> ERR 100663372 Invalid response <SCD>
Please note that key generation is takes time unusually longer from a viewpoint of card reader.
It is possible for a card reader to give up the execution of key generation command as timeout.
I am trying to reproduce your problem with my 3.3 card using my TTXS card reader.
Jul 18 2019
I use the internal driver.
Are you using pcscd (is that process running) or the internal driver.? Please try the latter if you are not already using it.
Jul 9 2019
I pushed my change of rGc51a5685554a: scd: ccid-driver: Initial getting ATR more robustly..
With TTXS, scdaemon correctly recovers from the error.
When the computer is going to suspend, the scdaemon receives a message from USB layer as the interrupt transfer is shutting down, then scdaemon considers it's removal of device/card.
But in case of suspend (and the device does not support USB suspend), USB port is kept with the power.
So, it keeps running actually.
Here are results of my experiment with Intel NUC computer (which supports S4 (and S3)).
Jul 8 2019
No. I intentionally select: Not-backporting this feature.
The feature is added for Yubikey, in the specification.
Use of the feature by Data-Object is not that so useful.
Jul 5 2019
I think we should not backport this to 2.2 - okay?
Jun 10 2019
Thanks a lot @gniibe for this change.
I do understand and share your concerns, nevertheless are there, in my opinion valid reasons to be able to have a backup or duplicate, especially on the same or similar media type.
Consider for example giving multiple devices a chance of common interaction, using the keys for backup encryption etc. - I think there are several possible use-cases which can benefit from this.
Jun 4 2019
I see the regression of gpgconf. I wonder if it's better to fix gpgconf side, too.
I see a regression with your fix. This option is even controllable with gpgconf at the basic level. It would be better to make it a dummy option.
I meant, 'card-timeout' was not intended for controlling caching PIN on card. It was for "DISCONNECT" command support.
I'm going to remove questionable documentation.
Closing.
While it's not recommended, current master has a support of sharing same raw key materials. I think that it now works (I don't try, though).
Closing.
May 23 2019
Simply sending "KILLSCD" is implemented.
May 21 2019
In master, I pushed a change, closing.
For future, it would make sense applying your patch, but I wonder if it works on macOS.
Let me check.
May 20 2019
When having a backup media, I'd recommend completely different one (for example, on paper using paperkey to be stored in a locker in basement), which requires different method for recovering. Brains may be easily confused when same private key material exists in multiple similar devices.
Thanks for this @gniibe. I have long been frustrated by trying to save the correct "stubs" to have my keyring point at two different smartcards. It was common and even advocated in my former community to place one's master key on a separate smartcard (certify capability), with a different one designated for daily usage.
Thanks Gniibe San for explanation.
May 17 2019
@blades: This feature will be available in GnuPG 2.3, which is planed to be released this year.
For Debian, Buster will come with GnuPG 2.2.12. After release of GnuPG 2.3, backport might be available (like GnuPG 2.2.x is available as backport for Stretch).
May 16 2019
Helo and forgive me for the ignorance, Iam a new.
I subscribed to this topic because I need a fix like that, I have 2 yubikeys with same subkeys...
Now how is possible to install from master; It's about a debian based distro. Also, when this will be pushed for updates via apt-get;
Thank you.
Apr 9 2019
We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.
Apr 8 2019
Apr 5 2019
I did lot of tests in the last weeks while working on gpg-card.
Mar 28 2019
Good that it works again for you.
I don't anymore think that it makes sense to fix it. Further there is no cache for PINs; that is entirely up to the card.
This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...
Thanks so much your helps.
With new version 3.1.6, I can generate key on Kleopatra tool and use key stored in smartcard.
Mar 27 2019
Mar 26 2019
There was indeed a problem. With a test card I could reproduce the issue and fix it.
Mar 6 2019
Thanks for fixing that.
That's my badness. In wait_child_thread, assuan_release may cause thread context switch to agent_reset_scd which accesses scd_local_list; This access should be serialized.
And... in start_scd, calling unlock_scd should be after unlocking start_scd_lock.
Feb 26 2019
Does not happen in 2.2. Additional requirement to test this bug in master: Another connection to the scdaemon must be open. For example running scute or, easier, call "gpg --card-edit" and keep it open.
Feb 19 2019
Gnuk implements the feature, and newer GnuPG shows a dialog to request pushing the ack button.