This has been specified in 1997 by PGP 5 for a good reason. We talked often enough about this and it does not help to repeat your ideas over and over again. RFC9580 specifies a different protocol than OpenPGP as specified by RFC2440 and RFC4880 but alas grabbed the name OpenPGP for this.

b) For non-confirmed keys it returns broken OpenPGP keys (ie. without a user id and thus without important information)

Thank you very much for yours answers, explanations and effort!!!

Yeah sure.

In T8101#213455, @werner wrote:

You need to use a current Windows version (and not Windows Server 2016)

keys.openpgp.org has two problems: a) it is a centralized service due to the requirement to confirm mail addresses. b) For non-confirmed keys it returns broken OpenPGP keys (ie. without a user id and thus without important information). For these reasons and the general problems with the keyserver-(networks) there is no more default.

I'm surprised that nobody did detect these problems during the long beta phase...

Please do not use the portable installation - it is dangerous to use it. We will eventually remove this option.

Should work now.

This was fixed in Qt 6.10.0 by adding compatibility code that's "hidden" behind a compiler flag, i.e. we just need to enable this compiler flag. See https://codereview.qt-project.org/c/qt/qtbase/+/629255 for details.

For the time being I "upgraded 5.0.1 to 4.4.1 (in the new directory), and then Kleopatra started again.
When upgrading that installation again to 5.0.1, Kleopatra does not start (same error message as before).

Also: When I click "Abort" ("Abbrechen"), the dialog disappeared, but the main windows does not show any progress: Specifically it does not abort.
I had to press "Abort" ("Abbrechen") in the main window; then the upgrade aborted.
When retrying (and confirming that I don't want to install as Administrator (actually I cannot), the proposed target directory still is "C:\Program Files\Gpg4win".
When locating the previous installation directory (it seems it was a subdirectory of %USERPROFIL%\Downloads) the upgrade succeeded, but Kleopatra fails to start.
It want a bin\Qt6Core.dll, bit in the bin directory there is only a Qt5Corew.dll dated " 14. ‎Juli ‎2023, ‏‎13:23:40".
When retrying the installation/upgrade it announced to upgrade 5.0.1, but then did seemingly nothing (I guess as the version was estimated to "be current").
It seems some "reinstall/repair" option is missing.

We forgot to update the tooltip when the default keyserver was removed in gpg 2.5.3. This has already been fixed in the meantime. Sorry for the inconvenience!

Meanwhile all executables are signed.

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

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 AppImage now displays the same version as the Windows builds, i.e. in particular Gpg4win-VERSION for the "default" build.

With the recent changes to the build system the current version numbers for the Beta versions of the MSI packages are 4.0.90.<somenumber> for VSD, 5.0.90.xxx for GPD and Gpg4win. Thus we override the standard micro version with 90 to indicate beta versions. Obviously this will require to de-install a MSI beta version before installing the regular version. But we are somewhat constraint by the Windows versioning scheme.

In T7509#212953, @timegrid wrote:

Is the displayed version 4.0.0.260370 right for the appimage? shouldn't this also display the gpg4win version?

Got reported again with the 5.0.0 release, see

• https://forum.gnupg.org/t/issue-with-automated-installation-of-gpg4win-5-0-1/7098
• https://forum.gnupg.org/t/version-5-automatisierte-installation/7093/8

Is the displayed version 4.0.0.260370 right for the appimage? shouldn't this also display the gpg4win version?

Looks good to me on gpg4win-5.0.1-beta24 @ archllinux:

Ready for testing

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.

Gpg4win 5.0.0 (2026-01-14)

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.

Indeed, it looks this way. Thanks so much! Windows 10 and 11 in my case.

Looks good to me on gpg4win-5.0.0 @ win11. Tested with 20 starts of each combination:

• with / without keyboxd
• quitting kleopatra / killing all processes

I think this has been resolved in Gpg4win 5.

I've changed this now to "GnuPG VS-Desktop" (and "GnuPG Desktop").

Am I right that for VSD we use:

We set the following organization names for the different products:

• Gpg4win: Gpg4win
• GnuPG Desktop: GnuPG Desktop
• GnuPG VS-Desktop: GnuPG VS-Desktop

i.e. the registry path for Kleopatra settings will be for example
SOFTWARE\Gpg4win\Kleopatra\<config group>\<config entry>

On gpg4win-5.0.0-beta479 @ win11 the registry settings are not read due to the organization name not set.

I'm pretty sure that this is done. For gpd5 the changes have been merged upstream and kconfig reads the config keys in the desired order.

This task is obsolete as we do no longer use the Temp directory for encryption (I believe since vsd3.3.0/gpg4win 4.4.0). Instead the file is written directly to the target location with the ending ".part". It is renamed there after the encryption is completed.

It's mostly obsolete. With T7874, GetThreadUILanguage is used instead of GetThreadLocale if no locale/language related environment variables are set. GetThreadUILanguage returns the configured display language.

Note: No further tests, as this is explicitly about the qt5 AppImage

Is this ticket obsolete with T7874: Kleopatra: GnuPG System configuration not translated?

The next major release is coming

I have cleaned up the patches for the AppImage. Now the build fails at okular because it needs PlasmaActivities. In master this dependency has been removed so that I'm going to wait for Sune's update of Gpg4win to Qt 6.10.x, etc.

Additionally to the fix Andre cited years ago, we also did some more changes recently in regard to how signed/encrypted mails are shown. Which are relevant for the inbox, too.
This issue should be fixed.

In gpg4win-5.0.0-beta413 @ win11 there's a failing patch for kcrash:

Werner said we leave it as is for vsd3.3.3 and only change reading order of the configs for the change to the next mayor release.
So I retag this ticket for gpd5x. timegrid has made a separate ticket for updating the documentation.

So this means, the order in the description should be implemented, right?

Yes, by definition an immutable group doesn't allow any changes for that group. Don't mark a group as immutable if you want to allow changes.

The [KDE Action Restrictions][$i] in XDG_SYSTEM_DIRS/kleopatrarc prevents any changes within the whole group afterwards.
I guess, this is intended by defining an "immutable group", but i doubt that we want to prevent admins to change those settings?

So, regarding the minor version change: the change of order seems not critical (as there was no settings file before), but the introduction of the settings file might be.

I verified, that both in vsd 3.3.2 and vsd 3.3.3 beta90.29 the current implementation is

And we shouldn't change the precedence in a minor release, I believe.

The configuration readout order still needs to be specified/fixed.

Hi, I've managed to reproduce this bug on the gpg4win-5 beta as well. I think the frequency has gone down, perhaps, but it is still present.

As this was finished more than a year ago, this should be included (and testable) in vsd