@werner I added an implementation https://dev.gnupg.org/D622
that matches Linux behavior and avoids the message about secure memory not being supported on Windows. The change is scoped to the pinentry tool and intentionally follows Linux behavior. Does this approach look reasonable to you?

I don't think that we will implement that any time soon. Today we too often require more mlock-able memory than available and in this case Libgcrypt resorts to allocating new memory arenas which are not locked. This is not as worse as one might think: the majro advantage with secmem is that a free() on secmem allocated memory will also wipe that memory. A better solution has always been to use an encrypted swap/paging file. 25 years ago, it was not easy to configure but today there should be no problem and hopefully already the default.

Windows7 has long reached end-of-life. Do not use it unless you have a fully air-gapped system. In this case, continue to use gpg4win 4.4.1 or resort to the command line of 5.0.0 which should still work.

Looks good to me on gpg4win-5.0.0-beta479 @ win11.

Frankly, he OpenSSH support for Windows was experimental and I have never tested it. If it can be confirmed that this really works and is useful, it will be easy to add the opeion to gpgconf.

Frankly, he OpenSSH support for Windows was experimental and I have never tested it. If it can be confirmed that this really works and is useful, it will be easy to add the opeion to gpgconf. Note that the gpgconf option feature handles only a subset of all options on purpose.

Yes, Kleopatra quits again with the beta from yesterday:

Fixed in gpg4win-5.0.0-beta476

Fixed by applying a patch to our version of MinGW. This affected all Qt programs build with Qt 6.10.

With the product-specific standard locations implemented for T7717: Location of qt-application config files it's now longer necessary to customize the application name of Okular. Closing as wontfix.

The new approach has been implemented and backported for VSD 3.4.

New new plan (after discussion on 2025-12-08):

While working on https://dev.gnupg.org/T7962 I realized that https://dev.gnupg.org/T7717#208938 is probably not the best solution for separating the config files of different distributions of Kleopatra, Okular, etc. Changing the application name has many side effects, e.g. it changes the name of the config files, but that's unnecessary because we put the apps' files already in different folders. There are also other side effects that make things complicated (and require many changes in okular). Taking a step back what we need is different folders for VSD, GPD, and Gpg4win (and KDE Okular). And, for Kleopatra, we need different unique service IDs, but let's ignore this for now. That can easily be solved separately. For the different folders it would be sufficient (and maybe even nicer for selective backups) to use something like %(LOCAL)APPDATA%/GnuPG VS-Desktop, etc., as location for all apps' files of VSD/GPD/Gpg4win. Then we wouldn't have to change/patch anything in Okular (or any other Qt apps).

Backported for VSD 3.4

This is now implemented for Gpg4win 5.

For our GnuPG Okular, we should not use the standard file names (okularrc, …) as this would conflict with a regular Okular installation.

Looks good to me on gpg4win-5.0.0-beta413 @ win11

In T7588#207022, @timegrid wrote:

• unselected radio/checkboxes are a bit hard to see and worse to distinguish

In T7588#207022, @timegrid wrote:

• calendar (weekend days: general/selected/hover on dark background)

Tested on gpg4win-5.0.0-beta395 @ win10/win11

Fixed in 1.56.

Tested a little late and on Windows 11 with VS-Desktop-3.3.90.16-Beta (a Beta for VSD 3.3.3):

In T7758#205218, @timegrid wrote:

Note: If i set an invalid path in "Software\\GnuPG:Install Directory"

• the gpgconf -X output does not change
• the self-test Config File 'libkleopatrarc' fails with Error in archive definition tar: 'pack-command-openpgp' empty or not found

In T7758#205217, @timegrid wrote:

This probably can only be tested with signed releases?

Note: If i set an invalid path in "Software\\GnuPG:Install Directory"

• the gpgconf -X output does not change
• the self-test Config File 'libkleopatrarc' fails with Error in archive definition tar: 'pack-command-openpgp' empty or not found

This probably can only be tested with signed releases?

Looks good to me on gpg4win-5.0.0-beta357 @ win10.

Kleopatra from VSD installations should now use gpgv from the GnuPG installed by VSD when verifying the signature of the VERSION file. GPD and Gpg4win installations both use gpgv from the GnuPG installed at the value of the registry key "Software\\GnuPG:Install Directory".

Fixed with new GPGRT_PROCESS_STDIO_NUL flag.

It's intentional that with Gpg4win migration from %LOCALAPPDATA% does not work because %LOCALAPPDATA% is used by VSD (and GPD) but not by any old Gpg4win.

As timegrid has not experienced the older versions himself, he misunderstood this. Ingo's description is correct.
(%LOCALAPPDATA% was the location of kleopatragroupsrc before VSD 3.3.0.)

If we will fix gpgconf using GPGRT_PROCESS_STDIO_NUL, we will need to fix gpg-connect-agent to see if it's NUL or not.

For KF5-based builds this is resolved because the improved heuristic for detecting light high-contrast themes (like "Desert") is used for VSD 3.3 and Gpg4win 4.4.

Ok, it was a missing update (although windows claimed to be up-to-date).
After installing 2025-06 [...] KB5060829 the Microsoft Print to PDF feature is available again and printing also works in Kleopatra/Okular.

It's also the same error in Okular, when a pdf is printed.

Same on gpg4win-4.4.1 @ win11 (here a bit more debugview context)

3	3.503991	8584	kleopatra.exe	org.kde.pim.kleopatra: Paperkey export finished:  0 status:  QProcess::NormalExit
4	3.691599	8584	kleopatra.exe	QPrintDialog: Cannot be used on non-native printers
5	3.691981	8584	kleopatra.exe	QPrintDialog: Cannot be used on non-native printers
6	3.692752	8584	kleopatra.exe	org.kde.pim.kleopatra: Printing aborted.

Works fine here.

I guess, that's ok then, moving this to done.

In T7594#202471, @timegrid wrote:

Shouldn't the enabled close button in win10 / disabled text / nr2 have green color? (it's the "search certs on server" dialog).

Shouldn't the enabled close button in win10 / disabled text / nr2 have green color? (it's the "search certs on server" dialog).

This also happens on Linux. And even with the Fusion style.

Thanks for the Windows 11 screen shots.

Thanks for the feedback. The issues are the same as on win10:

Regarding the "unsure" findings:

• invalid state in cert list tooltip (red on black)

1. Issues found

Most issues with icons in high contrast modes (of Windows 10) should have been fixed. Needs to be verified especially with the high contrast modes of Windows 11.

Setting to Testing.

Yes, for GPD and VSD there probably should be version numbers in swdb.lst if the update check should actually be active in those distributions. I think for VSD the update check is usually deactivated because a) it accesses the public internet which some customers don't want and b) the software is usually not installed by the users themselves so that the update check doesn't make much sense.

So, what shall we do with vanilla kleopatra, or GPD or VSD? It will be easy to record current versions number in swdb.lst

Tagging with Windows because the update check is a NOP except on Windows.