I changed the title of the issue to make it about adding the warning. I also think that is a good idea to avoid confusion / accidents.

I disagree. Unless customers explicitly request it users should be able to trust root certificates manually. I do not see much difference between this and allowing users to certify their own certificates.
This can be required when a user wants to encrypt something to an unknown certificate, regardless of VS-NfD or not.

Settings -> Configure Groups.

It seems that you are missing the step "Create a new file called gpgconf.ctl in the folder Gpg4win_Portable/bin."

It might be related to the GPGME test failure we had related to that. But I thought this was fixed in GnuPG.

A finding has been that the icon theme switch is not detected at runtime. It would be nice if we could add this, especially if customers explicitly test the support for high contrast modes.

In rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed#76893, @sandro wrote:

I am wondering why the global configs are not for all config options and for all of the various config files. That would make things for us and in general a lot easier. Also that the pinentry-program options was only for debugging was not obvious to us but we might continue to use it to avoid unnecessary wrappers around or symlinks.

Since I have closed T6377 which had high priority I am assigning this issue the same prio. Which I also think is appropriate.

I thought about this related to T6386 and I now agree with @ikloecker KEYTOCARD in SCD may not "move" the key. Otherwise it would be impossible to easily transfer a key to multiple smartcards. Since werner agreed in T6486 that this is a Bug and Unintended it can be closed as a duplicate as we do not need to further discuss this.

I have closed T4699 as a duplicate of this, even though T4699 was about simplification but IMO this is the same underlying problem.

I am downgrading this to wishlist. Even though I had worked on this a lot the regression risk is probably too high to fix this before GpgOL becomes obsolete.

I am closing this as a duplicate of T6117 even though it is not really a duplicate. But for me it does not make sense to keep this as a different issue because simplifying the dialog is directly related to making it more accessible.

Well it makes sense to me in that KEYTOCARD explicitly is not documented but the semantics between keytocard in edit key and KEYTOCARD in agent should be the same IMO. As you can imagine I am also not a fan of the fact that GnuPG changed behavior here, but the "keep / delete" is even with GnuPG 2.3 not really an option as GnuPG might replace the real key with the stub depending on how it is called anyhow. So this is dangerous for us to "suggest" from the UI that the key will be kept and then it might be removed without actions by Kleopatra. So this must be changed.

Oh sorry I only saw this now. We have "gpgme_set_offline" for this use case which disables CRL checks in the S/MIME case. It is more general because it also disables OCSP for example and might disable more online actions like fetching chain certificates etc.

So as I understand this:

Oh this issue was in the wrong project. Related to T5836

Oh, yes this makes sense in the copy/delete path of utils/path-helper.cpp Kleo::moveDir on Windows src and dest are usually on the same device so this might not have been noticed as much by our users as then it is just a rename.

I have seen that the rule is honoring the exclusions of Microsoft Defender but I do not know if one would need to exclude gpgol.dll or the gpgolconfig.exe / gpg.exe in this case. https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide#microsoft-defender-antivirus-exclusions-and-asr-rules

@werner I saw the call in _gpgme_set_engine_info at line 452 https://dev.gnupg.org/source/gpgme/browse/master/src/engine.c$452 which I think leads down to _gpgme_get_program_version in version.c which does a spawn and uses no cache.

In T6369#167642, @werner wrote:

The context cloning should not be that expensive compared to invoking gpg. Thus let us first see how to speed up this in the common case.

Output of --show-configs should also be added as a button or directly visible when the selftest of Kleopatra fails.

For testing the old version, did you use GNU Tar with Kleopatra or changed the configuration to use gpgtar?

As discussed with Werner, the initial default will be changed "guessed" in GPGME to avoid code duplication between libkleo and GPGME.

I am adding gpgcom, as a tag, the first minimal task would be to create such a page with the debug output from gpgconf -X with options to copy / or save them to a file. Not sure if that should be a subtask, because on the other hand this would be a start of this "Debug Tab"

I edited this task a bit: For compression we have T6332
For Archives passed to Gpgtar we have: T6342

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.

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.

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.

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.

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.

Commited this state with revision 1642162

This should really be in the next release.

Another thing I have noticed when turning qt debug output on is that the qt windows platformsupport fontdatabase logs over a a timespan of over two seconds that it is adding fonts to its database.

Some timings, timed with procmon and not by decorating the calls in the code. Just looking at was process does.

Currently the first call to QGpgMENewCryptoConfig::reloadConfiguration happens in the GpgSM self test. Funnily enough the selftest for gpg just returns true when the empty constructors of the cryptoconfig are called. The first component load is GpgSM.

Discussed with werner is for Wontfix as this is not really the AppImage way to do things. As you also seem to tend this way I slightly agree. I still would find it nice to have but If we have a real demand for that we can document or support people to do this.

I am changing the priority here to high as the parent task has high prio. Maybe we should close this as a duplicate of T5478