While this is a small problem for software (and hardware) that needs custom kernel drivers, or software that needs to run as administrator, you seem to have jumped a long way past that to rant about FOSS on Windows with no justification- general unsigned software works just fine on Windows as it always has.
"works just fine on Windows as it always has" is just not true. These days, I cannot even run my own cross-compiled Go executables of a cross-platform tool that I am developing in private on Windows 10 or 11, because some blue popup from Windows Defender/"SmartScreen" prevents me from doing so, and tells me to contact the software publisher if I'd like to be able to do something about it. Outright disabling Defender/SmartScreen works around the problem (but the popup doesn't tell me that), and, presumably, signing these executables with a "trusted" developer certificate would make this outcome less probable - that is at least what people online have been telling me.
In my book (I started using computers during ther Windows 3.0 era), this clearly does not qualify as "working just fine on Windows as it always has", no matter how you spin it.
Do you download the cross-compiled executable via http or smb to the Windows machine? If so than it most likely got earmarked with a NTFS alternate data stream.
File Settings > This file come from another computer: Unblock
PowerShell > Unblock-File
Add your smb file share as trusted: Internet Properties > Security > Local Intranet > Sites
I hate it too that you need to sign software that you want to publish. Totally destroys the economics of little shareware type software.
Thanks for this (and I actually learned about PS1's handy Unblock-File this very moment! :)), but I am aware of the "mark of the web"-stuff MSFT had introduced after realizing that an "attacker-controlled" filename extension alone is a poor safeguard against making a file executable ;)
For my specific problem/situation, the executable in question gets transferred to the target machine on a read-only UDF file system burnt onto a USB thumb drive. Other Golang executables from FOSS projects on the same filesystem execute just fine (I guess they have better "reputation", due to their hashes being registered with MSFT somewhere).
