I recently downloaded an LO nightly build installer, and tried to run it. My Windows 11 brought up a blue-background window telling me that "Windows has protected your PC" or "Windows protects your PC", and that it refuses to run the executable since... frankly, I don't quite remember the reason, it must have been missing some signature, or being unknown to Windows, or something. There is not even an "Install anyway" button - there is a "More Info", and when you click it, then you get an install-anyway button. I don't know whether this happens for actual releases or not (I use Chocolatey to install LO regularly). What I can't say is that it doesn't happen twice: The second time I run the same MSI, I get a confirmation prompt, but it's just a confirmation: "“LibreOfficeDev_26.8.0.0.alpha0_Win_x86-64.msi” is an executable file. Executable files may contain viruses or other malicious code that could harm your computer. Use caution when opening this file. Are you sure you want to launch “LibreOfficeDev_26.8.0.0.alpha0_Win_x86-64.msi”? questionable, but more tolerable than what I saw before. Now, you could say that the "protected your PC" is NOTOURBUG, but - it deters people from installing LO, especially if it also happens for releases.
That is nothing we can fix on our end - it is just a trigger that kicks in if something is downloaded by comparatively few users/if it is a new/unknown file and since the daily builds aren't codesigned (and I guess the rules/what exactly triggers it can/will change over time) As you write there's an option to open anyway, even if "hidden" behind a more info button. It won't happen for actual releases since those are on the one hand downloaded by lots of people, and also they are codesigned. So I set it as worksforme, as we cannot control Microsoft's heuristics about what is considered potentially malicious, and we also don't want to have signing keys on our CI bots/we don't want to sign builds created automatically (and actually cannot, signing on windows requires unlocking the key stored on a smartcard/requires physical access to the machine). Given that daily builds are used by advanced/knowledgeable users, I think the situation is acceptable. It is similar on macOS where apples sets a quarantine flag that has to be cleared before you can launch a unsigned binary from an "untrusted" source (aka not created on your own machine/downloaded from the internet) Would be a totally different story if our main releases were affected, but as said the offical alpha/beta/RCs/final builds don't have this specific problem.
(In reply to Christian Lohmaier from comment #1) > That is nothing we can fix on our end On our end, no. But we could try to politically fix this, on their end. Although... > - it is just a trigger that kicks in > if something is downloaded by comparatively few users/if it is a new/unknown > file and since the daily builds aren't codesigned (and I guess the > rules/what exactly triggers it can/will change over time) > > It won't happen for actual releases since those are on the one hand > downloaded by lots of people, and also they are codesigned. I guess it's not worth the effort, for nightly builds. Changing the resolution to NOTOURBUG, because it's not as though you don't see this happening.