With the 25.12 release, the luci app to use ASU for upgrades became installed by default in OpenWrt's "vanilla" images the project builds and provides for supported hardware and devices.
Previous OpenWrt releases at least as far back as 21.02 could be equipped with the same degree of ASU support by installing a single package (luci-app-attendedsysupgrade) and its dependencies.
Living in a city in Europe in a very decent apartment in a building that was erected in the 1880s (sic), this article made me chuckle - but also feel bad about how the throwaway society of the 21st century has extended even to things that are supposed to last.
We use this technique in our team to distribute passphrases for our secondary secret stores (that contain instructions on how to access our primary secret stores) in a "democratically secure and safe" manner.
One of my most esteemed former co-workers used to say that whenever you succeed in making something idiot-proof, the universe will create a better idiot, undoing any progress you made.
Does Windows on ARM use VBS/Virtualization Based Security, and does ARM support nested virtualization to do so in a VM, too? Does it employ costly CPU vulnerability mitigation techniques that might hit two times in a VM (unless the Hypervisor is adequately set up, which I'd hope is the default for Hyper-V)? Those two things account for most of the common performance problems observed when putting modern Windows in a VM. I'd love to know more about it, but the article does not seem to mention either.
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).
"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.
As a wireguard user myself (even on the lone Windows machine that I still begrundingly have), I am happy that this problem could have been resolved. I am just wondering - if there had not been this kind of public outcry and outrage that Mr. Donenfeld discounts in his announcement message, would the issue have been fixed by now?
What are individual developers of "lesser" (less important, less visible, less used) software with a Windows presence to do? Wait and pray for Goliath to make the first benevolent move, like all the folks who got locked out forever from their Google accounts on a whim? Ha!
The fact of the matter is, the code signing requirements on Windows are a serious threat to Free and Open Source Software on the platform. Code signing requirements are a threat to FOSS on all platforms that support this technique, and infinitely more so where it's effectively mandatory. I firmly believe that these days, THIS is the preferred angle/vector for Microsoft to kill the software variety their C-levels once publicly bad-mouthed as "cancer", and zx2c4 is one of the poor frogs being slowly boiled alive. Just not this time - yet.
I am already donating the rough equivalent of the cheapest Microsoft 365 subscription to The Document Foundation each year, and won't stop now just because they're increasing the visibility of their donation-based funding model. I hope they succeed, and many more people start contributing financially as a result.
Thanks, but no thanks. The only winning move, long-term, is to excise everything this wretched company makes from your life as vigorously as possible. It's been true 20 years ago, and it's even more true today.
None of the missing ones have proper, official, upstream LineageOS support. If you install LineageOS on these, you install somebody's own, personal fork of LineageOS. Which might be totally fine, of course. But because of the necessarily different signing keys alone, it's a (potentially) very different thing.
I disagree. If LineageOS builds were actually unsigned, I would have no way of verifying that release N was signed by the same private-key-bearing entity that signed release N-1, which I happen to have installed. It could be construed as the effective difference between a Trust On First Use (TOFU) vs. a Certificate Authority (CA) style ecosystem. I hope you can agree that TOFU is worth MUCH more than having no assurance about (continued) authorship at all.
LineageOS isn't unsigned, it just happens to be signed by keys that are not "trusted" (i.e., allowed - thanks for the correction!) by the phone's bootloaders.