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):

Everything mentioned above was translated and is now shown that way in all three languages.

I would keep the "create group", too.

In T7515#198012, @alexk wrote:

Regarding the suggest list I would change the following:
but keep:

• Enable/Disable Certificate

Regarding the suggest list I would change the following:

Fixed.

In T7515#197774, @TobiasFella wrote:

I'd suggest removing:

I'd suggest removing:

If a single OpenPGP certificate is updated then we now show the same detailed information for the update from WKD as for the update from a keyserver, i.e. if the certificate didn't change via WKD then we say so.

I think there's some confusion.

changed the workboard to gpd5x as this is still the case in Gpg4win 5.0-Beta versions.

Gpg4win-5.0.0-beta32
Works!

Gpg4win-5.0.0-beta32:
The remaining attempts are listed:

You need to be asked this question when you restore the backup of all of your keys or when you migrate all your secret keys to a new computer.

The situation seems to be even more complicated: If I click "yes" or "no" in this dialog, I *do* get asked for all certificates that are being imported. If I click "Cancel", no more dialogs show up.

Tested locally:

• Build the Docker image for building the AppImage (using the archived CentOS 7 packages).
• Build an AppImage for Gpg4win 4.4 with the unsplit gpgme repo.
• Build an AppImage for Gpg4win 4.4 with the split gpgme repos (T7262).

I'm not sure what Kleopatra should do differently. Kleopatra relies on the error messages provided by gpgme which in turn relies on gpg's status messages.

For Gpg4win 4.4.0:
Encryption: ~2:35
Decryption: ~0:44

To make the test complete for VSD, here the times for decryption (and verification) of the 3G file from above:

• VSD 3.2.4: ~3:36
• VSD 3.3.0: ~2:20
• command line: ~2:30 (maybe the bit slower than in Kleo is because this was done in a shared folder of the host system instead of on the c: partition)

The cli was done in both tests with the gpg version from VSD 3.3.0

FWIW, If a fix is really required for gnupg this will be done for gnupg26 and not for gnupg22. However, it is mostly a kleopatra issue.

Tested encryption (+ signature) via Kleopatra with a 3 GB file (random data) with:

• VSD 3.2.4: ~ 5:20
• VSD 3.3.0: ~ 4:25
• command line; ~4:25