fix tested and confirmed with GnuPG 2.5.12 on windows 10

If this is indeed a bug it won't be fixed in gpg4win 4. Thus a test with gpg4win 5 beta is highly appreciated. It would also be interesting to see what what version of gpg comes with Git.

i've included logfiles for gpg-agent and scdaemon with debug-level 10. the files include

We will do a new gpg4win beta soon.

@m.eik Could you please enable debug option for gpg-agent and get the log output for the crash?

I think it is save to say that we will not implement pgp/inline encryption with attachments

Can you please try with gpg4win-5 beta: https://www.gpg4win.org/version5.html this makes it easier for us to see the reason. Deinstall gpg4win first and note that version5 is 64 bit and installed under Program Files (w/o (x86)). If it still does not work please add

This is addressed in my blog post; I set the GPG executable used by Git in the configuration so that it uses the one shipped with GPG4Win:

The problem is likely the gpg which comes with Git on Windows. Depending on where they are in the %PATH% a wrong one will be used. Please run gpgconf -L to check that the correct version of gnupg is used. I have never used git on Window but I would suggest to remove the gnupg binaries which come with Git and adjust the gpg.exe name in the global config.

The reporter in the forum originally wrote:

It is unlikely that we will fix it. The OL behaviour is just too flaky. It might be possible to do this in the no-preview mode in a more robust way.

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?