Has now been backported to be released with 2.2.53

Make all table column headings accessible (see Update 2025-10-27).

Fixed and backported for VSD 3.4.

Okay, then I set the ticket to Testing.

Your fix is okay.

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

This ticket is only for ignoring the autoencryptUntrusted setting. For the gpgolconfig.exe part see T8090

@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 */

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.

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

I was told to only fix this in the German translation, as otherwise all other translations would have to be updated.
I'll push the translations shortly.

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.

a) Here's a log anyway (ignore it, if decryption does always work):

@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.

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

checked with vsd 3.3.5: no change

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

We'll go with solution no 2 (which is in effect the same as no 1 anyway)

I misunderstood this, the mail can be forwarded with attachment if you first deselect the mail and then select it again. So the workaround is OK.

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.

a) "Prefer S/MIME" only applies to encryption, not decryption. If you do not want to decrypt with GpgOL you have to disable S/MIME in GpgOL.

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

@mmontkowski, use this as string:

For now I'll commit the following German translations, fixing spelling plus other slight changes:

We need to test the current state

Fixed and backported for VSD 3.4

Backported for VSD 3.4

I have split out the "Tab navigation in the Smartcard Dialog is broken" issue because it's unrelated to this ticket: T8051: Kleopatra: Tab navigation in smartcard table is broken

Backported for VSD 3.4

I think this is a very good idea. Go ahead an backport, I'll change the ticket description accordingly.

We need to retest this with vsd34 as @ikloecker backported some tab related things after the 3.3.4 release.

Backported for VSD 3.4

I'll wait for feedback before I backport this.