Hm, "Names for the certificate" seems wrong to me. Shouldn't it better be "Names in the User IDs [of this certificate]"? I would leave of the part in [] as redundant. Likewise for the mail addresses.

Thinking about this some more, i came up with some more ways of showing some nice-to-have information in the tooltips:

works with VS-Desktop-3.2.94.481-Beta

works in VS-Desktop-3.2.94.481-Beta. The "Trust Root Certificate" is no longer offered in the context menu.

works in VS-Desktop-3.2.94.481-Beta

"Tested" with VSD-beta-478, looks as expected

works with VSD-beta-478

Works fine in VSD-beta-478

https://invent.kde.org/pim/kleopatra/-/merge_requests/355 makes both components use the same tooltips; we can then change both when we decide on what exactly to show in the tooltips in general

Yeah, I guess we can word this a bit less spec-like. It has more or less the same purpose as an admin PIN except that it's a 128 (?) bit key. And, if I understand correctly, it can also be used by the (admin) user to make sure they are talking to the correct card (if all cards are provisioned with unique keys). Kleopatra automatically tries to authenticate with the standard key so that we never see the prompt for the key unless we have changed it.

The additional changes were also backported for VSD 3.3

https://invent.kde.org/pim/libkleo/-/merge_requests/178

Backported for VSD 3.3

There's a different (but very similar) bug here for RSA keys; fixed in https://invent.kde.org/pim/libkleo/-/merge_requests/177

Maybe the title should be "Password - Kleopatra" (or similar) if the operation was triggered by Kleopatra.

We noticed in the above mentioned ticket, that this needs to be backported

as far as I understand both the Gtk and Qt implementation are using pinentry_get_title which does the /proc stuff, but this is only on Linux. On Windows, pinentry_get_title will return the value set in pinentry_init, in our case pineentry-qt or pineentry-qt5.

Check out the GTK version which scans /proc for the process to find the command line. Very handy for ssh sessions.

I can still reproduce the issue with VSD beta 478

Backported for VSD 3.3

Backported for VSD 3.3

Let's backport this for VSD 3.3 even if https://dev.gnupg.org/T7227#195685 is just a cosmetic issue. The first impression counts.

Apart from checking the gpgme logs to see if validation is enabled for the key listing this can be tested indirectly by verifying that the Status column isn't too narrow after generating a new certificate in an empty keyring in a VSD version (see https://dev.gnupg.org/T7227#195685).

The changes hat to be reverted, a working solution is planned for later

(ignore the last commit, I assigned the wrong task to it)

I'm not sure what we need for the clipboard that's not already in the SignEncryptWidget. I think the SignEncryptFilesDialog mostly adds functionality for the file handling. It might make more sense to try to share code that's implemented for the Notepad and then wrap this in a simple dialog.

In T7362#195689, @alexk wrote:

Yes, automatic scanning of the clipboard is not good. I withdraw the idea.

I think then we could also include this idea: https://dev.gnupg.org/T5006#195230
And thereby show this information for notepad imports, too

If we're looking at changing this workflow, we could also consider how those dialogs (especially the "Certificate Import Result") dialog relate to the "Imported Certificates" tab - maybe we can find a way of showing both the relevant contents of the tab and the dialog in a unified view and then no longer need the dialog

All changes proposed here have been implemented. I do plan more changes, but will put them in separate tickets

Yes, automatic scanning of the clipboard is not good. I withdraw the idea.

Maybe we could join the two dialogs, i.e. add the additional text and the Certify button to the import result window.

On the other hand might 2 pop up windows after an import be annoying…
Although the second window has a "do not show again" option.
Any suggestions?

Additionally permanently watching the clipboard for changes can cause some password managers to detect an "attack". As it is discoverable which application accesses the clipboard on windows we had the case where a password manager would not work when Kleopatras clipboard watcher was running. T6642

I think we have to use multiple different texts instead of assuming that we can use something general as "Detailed import results from %1" which fits all cases in all languages.

My comment referred exclusively to Tobias's "In the future [...]" comment.