I tried the same:

I think I haven't been clear enough about the issue for this ticket, sorry about that. My main concern here is that in Kleopatra's Certificate Selection Dialog, the key filters don't filter the keygroups at all, i.e., if i select the "OpenPGP Certificates" filter, a group containing only SMIME keys is still visible.

I'm wondering whether we didn't do this for a reason. Currently, groups are only used in the certificate line edit. Didn't we want to show all groups to give the user the chance to notice a group containing an unsuitable key? If we filter out the group then the user will have a much harder time to find out why the group isn't offered. Things may be different for the key selection combo box which is primarily (or exclusively?) used for the user's own keys without even offering groups.

Looks like
https://bugs.kde.org/buglist.cgi?component=it&product=i18n&resolution=---
is the bug tracker for Italian translations.

Setting the priority to low because that is the task for the KDE translation team. I am not sure how we can interact with the translation team, bug tracker wise. Do they have their own tracker?

As a change in behavior is not possible, we continue with the button solution here: T6984: Kleopatra: Add icon for folder encryption

@TobiasFella Since werner, ebo and ingo will be only talking about the smartcard related issues next week, I think there are plenty of nice jobs here :)

Feel free to fix this

But like it is now one would only go into the subkey view after things start behaving unexpectedly. After all, "I told the program to extend the subkeys", why should I verify if it really did this?
If the box "extend validity for subkeys" could not be checked in case no keys will be extended, I would then go to the subkey details, if I wanted to extend them, too.

I think this currently is fine. You can always go into the subkey view and the the expiry date there for corner cases.

I don't think that we need to show which keys are compliant or not because that is already shown by the VS-NfD compliance status. And then we only have left the case where the keys are expired / revoked so a user could sort by validity to find out which ones are those.

Yes that probably gets lost along the way, where we communicate with scdaemon to generate the key. Needs to be tracked down. Such things can be very confusing to users. Especially if that increases the PIN Retry counter!

Yes I think that some keys must match, e.g. if you filter for S/MIME you only want to see groups where at least one S/MIME certificate is part of the group. Or for expired to see if there are groups with expired certificates in them.

And not using the native Windows dialog isn't an option because people are used to the Windows dialog. I absolutely hate it when some application on Linux doesn't use the KDE dialog but its own dialog because it behaves slightly differently and it doesn't have my bookmarked folders.

We cannot

Switch to gpgtar if folders are involved. In that case "Sign/Encrypt Folder" would no longer be needed.

because we don't know that folders are involved. And I don't think we can hide the folders, so that users cannot select folders and wonder why they are not encrypted, because Microsoft thought it would be a great idea to basically use the Windows Explorer as File Open/Select/Save dialog. And, of course, they won't change this because this would break all existing Windows applications if suddenly folders are returned.

I would like to change the description of this ticket.
Which way do we want to go?

I guess we should put this on the agenda for our next RL meeting.

Regarding https://invent.kde.org/pim/kleopatra/-/merge_requests/106 I cannot login to gitlab right now. Since I have to manually migrate my fdroid apps to the new phone and my 2fa app is one of them. But I agree with everything ingo said there.

As in my test case Kleopatra didn't check the box for "with subkeys" when the extension wouldn't work I propose as minimal solution:

• disable the checkbox if no key would be extended anyway + info why the box is not checkable (via tooltip)

You are (of course) right, gpg -k shows the keys in that order. Which is different from the order shown in the smartcard management view and what gpg-card shows. So lets drop that point for now and maybe discuss this some time in the future.

Additionally I would find it sensible to display the keys always in the order of the keyslots.

Possible fix for testing as patch: https://invent.kde.org/frameworks/kio/-/merge_requests/1540

Just a reminder, this is important for 384 bit keys (see T6379).

The state of the brain is:

Kleopatra behaves as intended (by me). Only subkeys meeting the following conditions are extended together with the primary key:

• skip revoked subkeys which would anyway be ignored by gpg;
• also skip subkeys without explicit expiration because they inherit the primary key's expiration;
• include all subkeys that are not yet expired or that expired around the same time as the primary key

For existing files it does now do the same as when encrypting. Folders were already renamed automatically to avoid overwriting. This hasn't been changed.

Move back to vsd33 Backlog because the changes may have to be merged to a (future) vsd33 branch.

works in Gpg4win-4.3.0-beta571

Changes:

• Decouple creating a backup of the (secret) key from deleting the copy of the (secret) key stored on disk.
• Improve the button texts and the messages to make it clearer that the copy stored on the computer's disk can be deleted.
• Don't ask a second time for confirmation if a backup has been created.
  • If the user has created a backup of the secret key and then chosen to delete the copy on disk then don't annoy them with another request for confirmation. Even if they accidentally chose to delete the copy on disk they can restore it with the backup.
  • If the user hasn't created a backup (that we know of) then we keep requesting confirmation.

@aheinecke For Gpg4win I do not have a suitable test version yet.

Is the problem that another success message is shown after deleting the local copy?

@ebo Is this fixed now?

I'm putting this back to triage because I cannot act on this ticket. There's way too much text and the outcome what should be done is unclear. Either rewrite the description so that it tells the reader concisely what should be changed and how it should be changed. Or, maybe better, create a new ticket referring to the discussion in this ticket and close this ticket.

I don't understand what your comments about the (missing) success window mean. The screenshot that you added to this task is the success window reporting "The key was copied to the card.". It even has the title "Success". As far as I can tell this window is exactly what you describe with

Would it be possible to move the success window to the start? Ideally combine it with the window asking what should be done with the key on disk. Then "copied" would be correct, as the original still exists and we do not need additional code paths for the other combinations.

The problem mentioned in T6095#173465 no longer occurs with the changes made for T6662: Kleopatra: improve useability of group configuration , neither if the Help button is shown nor if the Help button isn't shown.

Regarding T6662#174484, this was already implemented this way. Of course, it still works this way.

It doesn't actually work as expected on X11. There pinentry uses the NET::KeepAbove window flag to make the pinentry window stay on top of Kleopatra.

This is what T6799 this needs to be fixed in general.

All icons that are available in normal/light mode should now also be available in dark mode.

KF6 KWindowSystem has some convenience API to deal with this: https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/136