Release quite some time ago.

Great! But as mentioned I would like to have a setting in Kleo to explicitly disable compression, GPGME_ENCRYPT_NO_COMPRESS. But that is a different task.

The compression check currently detects bzip2, gzip, zip, pkzip, and PDF. This also covers common document formats like odt and docx. We may add some more detection in the future. However, for large files you usually know their type and thus you better use "-z0" for already compressed data or "-z-1" if you want to force compression (may be for PDFs which often can be a shrinked to 80% or so).

Sorry, but we can't check all parameters. Why only check that one and not the others or invalid values for ctx. You may do such checks in an interactive environment but not for a general library.

So here is a redacted CLI-dump of the exact sequence I'm describing in my post. This is with untweaked keys and gpg 2.2.40 and a factory-reset yubikey.

The timestamp problem may be fixed by moving the line

File ${prefix}/share/icons/breeze/icon-theme.cache

(and any other lines installing an icon-theme.cache) at the end of inst-breeze-icons.nsi (or the corresponding inst-*.nsi file).

I just learned that

Qt will make use of GTK's icon-theme.cache if present to speed up the lookup.

https://doc.qt.io/qt-5/qicon.html#fromTheme

So on Linux, this looks quite differently.

I would like to take this on myself by creating a gpgversioninfo class which will have signal / slot based API for both the SWDB Query and the version checks, both currently delay the startup too much.

So in case this was not clear... What I'm describing is very similar to the original description, but it is "inverted" - the untweaked key works flawlessly (import and decryption) except for keytocard. And the tweaked key can't be imported - either "Bad Secret Key" or asking for passphrase.

I am somehwat confused, my symantec system got faster. But there are some things like "Symantec Insight" which will whitelist often used files and applications, also signed files might get preferred treatment. I tried to get this slower by disabling the "Insight" and changing the "Bloodhound behavior" to agressive... So timings might not be comparable. I should probably do tests ohne without restarting my systems for a good comparison.

@onickolay Yes, I have. I have used --check-cv25519-bits and it said that it needs patching. I then did --fix-cv25519-bits and exported the key. Looking at the CV25519 private-key bytes produced by my code and by RNP, I confirmed that they did the exact same transformation.
When trying to re-import the exported key into gpg, I got the "Bad Secret Key" error again

@bigmomma Just for a quick check - did you try to use RNP's CLI command --edit-key --fix-cv25519-bits, as it's not clear from the message?

Hi! I would like to chime in on this issue as I am having some weird problems with a CV25519 sub-key and after stumbling upon this thread, I think it is related to this.
Unfortunately, I can't post the key material here, because it is my actual encryption private-key.

Yes I am an admin on the https://pypi.org/project/gpg/ package.

Commited with revision 1642622.

I am closing this now, as we now should have complete kleopatra translation and can just move one of them to testing.

This can be easily tested using

No more logs. My understaning is that the pypi ownershipof the project has been transferred to @bernhard

Instead of using --enable-special-filenames and a separate FD the list of files is now passed to gpgtar's stdin. Similarly, we read from gpgtar's stderr instead of using a separate --logger-fd.

I am pretty sure that this was related to issues we found when analyzing another crash / hang with Kleopatra. In T5478 we are currently reworking how we handle archives completely. This will fix this issue, too.

I am pretty sure that this was the issue we had analyzed with QProcess. Where the fix will be T5478 that will rework how Kleo handles archives altogether.

I am very sure that this is resolved and we support that in Kleopatra.

Thank you for the patch.