@bb - I've tried this, this doesn't appear to work. It looks like the Gtk2 pinentry doesn't grab focus when doing authentication, either. Interestingly enough, it also doesn't show in the taskbar.

Note:
I added:

pinentry-program "C:\Program Files (x86)\Gpg4win\bin\pinentry-gtk-2.exe"

as a workaround to my gpg-agent.conf. This pinentry is able to grab the focus.

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.

Does anyone has an update on this issue?

I've just uploaded pinentry 1.1.0-3 to debian unstable with this fix in it.

@aheinecke thanks for the heads-up. i'll pull this in.

Thanks. So, this is a positive report for 8E60:34C2. I'm going to add this VID:PID to support pinpad input by the internal CCID driver.

Pinpad input is not supported for Gemalto Ezio Shield, currently. OpenPGP card expects variable length pinpad input, and we don't have any positive report with the card reader.

we won't backport it to 2.2

Can you help me please to understand why you think that this is a regular use case?

Fairly typical situation: user needs to encrypt binary and text regularly

Pinpad input is not supported for Gemalto Ezio Shield, currently. OpenPGP card expects variable length pinpad input, and we don't have any positive report with the card reader.

@aheinecke , Would you consider re-opening this ticket?

Wow, thanks for the quick response! I've applied your patch to the Ubuntu package (2.2.4-1ubuntu1.2), and gpg --card-status now works fine:

@dkg This patch ( rP0e2e53) might also be something for debian as it can cause crashes depending on the qt theme, which is not under our control.

Thanks!

I can confirm that the patch from the referenced commit fixes the issue. Thanks for the quick action!

thanks for the report. I've commited a different fix 0e2e53c8987d6f236aaef515eb005e8e86397fbc which also should solve the problem.

Adding the patch here.

I pushed a fix to master: rG858dc9564326: scd: Fix bBWI value.

I've just broken out my changes into two commits, one that makes gpg and gpgsm more robust. That should be applicable without any risk.

I see your point (I am also the one who implements reader/token). That's reasonable argument.

Thanks for your report, with helpful log.

thanks for the report and trying to help with Gpg4win. The underlying problem is that our backend (GnuPG) does not provide proper error handling when changing the expiry date. We already had an issue for that so I've merged this task with T4395.

I've just posted rGb84feb0c82eb to the dkg-fix-T4652 branch, which solves the failure problems by making agent_pkdecrypt and gpgsm_agent_pkdecrypt more robust.

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)

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.

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.

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).

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:

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?

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?

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.

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.

I'm aware of you releasing an RC for comments, and i apologize for not catching this particular case earlier. As you know from T4607, i was even advocating for it. i didn't understand the full implications of the "import-then-clean" approach at the time, and was thinking it would only apply to the incoming material, not the stored material.

Are you using pcscd (is that process running) or the internal driver.? Please try the latter if you are not already using it.

The code has comments why we do a first clean_key on the imported keyblock.

All my keys are RSA 4096. It worked fine with OpenPGP smart cards and with two Yubikey 5. On all devices a set of RSA 4096 keys were geneated on the device itself. Only one card failed. But even the card which failed, generated at least the signature key in RSA 4096.

Please let us know what kind of key and how large, like RSA-4096 or ECC Brainpool.
For RSA 2048 or larger, yes, it takes too long.

I mean, if all SKESK packets should be tried, we need some larger surgery of current implementation.

Is it possible for your application (DOTS), to specify the packet number for SKESKP, not trying all SKESK packets?

i've merged a variant of rGbe99eec2b105eb5f8e3759147ae351dcc40560ad into the GnuPG packaging in debian unstable as of version 2.2.17-3 to avoid the risks of data loss and signature verification failures. I'll revert it if i see the concern addressed upstream.

@gniibe, thank you for backporting this to STABLE-BRANCH-2-2!

But that's exactly my use case in DOTS: an easily to create 'decryption puzzle' (including the hardness of iterated and salted S2K) for the serving party in order to make DoS harder. I don't see how public-key crypto can help here. Moreover, I would keep the user interaction as cheap as possible, i.e., copy'n'paste an ASCII-armored message and passwort to GnuPG without importing public keys etc.

The problem here is that trial decryption may cost a lot of time because of the passphrase KDF function which, on purpose, takes long. There is one exception: A simple S2K (algo 0) takes no time and its use makes sense iff the passphrase has been created directly as a random string. However, I do not see the use cases for of a set of many passphrases compared to just use public key crypto.

I should may add, that on the card which failed, only the signature key was generated and written to the card. The authentication and encryption keys could not be generated..

@gniibe Thanks for explaining the background. Are there any ideas for fixing? (e.g. the decrypted content could be checked for a valid packet structure or at least for starting with a valid packet header)

does the removal of the gpg22 tag mean that it will not be possible to rely on colon-delimited output for the gpg 2.2 series?

Just a note that we're now shipping this patch in debian unstable. It would be great if it was merged upstream.

that pseudocode is strange to me -- it looks like you have (two) duplicate calls to clean_key (imported_keyblock) (though maybe i just don't know what .... means in this pseudocode).

Thanks, fixed in master.

You are partly right. I missed that we also do clean the original keyblock while updating a key. The code is

I see. I am also mostly testing with ntbtls so I was wondering about the report. Thanks for reporting and fixing.

Current situation of *.pc: static linking is not supported (yet).
It has never supported, actually, by *-config.