I had two arguments about using gpg_op_createkey, first it was only available on "recent" gnupg versions. That is obsolete now.
Secondly it required you to add each subkey one after another. With rentering the passphasre. This could lead to error behaviors are was just confusing. But otherwise I am all for it. But I think changing this now is a bit too invasive.

Starting to understand KIO architecture a bit better. We can easily add more protocols if we want to. For now I have just added the file plugin. I tested with moving.

The code for the file Job etc. is definetly in there. I think it somehow tries to intospect supported protocols maybe even through dbus and this fails then. My current expectation is that we need to identify where this happens and then to hardcode some supported jobs / workers etc.

Yes most definetly I am looking it at next

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