fwiw, this patch appears to cause gpgsm to fail its test suite:

I've just pushed rG1ae16838660a to the dkg-fix-T4652 branch (i just adjusted it the commit message to include the GnuPG-bug-id)

I installed microsoft office 2016 on a brand new laptop and got the same problem described in the post listed above.
My solution was to uninstall the pre-configured app : "Microsoft Office Desktop Apps" and voila!!

Thanks aheinecke and dkg.
I havent been able to replicate the fault using the command line (using the exact same command and options that our program is calling)
however our R&D dept have,
The next time it fails and we can replicate it we will try the --homedir fix and see if thats it.
Its the same user in the program and command prompt so we dont think its a certificate issue.

when you double click a key and then click "Export" you get a copy & paste version of the key.

Thanks for the report. It is always good to have such issues documented.

This pretty much matches my test setup. As the crash is in GPGME it is out of Kleopatra's hand. So I'll try to write a test that repeats such a signing for lots of times. I think this is probably some random race condition.

I think that even if the reason is corrupted keys it would be good to handle this better, either in Kleopatra or in GnuPG. e.g. Kleopatra could detect if a keylisting takes too long and offer to do some cleanup programatically.

I don't think I can reproduce it, at least it didn't happen anymore after restarting and continuing the imports. AFAIR it happened after importing the "Master Key", during trying to import the "Release Key" from https://www.chiark.greenend.org.uk/~sgtatham/putty/keys.html
Ah and maybe one more hint: I have several keypairs, so the dialog for choosing the keypair to be used appears in the next step.

I'm also not sure how to classify this issue. I'm giving it low priority for now as we do not have the info to determine if this is a program error.

I think we had that issue in the past and solved it. It probably broke again. There is an external library we use for this dialog and that might have regressed in the latest update.

Mmh, the error log only tells me that it crashed in our GPGME library. So it is a bug in our software.

Hi Florian,

This report doesn't contain enough information to be able to tell you why the command is failing within your program, but not failing outside of it.

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.

Hi everyone,

Backported.

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.

I applied the following with gpg-connect-agent --hex:

@werner wrote:

Other tasks in master are right now more important.

Yes: at least 255 times.

IIUC, there is only a single recipient, but it has 256 SKESK packets, while only a single SKESK is valid and others are all dummy, right?

Other tasks in master are right now more important. You need to wait a bit more.

So, what about this? If I recall correctly, we had agreed in the call to merge this patch, at least into master?

Patch is pushed to master. Will be backported to 2.2.

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.

Thank you. Merged.

Sorry, perhaps, I misunderstood how SKESK packets are generated in your application.
I was considering there were 256 recipients.

If the use of GnuPG (current implementation) is a condition, I think that you could improve the generation of SKESK packets, so that no other passphrase can let gpg misunderstand as it may decrypt encrypted packet.

Unfortunately, for my use case the corresponding SKESK packet number is not known when calling GnuPG.

I use the internal driver.

@werner I would be willing to share 20% to the reviewer of my patches. (or 25% in this case, as @jwilk went through the effort to even write a test to point out a bug in my code). However, so far that has been entirely @jwilk who has been reviewing my patches.

I've just pushed rE732855a483709345a5c0f49504f45cb8da3f883a to dkg-fix-T4643 in the gpg-error git repository. I don't know why it is not yet visible here.