ok. For the tooltip I would now favor the same addition to all current tool tips where it applies:
"(w/o disabled ones)", e.g. "All certificates (except disabled ones)".

I would exclude them.

What about all other filters? For example "Not Certified", "Not Fully Certified", "My Own", "OpenPGP"? Should the disabled certificates also be excluded for those filters?

ok, discussed this with Werner and Alexander, result was:

Setting to Testing and WiP to reflect status of the subtasks and to get it removed from the Open Tasks list.

This was implemented by Tobias

Given that we backported it to gnupg22 we should go ahead and implement that flag. For example: if the flag is set for any root CA we will show compliance only if that flag is set for the specific root CA. This way we can introduce this feature w/o too much backward incompatibility. We could also hide the feature behind a compatibility flag. There is no reason why we should not add the de-vs trustlist flag to our vsd configuraion files, right away.

This has now been implemented for gnupg26 for public key encryption. However, symmetric key encryption, a man page, and the gpgme support are missing right now.

In T4060#190972, @werner wrote:

We need a way to pass --known-notation to gpgme_op_verify

We need a way to pass --known-notation to gpgme_op_verify

So we need a way to launch scdaemon via userv and make sure that the scdaemon user gives proper permissions to its socket file. gpg-agent also nees to check for a proper version of scdaemon and gpgme needs to be aware of this as well (if it want to directly connect to scdaemon).

Also added a new gpgme context flag "proc-all-sigs" and a --porc-all-sigs option to gpgme's run-verify.c tool.

The new option `--proc-all-sigs' will be available in 2.5.1, 2.4.6, and 2.2.45.

I made a ticket on bugzilla with ready-made tests for S/MIME, but on close inspection a different structure appears for S/MIME and another for qualified signature (openssl could not verify token extracted from CAdES-BASELINE-T signature). However, these tests can be very useful.

What we can do is to provide a warning if a pubring.kbx or pubring.gpg still exists when use-keyboxd is enabled. And option to silence this warning.

Backported for VSD 3.3

Well, backup and restore oddity. I don't think that that we can have a full solution here unless we provide dedicated backup and restore scripts.

This works now.

The additional changes have been backported for VSD 3.3

Backported for VSD 3.3

I added some comments to the commit. But

• Rename to "GnuPG Configuration Dump"
• Change file extension to .txt
• Add Close button
• Set window title

tested with Version VS-Desktop-3.2.93.32-Beta

works

Texts are improved, checked with Gpg4win Beta-41

A better solution might be to use categories to have that element "this message will be signed / this message will be encrypted" above the edit window. But what I find more important and so much more a high priority is that in cases we have a failure saving the draft info flags an error message should come up. This happened for a customer and in the logs I could see that MAPI returned an error. the button was not toggled in this case but the mail also was not marked for encryption. T7144 is the task for that so I'd suggest to start with that one.

In gpgoladdin:

Changing the icon is unusual and does not match a native look and feel in Outlook where toggle icons are there for a reason, to be toggled or not. This is also the way how Outlooks native encrypt & sign works and Microsoft will probably have thought about this a bit.

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

BTW, gpgme does not yet use --quick-set-ownertrust which can also be used to set the disabled flag. We should replace the interactor by the new command. See rG21f7ad563d for the new command.

For the certificate list it might make sense to have column-specific tool tips, e.g. to give details on "not certified" in the "User IDs" column. For the fingerprint column (just to pick one example) a tool tip makes little sense.

The latest changes have been backported for VSD 3.3.

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".)

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?

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.

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.

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

can't reproduce either

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.

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.

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.

I think we can close this as Wontfix since it is our opinion to wont fix this issue. If there should be more prevetion of accidents it would probably be better to have the user type in "DELETE" or "YES". Anything else then another click confirming a popup. Since this will just be clicked away through muscle memory. This came up again in T7211: Kleopatra: configuration option to prohibit deletion of certificate with secret key

In MMO Games this is usually handled that a player either has to type in "DELETE" or type in the Characters name to delete the character. At least in the last games I played.