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.