I have no idea how to test this aside from the test done in T7146.

In VSD 3.3.0 I can not check with "Rückstellcode" as the error message is now "Falsche PIN".
And the same in the released version Gpg4win 4.4.0.
Seems the gpg version now returns a different string:

No totally new install: I quit Kleopatra, then deleted %APPDATA%\kleopatra\kleopatrastaterc and %APPDATA%\gnupg and restarted Kleopatra. Then I imported the shown test certificate which has no expiry date.

I can't reproduce this. Was this with a fresh install or is it possible that there were existing column widths loaded from a state file?

Checked again with VSD 3.3.0: no error any more. Therefore setting this to resolved, I probably made a mistake the last time.

works as described.

Closing this ticket after creation of two follow up tickets for the remaining issues.

The certificate can also be downloaded from https://www.bsi.bund.de/DE/Service-Navi/Kontakt/smime.html

Remarks:

• This works now on Windows and with the AppImage. This was achieved by customizing the internal application name of Kleopatra: kleopatra-vsd for GnuPG VS-Desktop, kleopatra-gpd for GnuPG Desktop, kleopatra for everything else.
• As a side effect the different flavors of Kleopatra now use different names for the main config file and for the state file, i.e. Gpg4win uses kleopatrarc and kleopatrastaterc, GnuPG VS-Desktop will use kleopatra-vsdrc and kleopatra-vsdstaterc, and GnuPG Desktop will use kleopatra-gpdrc and kleopatra-gpdstaterc.
• The internal application name is also used for config entries retrieved from the registry. That means that for VSD and GPD different registry paths are used in future releases.
• Testing on Windows requires T7040: Make it possible to install GnuPG VSD and GPD in parallel.

Some remarks:

• All Kleopatras use GNUPGHOME/kleopatra for the config files, but they use different names for the main config file and for the state file, i.e. Gpg4win uses kleopatrarc and kleopatrastaterc, GnuPG VS-Desktop will use kleopatra-vsdrc and kleopatra-vsdstaterc, and GnuPG Desktop will use kleopatra-gpdrc and kleopatra-gpdstaterc. That's a side effect of the changes for T7528: Make it possible to run Kleopatra VSD and Kleopatra GPD in parallel where the internal application name is set to kleopatra, kleopatra-vsd or kleopatra-gpd for the different flavors.
• The Kleopatra configuration files are not migrated to the new location. (The group configuration should already have been migrated.)

By the way, this also works for different GNUPGHOME. Tested with a gpgconf.ctl file with content gnupg = gnupg-gpd next to gpgconf.exe.

Kleopatra now writes/reads all config files to/from GNUPGHOME/kleopatra.

VSD 3.3.0:

The button for "Encrypt to others" is gone:

Looks like scdaemon which I experienced today also but without having enabled scdaemon logging.

VSD 3.3.0: The buttons work as soon as the certificates are imported. (Depending on the card this will take some time)

Logs of a recent hang

VSD 3.3.0:

Haven't seen this in a while.

works in VSD 3.3.0:

VSD 3.3.0:

VSD 3.3.0: OK.

ok in VSD 3.3.0, too

Closed after the release of 2.5.4

You have imported a certificate with secret key.

You have imported a certificate with secret key.

Fingerprint: XXX
User ID: ABC

Here are some ideas:

Also, we should not forget the context of the whole dialog in the window. So we get the wording right, especially regarding key / certificate.

Removed in https://invent.kde.org/pim/kleopatra/-/merge_requests/369

In T5780#195277, @ikloecker wrote:

For me the change fixes the problem on Windows. (I haven't checked if there was a problem on Linux/X11, but I have verified that the change also works on Linux/X11.)

We do support "Decrypt & Verify" for multiple files (including the presentation of the status) so that it would be easy to do the same for all files in a folder (question is if this should even be recursive). Digging into the history I found that the desktop file was added shortly before Kleopatra 2.0.0-rc1, but that there wasn't any code for iterating a folder, i.e. this can never have worked.

I can't remember that we ever had support this. It is also not easy to come up with the good way to present the status for all files in a folder. We would need to define a format similar to what sha1sum uses: A list of file with they signature file or so. Note that kleopatra has support for running sha256sum in such a way.

We don't have this exact action on windows, but the normal "Decrypt & Verify" action shows up for folders there (and doesn't work either).

Can now be tested after the release of libassuan 3.0.2 (T6163)

"Exclusive user" sounds a bit odd and could still be misinterpreted. A native speaker would probably say "Are you the sole user of this secret key?“ or (even better and shorter) "Are you the only user of this secret key?"

Background of my "reminder" comment: we were discussing to establish a sane workflow for sharing keys. Which is quite commonly done e.g. for functional mail addresses, but usually people seem to share the whole secret key which is not advisable. We would want people to only share subkeys for that purpose.
It was the case that somebody gets a subkey for such an "offline" primary for the first time which I was thinking of.

Details should be the first action (since it's likely the most often used action by people who don't know about double-click). And I'd move the "destructive actions" to the bottom. And there are way to many separators.

In T7502#198141, @ebo wrote:

Reminder: we have to keep in mind the workflow of the import of secret subkeys. Do we need different behavior conditional on "is primary key present" or not?

Reminder: we have to keep in mind the workflow of the import of secret subkeys. Do we need different behavior conditional on "is primary key present" or not?

With my initial suggestions, modified by:

Another thing (should definitely go into a new ticket if we want to do something regarding this):

Again for Gpg4win 4.4.0, this time with better attention (and definitively encryption only):

Shorter version:

Possible explanation text for the user regarding the background of the question (probably to long):

This is the current (VSD 3.3.0) state for Japanese (with German as fallback):