You need to be asked this question when you restore the backup of all of your keys or when you migrate all your secret keys to a new computer.

Okay, thanks!

Fixed in master and the new gpgme-1.24-branch. Thus this fix will be in 2.0.0 and 1.24.2

Sorry, this will not be fixed for 2.4.

The situation seems to be even more complicated: If I click "yes" or "no" in this dialog, I *do* get asked for all certificates that are being imported. If I click "Cancel", no more dialogs show up.

Tested locally:

• Build the Docker image for building the AppImage (using the archived CentOS 7 packages).
• Build an AppImage for Gpg4win 4.4 with the unsplit gpgme repo.
• Build an AppImage for Gpg4win 4.4 with the split gpgme repos (T7262).

please prefer the patch here over the one on the mailing list. my followups to the mailing list are not going through due to some kind of intermittent IPv4/IPv6 deliverability issue. Sorry for the confusion.

Thanks for the fix, @werner ! Here's a comparable patch for the 2.4 branch as well, but without the change to de-vs as i think the comment in rGc2ff47d5bcd2953fc2095ef2242af2c7e9cd4420 indicated that you only wanted to rebase de-vs to --gnupg in the 2.5.x series.

I'm not sure what Kleopatra should do differently. Kleopatra relies on the error messages provided by gpgme which in turn relies on gpg's status messages.

I am pretty sure this was my fault: rM62b6c1f16 is the culprit.

@werner Thank you for the response. Is there a nightly build or similar that I can grab from somewhere to see if using the latest master branch solves the issue?

For Gpg4win 4.4.0:
Encryption: ~2:35
Decryption: ~0:44

To make the test complete for VSD, here the times for decryption (and verification) of the 3G file from above:

• VSD 3.2.4: ~3:36
• VSD 3.3.0: ~2:20
• command line: ~2:30 (maybe the bit slower than in Kleo is because this was done in a shared folder of the host system instead of on the c: partition)

The cli was done in both tests with the gpg version from VSD 3.3.0

@gouttegd: Good idea. I did this with the above patches.

FWIW, If a fix is really required for gnupg this will be done for gnupg26 and not for gnupg22. However, it is mostly a kleopatra issue.

Thanks. I applied all 4 patches to master and did one additional change to get --allow-old-cipher-algos straight.

Tested encryption (+ signature) via Kleopatra with a 3 GB file (random data) with:

• VSD 3.2.4: ~ 5:20
• VSD 3.3.0: ~ 4:25
• command line; ~4:25

I never tested the WSL stuff with gpg-agent but I use the standard OpenSSH based ssh server on Windows on a daily base. It is actually part of our release build chain. A recent problem I encountered was fixed in master with rG2469dc5aae and should be backported to 2.4. Might be related to your problem but I need to read your detailed bug report more closely.

Here's all of the above patches squashed into a single patch:

attached here is a series of 4 patches that reinforce that the last --compliance policy option (or equivalent option, like --rfc4880 or --gnupg) supercedes any earlier one.

sorry for the confusion in the initial report -- the policy compliance option is of course --compliance, and not --policy, and i just miswrote it in one line of the description above. I've corrected it now, and all the rest of the report is still as it was.

Ok, then this will not be included in the VSD versions until we switch away from gpg 2.2

That gpg seems to be some other or patched software than the one from gnupg:

21f7ad563d9b was not backported to gnupg 2.2, so this can't be done yet

The commit rC58c11aa8 is the improved version by k-ary exponentiation (while rC6dffd105e2e2 is 1-bit at a time) and using heap.

It's missing a check for the required gpg-2.2 version. I will add that