The checksum part for this was mentioned only in relation to T6470

Why? The idea is that someone might trick you by having printed out "Andre Heinecke <aheinecke@gnupg.com> 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1" Then adding the ID "Ingo ...." and sneakily adding that to the .krgp.

I recently had a workshop with a customer that shared the same secret key inside her organization of about >1000 users and even handed it out to external users to avoid having any hassle with public key management. They did not have the highest security requirements and were mostly concerned about transport encryption.

This can be a fixed validity period of the certifications. So like 3 years. Even if the user has set the certificate to be valid for only one year the user could then extend it in my opinion to the full 3 years before the certification loses the validity.

@dvratil I think the message has changed a bit with recent versions of the WKS server. Or is this maybe in a plugin that might not be installed on some distributions? At least when alexk tried it it was not processed on a fairly recent ArchLinux but he had such issues like plugin for crypto settings in KAdressbook not installed etc. so it might just be that. I can test this again but its probably best if we get you a test mail address with a forward for gnupg.org (which has WKS)

A starting point for this could be:

Werner mentioned that the keyword "qual" can also be used like the "relax" keyword can also be used in the global trustlist.txt

Eva this is a bit related to the certification documentation and we talked about this last week.

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.