This is the minimized test case.

Having a fallback in Kleopatra makes sense because very old HKP keyservers don't return the fingerprint and LDAP keyservers not using the modernized schema do neither.

Please read also the report T5442 which is basically the same.

Thanks for the well written report. We had another already, and thus I merged it into T5415.

I did a new test and found that if it is a single file regardless of disk size, no error appears, but when there are multiple files in a single encrypted folder with a size greater than 1.5GB, the error occurs. Traverse a directory like Zorvek and Aheinecke wrote would be an optimal solution or at least some alert messsage to be aware of the action no supported.

I have removed all of the changed code in my working copy. ;-)

I just talked with werner about that and he told me that GnuPG can return the fingerprint. And I also mentioned to him that kleopatra really assumes that a Fingerprint is always set for a valid key object.

I have allowed myself to edit this task to more reflect what this is about. Although the error is of course in my opinion more of a bug because it is so bad but I would rather fix it with this feature.

I actually agree that this makes sense. I mean at least Kleo could say: "Hey we have detected 50 files that are encryped in this folder tree, do you really want to decrypt them all?"

Should have linked the commit with a patch for Gpg4win here: 22bc52775bdb I mostly needed that as an immediate fix for someone testing with ldap servers a lot.

Funny thing is that I can't replicate it anymore with the current version (2.2.18-beta77). I tested it on two machines and things just worked. One machine had just one reader and the other had several virtual readers in addition to the scr3500. After adding --reader-port for the latter it worked as well. I don't think I had a Windows update in the meantime.

Then let's get it in there. It's pretty easy to traverse a directory.

reading your report again: You clicked on a folder and expected that all encrypted files in this folder will be decrypted? That is unfortunately not supported.

I have the same message when i try to decrypt files larger than 1.5GB in size; i atached the report "gpgconf --show-version"

Okay. Fixed with rG65bc5ea95e60: scd:p15: Fix logic for appending product name to MANUFACTURER.

Possibly, it keeps running at calibrate_s2k_count, for some reason.

I was wrong.

Note: I believe this issue might affect multiple other GnuPG projects.

In T5436#146148, @ikloecker wrote:

It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.

I fully agree. That was actually my itention - not sure why the coded ended up as it is.

Just got around to testing this on Linux, and I can confirm the same behavior: decryption PIN caching works on 2.2 and doesn't work on 2.3.

Due to tax issues, we can't accept a donation as return on service. However, we will fix bugs anyway if possible,

@znull You can also fix the detection issue by building with ./configure --disable-ccid-driver, in which case you won't need the disable-ccid setting anymore.

@ikloecker Sorry for not being clear, I was not aware different operations have different behaviors in regard to entering / caching the PIN.

It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.

I just wanted to chime in that I've had exactly the same experience as @lbogdan: gnupg 2.3 stopped recognizing my yubikey entirely on MacOS until the T5415 workaround (disable-ccid). After that, pin caching was broken until I applied his patch to call-scd.c:548, which makes it work as before. Without these two changes the experience with gnupg 2.3 is degraded relative to 2.2.

So I did a bit more reading on smartcard PIN caching, and took a better look at the debug logging of gnupg 2.2, and learned that, indeed, the PIN is cached by the card and not by any one gnupg component.

I am testing with rGccfb5e0a7dc6: scd: Use SCardStatus for pcsc_get_status. on GNU/Linux.

Yes, I already linked to T5415, but that breaks YubiKey completely, and I fixed it with disable-ccid.

The pincache is actually not what you think it is. It is only used to allow switching between different application on a Yubikey which reqieres a new VERIFY command after switching back to the first application the card. What you feel as caching is the state of the card, which usually keeps its verification state until the card is powered down.