Fix Windows registry access mode when adding icons to file type associations

[marcoesters]

Description

When adding an icon to a file type association in the Windows registry, the subkey is opened with read-only access. This leads to a permission error when trying to add the icon. This was not caught by tests because the data file did not have the icon key set.

Opening the subkey with KEY_SET_VALUE correctly adds the icon file.

Closes #191.

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

[jaimergp]

Awesome catch!

We don't need this anywhere else for other keys, right? Thinking of file type association and so on.

[marcoesters]

The only other key we open is here:

menuinst/menuinst/platforms/win_utils/registry.py

Lines 47 to 52 in 75f7fa0

	with winreg.OpenKeyEx(
	(
	winreg.HKEY_LOCAL_MACHINE if mode == "system" else winreg.HKEY_CURRENT_USER # HKLM
	), # HKCU
	r"Software\Classes",
	) as key:

This is done with write-only access as the default. However, we only write to subkeys and the documentation there is a little confusing:

The key identified by the key parameter must have been opened with KEY_SET_VALUE access.

However, when a subkey is not null, the source code suggests that they are always opened with KEY_SET_VALUE access: https://github.com/python/cpython/blob/6d419db10c84cacbb3862e2adc940342175bfce9/PC/winreg.c#L1787-L1796

My interpretation is that the reason the icon fails is that we don't explicitly pass a subkey value, but instead operate on the key object itself.

[jaimergp]

Got it. So for now no action needed but let's keep an eye for reports in case we need to pass more access flags. Thanks for the research!