Note: In vsd it must be restricted to the bp algorithms then

If the user clicks the "No, others also use this key" button they get the following dialog

@werner: Shall we backport the fix to the gpgme-1.24-branch or do we just add a patch to gpg4win's gpg4win-4-branch and/or vsd-3.3-branch?

I have verified (by locally applying the change to a Gpg4win 4 build) that ifdef'ing-out the above hack for Windows builds fixes the display issue.

The capping of the date seems to be caused by this workaround/hack in gpgme's _gpgme_parse_timestamp

/* Fixme: We would better use a configure test to see whether
   mktime can handle dates beyond 2038. */
if (sizeof (time_t) <= 4 && year >= 2038)
  return (time_t)2145914603; /* 2037-12-31 23:23:23 */

Now an expired signature with certified key is reported like this:

It looks like we get a specific "Invalid public key algorithm" error from gpgme so that we can add helpful information with likely reasons to the error message.

The blue Kleopatra icon is now used for the Windows builds of Gpg4win and GPD and for the corresponding AppImages.

I might add that we recently had a customer support contact where they had that error and asked how they could make using their S/MIME certificates work.

Backported for VSD 3.4

Fixed. Kleopatra now looks for programs given as plain name (i.e. without any path) first in the GnuPG installation path (as reported by gpgme) and then next to the kleopatra executable. If the program is found at neither location it is run as-is.

For "expired signature with certified key" I believe green with check mark is a too positive. Should be a warning, too.

The text is exactly as discussed and I'm OK with the layout, too.

Is this wording / layout okay?

The display in Okular is independent from Kleopatra, so dropping it in Kleopatra should be fine.
If a QES certificate is available, Okular should highlight and add a filter for them (which is currently not working, see T6632: Okular: Highlight / preselect "nonRepudiation" certificates for qualified signatures)

I currently have a slight preference to drop bold and go with normal font. Werner would be ok with that, too.

@svuorela said, QES certs shouldn't be required to be on a smartcard.

Using an icon for QES certificates isn't that easy because we use an icon for smartcard certificates and any list item can have at most one icon. Moreover, QES certificates are very like stored on a smartcard (isn't that even a requirement?), i.e. an icon clash is basically guaranteed.

Additionally, the de-vs-compliance filters are no longer show in non-compliant installations like Gpg4win.

In T6632: Okular: Highlight / preselect "nonRepudiation" certificates for qualified signatures I had the impression, that some hint is useful for signing operations. Probably not so much in general.

Done and backported for VSD 3.4

Highlighting QES is mostly useful for Okular, I guess.
Maybe use a symbol with a pen? That should be self-explanatory.

We decided to still use the term "Valid" (with description/tooltip "Certificates that are neither expired nor revoked (except disabled ones)"). This matches the use of the term "invalid" for expired and revoked certificates as in "Certificates that are invalid because they have expired (except disabled ones)".

This overloading of "bold" for "my certificates", "qualified certificates" and "trusted root certificates" seems to exist since two decades. I stopped digging into ancient history at the commit that added the hard-coded default filters.

Take care: Too many attributes (color, font) are bad style.

Well, the qual flag should only be set for CAs dedicated to certifying QES certificates. And those should by definition be signature certificates only, afaik.

Backported for VSD 3.4

Done. Example (with default text in English and German translation):

[Welcome]
welcome-text[$i]=<h2>Hello, World!</h2>
welcome-text[$i][de]=<h2>Hallo, Welt!</h2>

Backported for VSD 3.4

This is actually a (known) bug in gpg, i.e. gpg --delete-secret-and-public-key PRIMARY_KEY_FPR only deletes the public key for keys without primary secret key.

As a first step we should make the diagnostics output available everywhere via a button like in T6268: Kleopatra: Diagnostic output when importing keys

We have this now for VSD, there is (currently) no neccessitiy für Ggp4win

As there are there are no user requests for this, we'll close this

meanwhile we do not show a percentage any more so this is resolved

My actual plan is to rework the imp[ort/export of secret keys to gpg-agent. Right now gpg-agent has knowledge of OpenPGP for import/export. This is not good and the required conversion should be moved to a helper tools for easier testing and to have this out of the gpg-agent process. For Kyber we right now don't use any conversion mut store the secret keys in gpg-agent's native format. Thus the passphrase is not necessary. We need to figure out why we have this problem here.

This ticket is explicitly about Kleopatra included in Gpg4win.

In T8059#212270, @bernhard wrote:

Kleopatra is also run on GNU/Linux Distributions.

Kleopatra is also run on GNU/Linux Distributions.

This is still open. It cannot be tested because Gpg4win still doesn't use KIO::move on Windows (because the above patch has not yet been merged).

I think this is still open (and requires T6537: Make KIO::move work on Windows when moving between different partitions).

While key generation works now with an expiry date up to 2106-02-04, the representation on the command line is a bit ugly.