I found out, that successful notepad pgp encryption/signature never had an audit log button (it's also like this in gpg4win-4.4.1 and vsd-3.3.4).
So, everything fine here for gpg4win-5.0.2-beta2 @ win11, vsd still needs to be tested.

In T7784#214660, @timegrid wrote:

Just to be sure: The "Show Email" button is still never shown on the notepad, right?

In T7784#214657, @timegrid wrote:

Issues found:

• pgp encrypt/sign does not offer an audit log, the first screenshot in the description ("verschlüsselt und signiert") suggests that this was different before

Also done: The tab order for the close button is now correct.

Note: On gpg4win-5.0.1, there's also no audit log for notepad pgp sign/encrypt. So this is expected?

Looks good to me on gpg4win-5.0.2-beta2 @ win11.

Just to be sure: The "Show Email" button is still never shown on the notepad, right?

In general looks good to me on gpg4win-5.0.2-beta2 @ win11:

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

Looks good to me on parallel install of

1. gpg4win-5.0.2-beta2 @ win11
2. vsd-4.0.0-beta1203 @ win11

Seems to work in principle with gpg4win-5.0.2-beta2 and vsd-4.0.0-beta1203.
I'll wait for a new vsd beta release (with some fixes) for further testing.

with Gpg4win-5.0.2-beta2:

Ok in Gpg4win 5.0.2. (Beta), in German:

config file: Sorry, I got confused, it has to be %APPDATA%\GnuPG VS-Desktop\kleopatrarc in this case (VS-Desktop-4.0.90.1203-Beta), of course. And this one works.
Registry entry SOFTWARE\GnuPG VS-Desktop\Kleopatra\CMS\SaveCSRAsPEM does not work, though. But this is a separate issue, seems all Registry entries do not work in that build.

• config file: According to T7717: Location of qt-application config files %APPDATA%/Gpg4win/kleopatrarc should work.
• registry: According to T5707: Kleopatra: Use windows registry additionally to config files this should be SOFTWARE\Gpg4win\Kleopatra\CMS\SaveCSRAsPEM now

Works with VS-Desktop-4.0.90.1203-Beta when putting this in C:\Program Files\GnuPG VS-Desktop\share\kleopatrarc
CSR is then saved as .pem file with ascii-armored content.

The new German tool tip is shown in Gpg4win 5.0.2 (Beta)

Done and backported for VSD 3.4.

So ok, go ahead Ingo with your plan in https://dev.gnupg.org/T7502#213972

I tend to agree with keeping it short and close to the wording we use for normal public key imports.

Backported for VSD 3.4

We decided to backport to VSD 3.4 because it fixes an accessibility issue.

Backported for VSD 3.4

We decided to backport to VSD 3.4 because it fixes an accessibility issue (wrong tab order).

Backported for VSD 3.4

Done.

How about "Certification includes that you check the fingerprint against a trusted source."? "Means" seems wrong to me. @hej, please comment

ok, lets do this. I'll update the description

I'm fine with just dropping it.

One doesn't even need a global config file to reproduce the duplication.

I'm okay with omitting the list of suggestions for shared secret keys. The person distributing the key should have told the recipients how to import and certify them properly.

Also backported for VSD 3.4.

Now also available in Gpg4win 5.

How about changing the text after sentence two simply to:

Do we agree to drop bolt font for QES certificates?
Will we change this for VSD 3.4?

Backported for VSD 3.4

For all tables where the visible columns can be configured via the context menu of the table header the visible columns can now also be configured via the context menu of the table cells/rows. (The only exception is the result table in the selftest where it doesn't really make sense to change the visible columns. Instead we should disable the context menu of the table header.)

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