Works good enough for me

I agree, but can't give this priority because it is more work then it sounds since we need to start from the bottom with dirmngr feedback and then pass this all the way through our layers to kleo.

As ingo pointed out in the main issue, just using an "inactive" color for the validity might be confusing / inacessible.

So the reason this fails is the same as it was back when T3547 was fixed. MoveFile does not work across directories, and even MoveFileEx that supports this for files does not support this for directories.

Can you try on the command line, errors might be more specific there. This can be caused for example by a wrong system clock.

This is not really what the issue here is talking about. This issue was about "merging" multiple keyrings into a single view. If I understand you correctly you want to have matching pubrings and secret key directories for different applications. That is fully covered and what many users do by setting GNUPGHOME through the environment, the --homedir option or the windows registry.

Moved this on the workboard to have a better overview.

Fixed with: 8e258f77114ce0474a2bb6aa1314385e2fb68e15

With the recent commit the old workaround works reliably again.

Mmh, why did this go into its own rc file. I guess its because its in libkleo and not in Kleo itself. I have to check how this works with my registry code. I doubt that this will work out of the box but its important for us that our settings can be set through the windows registry.

I think that you both misunderstand my idea a bit. I would like to present it to you at some point over a Video Call or I have to write the proposal out in some longer form.

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.