Sun, Jan 25
@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?
Fri, Jan 23
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.
Fri, Jan 16
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.
Tue, Jan 13
Thu, Jan 8
Looks good to me on gpg4win-5.0.0-beta479 @ win11.
Jan 6 2026
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.
Jan 5 2026
Dec 23 2025
Yes, Kleopatra quits again with the beta from yesterday:
Dec 22 2025
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.
Dec 15 2025
Dec 12 2025
Dec 9 2025
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.
Dec 8 2025
New new plan (after discussion on 2025-12-08):
Dec 4 2025
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).
Dec 2 2025
Backported for VSD 3.4
Dec 1 2025
This is now implemented for Gpg4win 5.
Nov 28 2025
Nov 26 2025
Nov 25 2025
For our GnuPG Okular, we should not use the standard file names (okularrc, …) as this would conflict with a regular Okular installation.
Nov 21 2025
Looks good to me on gpg4win-5.0.0-beta413 @ win11
Nov 11 2025
Oct 23 2025
Tested on gpg4win-5.0.0-beta395 @ win10/win11
