i see two forms of an initial resolution here: one is to have set_compliance_option always explicitly set opt.def_newkey_algo. The other is to check opt.compliance in get_default_pubkey_algo.

Thanks for the followup. As a downstream maintainer, it would help me a lot to know why this won't be fixed for 2.4. Do you forsee a specific problem with it? Does the subtle change in semantics of previously unspecified combinations/permutations of options represent something you're trying to avoid on the stable release channel? Are there bugs that users should be worried about?

Gpg4win-5.0.0-beta32
Works!

Gpg4win-5.0.0-beta32:
The remaining attempts are listed:

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.

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 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 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 includes 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