The order of states is "expired", "revoked", "disabled", "invalid", "certified", "not certified". Since we show only one state we need to define an order. I guess it would make sense to give "disabled" the highest priority. (I also think that "revoked" should have higher priority than "expired".)

Found a workaround for me. I thought that to only set gitrep if it is not set an ":=" would be required but as other variables in there were also assigned by a single equal sign, I tried to set it on the command line, too and this worked.

Sure! I agree. But my commit did not change that, it only changed that if it that preferable source directory is not at the expected place that it falls back to a remote connection. Since this is also not done in release builds etc. I don't see the harm. And it makes it easier to build GnuPG I think it is weird that users need to modify the script for a git build, this is also not documented. Or a manually reviewed source tree setup under ~/s . But the maintainer could have such a setup and so that setup is preferred! So nothing has been changed for the maintainer.

This is how it looked before (VSD 3.2.2):

In T7089#188733, @ebo wrote:

What I see is: If the status of a certificate is "certified" or "not certified" before disabling it, then Kleo shows "disabled" in the User-ID column. If it was "revoked" or "expired", those are not changed. The same is true for the "Status" info in the details.
Is this distinction on purpose? What is the reason?

Closing.

Well, now it does not occur for me any more, either. Ok, I'm setting this to resolved, this was most likely a situation where Kleopatra could not write to the kleopatrastaterc (in %APPDATA%\kleopatra\) for some reason. This would then be a more general issue, anyhow, for which we need another ticket if we can reproduce this.

I got confused in the various tests and mixed up the Qt6 test on normal Windows 10 with the Qt5 test. In the Qt6 case there are still issues, but that might be explained by packaging still. But for this we have less urgency.

The only change i remember and can find regarding that, is, that for the initial keylisting we disabled the check using the context flag T6261: Kleopatra / QGPGME: Use --no-auto-check-trustdb for initial keylisting since we suspected that this had something to do with reports that the initial keylisting either locked up or was very slow. At the least the goal was that by no auto check trustdb on the initial keylisting it would make it behave more consistently from start to start. But I am pretty sure that you told at least me, that Kleopatra should not try to explicitly do trustdb checks and try to manage that since gnupg takes care of this internally.

That's the way it works today in some organizations:
If users can't delete their key they are requested to ask their GnuPG admin, they actually do so and the admin does help.

I'd be in favor of keeping the UI and just fixing the most significant bugs it has.

with Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41):

iirc, we once disabled the trustdb check because it was run for each imported certificate which took long and was superfluous die to changes introduced by the next certificates. GPGME has a "no-auto-check-trustdb" flag to allow for this.
See T6261

@TobiasFella: This is on purpose: The key might be expired because the user does not have the primary address anymore and thus it makes no sense to show the name. Anyway the listing of the name is more a convenience thing and it might be better if the frontend takes it from its own cache. But it is pretty old code and things and ideas may have changed meanwhile.

can't reproduce either

I think that this would be more like something for a "Task" in Kleopatra and not for a job in GPGME. As a job usually is only one operation and having a single job do two operations is different from the rest of the API. So I would be against it. A signEncryptJob is IMO something that should be reserved for a time when GPGSM supports gpgsm -se

We had discussed this several times in the past as this is similar for files. Like you could do an opaque signing and encrypt for files, the same you can do it for text here. But as I remember it the end result was mostly that since the proper solution would be for GnuPG to support that T2435: gpgsm combined sign and encrypt it should be done in GnuPG proper. And we really did not have any real usecase of S/MIME file and text encryption since S/MIME was even more then OpenPGP about Mails for the Gpg4win users.

I did what you did, didn't even need to restart Kleopatra.

I cannot reproduce this with Version 3.2.2.2405000+git20240712T143635~6033869e1. I open the Details window, go to Subkeys, right-click table header, select Keygrip, close Details window, open it again, go to Subkeys, Keygrip column is still shown. Even after restarting Kleopatra.

With Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41) II can add a keygrip column to the subkey details. But if I close the details window and open it again, the column are no longer selected.

The easiest solution would be a setting for gnupg. Then Kleopatra would just error out. But, as Andre rightfully points out, people will work around this restriction. Users are incredibly creative.

Just to clarify: I didn't say that we should remove the coloring/font style of certificates. I just said that I vote for removing the UI for changing the colors and font style.

The data looks garbled:

Since Kleopatra does not suppress the pinentry prompts think there is even one additional question at least for S/MIME. So it asks you once from Kleopatra and then you are asked by GnuPG.
AFAIR we had discussed this in the past and also came up with the Idea that the user should type in DELETE. That dialog should then come from GnuPG I think so that it is the same.

gpg makes it pretty hard to delete a secret key; thus having a (user settable) option in Kleopatra makes a lot of sense to me.

No. To solve that problem we have the revocation certificates autogenerated in the GnuPG home folder and which are kept of course when a user deletes their key.

Mh, no, on the other hand the style is useful in the "All certificates view" to make distinctions based on multiple parameters. "Like trusted S/MIME root certificate" and it is useful to see that right away instead of using the filters. So my vote would be to clean it up, but keep it in general.

Experiences from customers are that people create their certificate, upload it to a server. Then they notice a mistake in their name and delete the whole cert and upload the new one. Now there are two certificates on the server. This is only one example of what can go wrong. Admins want this not to happen and that's the reason for this feature. More warnings will probably not solve the problem.

Hard to decide as we have no data how much it is used. :-/ But I tend to agree here. We should not loose sight of the fact that Kleopatra should be more of a diagnostic tool and provide all the information a user might need to solve their issues with signing, verification, encryption and decryption. Kleopatra is not something a user uses so often that they play around with appearance or so like they maybe would in a MUA. Certificate management is just an unwelcome side effect required for crypto. But users do not want to do certificate management for its own sake.

I vote for removing the UI for configuring the appearance of the certificate categories completely from Kleopatra. This would solve all usability problems in an instant. People who want to go crazy with colors can edit the rc file.

You could use colors, fonts, icons to mark any certificate you want instead of having to use tags and filter by them. You could even put their company logo on certificates of your communication partners.

As it was a fresh install of a gpg4win test version I used: yes, common.conf was not only supposed to be there, it is and keyboxd.exe is shown in the task manager.
But I think it not only needs to be solved for keyboxd, as our VSD customers don't have that.

In T7212#188683, @ebo wrote:

We might also consider going all out and allowing a configurable appearance on a per certificate level. Then this feature would see an increase in use for sure. But it should work without issues, in that case, as then people will notice them…

From the support angle, the worst of these issues is that the default will not be restored for VS-NfD. But then: nobody has inquired about that yet…

The high-contrast modes disable all colors, but for normal dark modes we might have a problem with some of the predefined colors.

Uhm this is a task I have with High priority. I do not know what to do here or what it is really about. -> Invalid.

Yes, this is all something that is ugly. The VS-NfD colorization was done by justus winter back then since I fell sick and it was one of his first and only tasks in Kleopatra. So it is normal I think if that is implemented differently then other things. And in general the whole appearence configuration is I think rarely used. To me it always felt like a "We add it because we can." feature. But also with this mix of filters defined in a preinstalled libkleopatrarc and additionally hardcoded filters it is all strange.
Well colors and so on should be changeable for accessibility of course.

Wouldn't this usecase be better solved if we could highlight trusted-keys in the keylist better? I mean not trusted-keys as in "this key has full trust" but this key is one of 1-10 (In real life the most we saw was 5) which is configured as a TrustedKey

TrustedKey1
The value specifies a fixed trust root (trusted-key). If more than one trust root is required, the entries TrustedKey2, TrustedKey3, TrustedKey4, TrustedKey5 may also be used. Take care to specify the 40 hex-digit fingerprint of those trusted keys.

The problem here is that Kleopatra could do that of course, e.g. after importing a file. But this has to be done by the GnuPG system to handle all the automatic cases etc.
I leave this up for triage, since I am not sure if this is a bug, or a feature request. @ebo I believe you said to me that you tested this with keyboxd? As my answer would have been that keyboxd would be required for a proper solution to this.