No, I have no admin rights on that computer: I installed the portable version, too. I saw that the previous version had been uninstalled before installation.
On a different computer I tried to reproduce the situation where GPG4WIN had been installed the standard way. I did not see the effect there. However when upgrading I got a message that the c library could not be written; that was because some Kleopatra windows was still open. After manually closing that, a retry was successful. Other software installers close the application before trying an uninstall or update, however.

Just to be clear: You originally installed it as a portable applications and then you also installed a new version in the standard way?

after https://dev.gnupg.org/rW14d86c01819ef3ddbc7f03b34e821e367cea3b02 only qrencode is left:

currently not testable. some urls in download.sh are broken (404):

looks good to me on gpg4win-5.0.0-beta190@win10

Unfortunately, the attempt on my end still fails. The MSI package was successfully built; however, testing installing it on a Windows host resulted in garbled UI text and a bunch of errors.

Possibly related upstream bug:

light.exe : error LGHT0216 : An unexpected Win32 exception with error code 0x65B occurred: Function failed

I did not run the full tests becaue those would take some hours but one test case using the genhashdata tool from the libgcrypt test suite gives the correct value (see genhashdata.c source)

the included tools are intended to bootstrap things and are not optimized in any way. We don't run large data test either. Someone will look into it, thoigh. A better way is to use

Is not a GpgOL bug.
Full functionality will be possible with GpgOL/WEB.

In T6883#199155, @ebo wrote:

I guess this is done if QT6 versions have a pinentry?

I guess this is done if QT6 versions have a pinentry?

This even happens with native Windows applications thus normal priority. Users need to watch the taskbar for blinking items.

This is very similar to T5780 except that it concerns a different operation and thus a different window. The fix is likely the same as for T5780.

Okay. We now replace the standard Breeze icon of kleopatra with the red head for vsd and with a new blue head for gpd. The replacements are used for the About action and in the About dialog, but kwin (X11) insists on using the standard icon as window icon. And the system tray also shows the standard symbolic Breeze icon instead of the replacements. strace shows that the replacement icons embedded in the AppImage are loaded. No idea why kwin and the system tray still use the standard icons.

FWIW, for gpd and vsd we should use a different icon (blue head for gpd and red head for vsd)

Kleopatra with Breeze style:

I did a quick test with a test user running a Wayland session and the AppImage works now.

Needs to be tested/verified by other developers. In short you do

./autogen.sh
cd packages
./download.sh
cd ..
./build.sh --appimage --builddir=...

If you omit the --builddir=... option then ~/b/SRCDIRNAME-appimage will be used.

Building an AppImage including Kleopatra and Okular works now (again) in the gpg4win-5-branch.

aheinecke: Yeah, but I did quite some changes to build.sh for a real out-of-source build (w/o copying files)

Just so that its not overlooked and you are meaning something different. But I had the Qt6 / KF6 branch working with the --appimage parameter.

Thanks for that info. I tag it as FAQ and change the subject in case someone searches for such a problem.

After a lot of digging I finally found the problem. It's actually not Gpg4win/GnuPG, but it's the Bitwarden desktop app. They recently added support for it to function as an SSH agent, and even though I have not enabled that feature, it's hijacking the socket anyways. When I close Bitwarden the issue disappears. The issue is logged in bitwarden/clients#13150.

@werner Thank you for the response. Is there a nightly build or similar that I can grab from somewhere to see if using the latest master branch solves the issue?

I never tested the WSL stuff with gpg-agent but I use the standard OpenSSH based ssh server on Windows on a daily base. It is actually part of our release build chain. A recent problem I encountered was fixed in master with rG2469dc5aae and should be backported to 2.4. Might be related to your problem but I need to read your detailed bug report more closely.

VS-Desktop-3.2.94.481-Beta: same as for the Gpg4win version.
And there is a hint if you enter "hkps://something" that this is not the right format (that is included in Gpg4win 4.4.0, too)

Note that that Beta uses a 64 bit Kleopatra but the GnuPG engine was accidentally build for 32 bit. This will be fixed with the next Beta. That might increase the confusion a bit.

GpgEX requires/uses Kleopatra so that only GnuPG would be left if you could deselect Kleopatra. And that's exactly what the simple installer installs because the simple installer is included in the Gpg4win installer.

FYI usually these are my install options:

No problem. I can stay on 4.4.x. Just thought I should give the beta a try and let you guys know.

Thanks for your feedback. Maybe the "minimal" install is missing a file. It's a beta version for a reason. We'll make sure to fix it for the stable release.

None. I just use the command line tools and always perform a "minimal" install. @aheinecke: I already tested it on cmd.exe. Same result. Also I do not have QT installed, or a QT_PLUGIN_PATH set up. The bottom line for me is still:

Actually I would like to remove the option to install gpg4win at non-standard places because this is somewhat troublesome. However some users rely on this and thus we better don't remove i.

What components of Gpg4win other than GnuPG do you use?

Yes, that's by design. GnuPG is always installed in $INSTDIR\..\GnuPG by the gpg4win installer.

Yeah that is a messed up environment mixing elf and windows binaries. There is no which on windows. It is called where. So if your terminal is able to execute which then this is some kind of Linux environment on Windows. The winpty error comes from the terminal. Please use cmd.exe for all tests.

I just tried to call pinentry directly on Windows cmd prompt:

Thanks for the comments. This is a regular git for Windows install which afaik uses mingw64. The messup with the binaries brought in by git has always been this way. I am using aliases to differentiate between the different versions. One might think that this may cause things to break, however all used to work well with 4.x versions.

gpg: [stdin]: clear-sign failed: No pinentrysrc/libwinpty/winpty.cc, line 924

Here you are:

Thanks for opening the ticket. I looked at it when it was reported in the forum, But had no test build at hand to test a fix. If you look at the history of g4wihelp.c you can see how other functions have been ported to Unicode recently. The change is that the strings in the nsis script world have changed to two byte strings. The problem is then where the c code interacts with the NSIS script obtaining parameters and setting return values. Since the popstackna takes an ascii string it only takes the first character as the second byte is null. Changing these occurrences to popstackn and the setuservariable to widechar should do the trick.

FWIW: as mentioned in T7452#195891, it might be necessary to manually copy the uninstaller to a temporary directory ({{ tmp_uninstall_exe }}) and call it from there to get a clean uninstall:

I had T3840 assigned to me related to the Qt parts. I close that now as duplicate. But I don't see that we ever added a call of gpgrt_w32_override_locale to kleopatra or gpgol either. Which I assume to be the fix for T7454

Since codesigning for all dlls was added this is fully resolved.

There won't be improvements to PGP/Inline

I looked at the wiki and the content seems okay and what this issue requests has been done years ago. So resolved.

I have fixed this as a7349189f3af05822eba4bd17b62482fa2b0747f so I am closing this as a duplicate of T5982 because it is clear to me now that the last remaining and current problem was sending and not receiving such mails and was broken by 9f81ed6561c5f41e50d1a51333c9586a33ed2ef6

The kf6 branch in Gpg4win was created for qt6 builds and can be used.

This was fixed by c0ca4f1b254f6879d719d1a5ed43a51ca9015b93 since the embedded message was not handled it was not extracted / parsed into an Attachment C++ Object which caused this error. I don't want to change the status of tasks which are not assigned to me but i saw it while looking over my open assigned tickets.

Jan, you please run something like

@uwi: We removed the ciphersuite from the server and tested with 4.2.0 that you get an update notification now. Because of some caching you may need to

This is due to an update of the server providing the version info. The server (Apache) uses a smaller hash than the ECC key. This is allowed behaviour and was fixed in our TLS library in 2022; see T6059. However, the new library was released only early this year an. We will check whether we can tell our Apache to use a more correct hash algorithm.

Ok. Sorry, just to avoid debugging in case it is not known, I am pretty sure the ini file is a regression from the unicode nsis switich. The timing when it was reported to no longer work matches around that time and the installer code itself hasnt changed for even longer.

In T7452#195845, @aheinecke wrote:

I doubt it as what Gpg4win does here is completely standard. So the win_package module should handle it or there would be multiple results if you search for "NSIS uninstall ansible"

Thanks for the clarification, it seems that was necessary.

Just a note (in case it was not clear enough): I was *not* talking about registering "*.pub" for Kleopatra (currently it launches Microsoft Publisher), but I was talking about the file selector's default input pattern (I had to switch to "all files" to be able to see the file I wanted to import):

In T7452#195841, @m.eik wrote:

this could also help with T5952, i was testing with ansible as well.

- name: Uninstall gpg4win from the registry
  ansible.windows.win_package:
    product_id: 'Gpg4win'
    arguments: /S
    state: absent

From a quick glance at the docs. This looks completely correct. What did this do and what didn't it do?

In T7452#195836, @aheinecke wrote:

To workaround you need to copy the uninstaller to a temporary locationm firs and then execute and delete the copy.

Just to explain, if you are executing it from the command line the command line will "lock" the uninstaller until it is finished. In GUI Mode it creates a copy in %TEMP% launches this copy and exits. When run from the command line it requires a session reset to delete the unistaller. So log out / log in and the uninstaller should be removed, but the dir might still exist. I am not sure. To workaround you need to copy the uninstaller to a temporary locationm firs and then execute and delete the copy.