Fixed. The problem was that the selected sections were stored in the 64-bit registry (unless browser integration was installed; see T8038), but they were read from the 32-bit registry.

Fixed.

Let's give this Normal priority.

Meh! The installation of the browser integration explicitly enables the 32-bit registry. Obviously a leftover from gpg4win 4.

In T8039#211727, @timegrid wrote:

I wonder where the information of the previously installed components comes from, if not from the MementoSection_SEC_kleopatra fields.

Thanks for checking! So now we know why the line is missing. Looks like installing browser integration causes a broken installation (at least with respect to registry keys).

I searched the whole registry and found, that if browser integration is installed, this key still lives in WOW6432Node: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Gpg4win

Oh, surpisingly it's the other way around: if the information is given in the registry key, all components are preselected. If the key is missing (browser integration installed), only the installed components are preselected. I wonder where the information of the previously installed components comes from, if not from the MementoSection_SEC_kleopatra fields.

Without browser integrations installed, the preselection works fine though.
Probably this happens, because the info in the registry is missing as soon as browser integration is installed, see T8038: NSIS: Updating line omitted if browser integration is installed

should properly uninstall the existing installation.

Regarding 32-bit and 64-bit installers: The installer looks in both registry trees for the relevant registry keys, i.e. 64-bit over 32-bit and vice versa should properly uninstall the existing installation.

I understood that this is done on purpose, i.e. all other components are explicitly always preselected.

gpg4win-5 has no idea that gpg4win-4 is installed because the former is a 64-bit installer/application and the latter a 32-bit installer/application, i.e. they use different registry trees. More important that the missing "Updating line" is very likely that the gpg4win-5 installer does not uninstall gpg4win-4. I haven't checked if NSIS is capable of detecting/uninstalling a 32-bit application from a 64-bit installer.

see also T8039: NSIS: Preselection of installed components on reinstall only works with browser integration installed

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

Also fixed for gnupg22

This has been fixed for gnupg24 and gpg4win.

As you might have seen from the commits mkportable has been removed from Gpg4win.

In T6085#162918, @ebo wrote:

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

In T6085#162921, @aheinecke wrote:

@ikloecker yes as mentioned in my response the current hints are only for symmetric.

@ikloecker yes as mentioned in my response the current hints are only for symmetric.

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

The long hint is "hidden" in the tooltip of the short hint.

And the issue for which @ebo opened this ticket is in my opinion that you have to fail first before you see the hint.

I think there was a misunderstanding here. We already set .pinentry.constraints.hint.long and .pinentry.constraints.hint.short in GnuPG-VSD but firstly they are only about symmetric.
And the issue for which @ebo opened this ticket is in my opinion that you have to fail first before you see the hint.

Thanks for the explanation. I understand gnupg-w32 is mainly for installing the command line component, yet adding a context menu for a specific file type is just as simple as importing a reg file like:

It is related in the following way:
The Gpg4win installer creates these context menu actions through the component GpgEX.
The Gpg4win installer does not support Windows XP anymore.

What I need is exactly ikloecker described on Linux. The point is NSIS installer gnupg-w32-2.2.27_20210111.exe (and versions above, I am sure) do not create context menu shortcut. Windows XP is not the point. Same on another Windows 7 machine. Do you need I find another windows 10 machine to test? I think it's easier to check whether the installer has that feature or not.

No support for Windows XP anymore.

Sorry, I should clarify that I am using the windows installer
gnupg-w32-2.2.27_20210111.exe on WindowsXpSp3. The installer do not create
any context menu since I use it. I use Gnupg with Enigmail in Thunderbird,
so Gpg4win is not preferred.

This is a hard to solve problem in the NSIS installer: If you accidently started more than one installer they may both register files for update at the next restart. Now after the restart the file which is to be renamed does not anymore exist and thus a component or even library is not available. In this case it is GpgEX, the explorer plugin.