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.

I would give this low priority. There is no way to prohibit that except if the user has no deletion rights on the file system. There are already multiple dialogs asking the user to confirm the secret key deletion. A user could by the same logic "Free up some space" in their local home directory and delete %APPDATA%.

ok, works with Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41).

As for renaming "Change Reset Code" to "Set Reset Code", what about "Change PIN" and "Change Admin PIN"? Should they also be renamed? If not, why not? Is there no default reset code? Is there a way to find out whether the reset code has already been set (in which case "change" would be more appropriate than "set")?

It's not tagged vsd33 and I didn't plan to backport this since it depends on other changes (T6787) that are master-only.

we are doing this for the last releases. The list of files can also be found in the repo now in gpg4win.mk.in

Will this be backported? Since the pgpcardwidget otherwise contains strings which are neither in master nor in kf5 I would say so.

Yes sounds good to me. Since we have the ability even in the full list view to filter for "only with secret" certificates. Regarding gpgme_set_sender. Only GpgOL uses this, we only really need it for TOFU I think. To leave that discussion / point out of this issue I created T7199: KMail / Kleopatra: Use gpgme_set_sender to add a hint which UserID was selected for a signature

ok, I like your proposal. To recap:

This behavior of the encrypt-to-others input field is intended. It avoids "Multiple matching certificates or groups found" errors if there is one current (good) certificate and one (or more) old expired certificates for an email address. There's a button to open a dialog listing all certificates so that the user can find a certificate they are missing in the input list's completion list. I think this is an acceptable compromise between making all certificates discoverable (even expired or revoked ones) and offering not too many irrelevant certificates. When the user selects a bad certificate in the selection dialog we should probably show a note that this certificate cannot be used instead of showing "Error: No matching certificates or groups found".

In T7183#188348, @ebo wrote:

I'm not sure if we are talking about the Encrypt-to-self drop-down or the Encrypt for others input fields. On the other hand, I see little reason to treat both differently.

At the moment they are treated differently. In the dropdown for encrypt-to-self no expired certificates are listed. encrypt-to-others does not have a dropdown. You are not able to find an expired Certificate by typing the name. But you can open the certificate list to chose from, where expired certificates are shown and selectable.

I'm not sure if we are talking about the Encrypt-to-self drop-down or the Encrypt for others input fields. On the other hand, I see little reason to treat both differently.

I agree with Ingo and Werner here. In summary

The ticket mentioned in the previous comment is T7190: Kleopatra: wrong claim of update in WKD for keys with no mail address.

Turns out

• the singular instead of plural in the German version is a translation thing and should now be fixed (but is not in the testversion beta35)
• there is another issue muddying the waters regarding search in WKD, for which I will create another ticket

rere 2: I agree as long as the expired certs are order behind regular certs.

Re 2.:

• I think expired user IDs should also be offered. Otherwise, people who forgot to extend the validity of their certificate won't find their certificate. Usability-wise it's better to offer the certificate and show a notice that the selected certificate has expired. I wouldn't differentiate between primary and additional user IDs.

In general, I question the usefulness of the tool tip for the certificate list. The information in the table is already very detailed and for more details there's the details view. Important information that's missing in the table shouldn't be hidden in the tool tip.

is there a keyring/password manager that is not dependent on a desktop environment that the terminal pinentry supports?

Now also done for libksba.

Done.

Done in 3.0.0.

Added in 3.0.0.

Different pinentries provide different options. The curses pinentry does not have that external password manager thingy. Mixing GUI and tty use seems to be a rare case.

The usability challenge does already exist today because Kleopatra allows to encrypt all files separately. Currently, all encrypted files are written to the same output folder. Which is highly problematic if some of the original files have identical names. Encrypting the individual files in-place would avoid the problem of name clashes.

The usability challenge here is what happens if the encryption does not work for some files in between:

Note that the origin stored for the key is for example required if a key is updated by fingerprint. In that case we don't known from which user ID to take the origin.

I updated the certificates of Werner, Andre and you and got as result "The certificates were updated.", i.e. plural, for both, keyserver and WKD. Singular could mean that only updates for one certificate were found.

Looking only at the text used, you get exactly the same messages used for single certificate updates, "The certificate has been updated" or "The certificate was not found.", both in the singular.

Querying WKDs for keys not retrieved via WKD leaks information, i.e. a (fake) WKD could track who is looking for keys. KDE's privacy-by-default policy doesn't allow such a setting to be enabled by default. (In VSD you can enable it for certain customers who don't have a problem with this.)

Note for testing: To reduce the PUK counter to 0 you have to enter a wrong PUK for "Unlock Card". The wrong PUK must have at least 8 characters. Otherwise, gpg-agent will consider the PUK wrong without even asking the smart card so that the smart card doesn't get a chance to reject the PUK and decrease the PUK counter.

And "But "Update certificate" does still not query WKD (not even after restarting Kleopatra.)" seems to happen because the setting "Query certificate directories of providers for all user IDs" wasn't enabled.

I can confirm that Kleopatra reports "The certificate was updated." when updating the certificate werner.koch@gnupg.com although gpgme reports "unchanged: 1" as ImportResult. Kleopatra even reports "The certificate was updated." under WKD for a locally generated test key that's not available via WKD. This should be fixed.

Tested with Gpg4win-4.3.2-beta25:

Tested with Gpg4win-4.3.2-beta25

I've talked to ebo about this and yes she will create subtasks for at least GPGME log an qDebug logging the GnuPG Logs can already disabled in the config so we dont really need it. Currently it looks like this and I find it rather confusing: