It's not enabled by default, though. Enabling it by default would probably break just about every Windows program out there and like UAC on Vista, everyone would turn it off immediately.
It's not enabled by default, though. Enabling it by default would probably break just about every Windows program out there and like UAC on Vista, everyone would turn it off immediately.
Seems like good enough a reason for them not to do it.
Their tooling is open-source, surely the few people still using unmaintained versions of macOS can create a `LegacyHomeBrew/brew` repository with patches for old macOS versions? It would also be a good place to stuff all the patches and workarounds that may be necessary to support old macOS versions.
Any decent project should have a way to install without Homebrew. It's really not necessary.
I'd classify that as an Apple problem rather than a Homebrew problem. If Apple themselves cannot be arsed to support an OS version, why would a volunteer project take on such a challenge?
For every piece of software I've fetched using Homebrew, there's a "compile from source" option available on Github or some other source repo.
Source? The OP suggests they expect it to be blacklisted
>I assume that Kaspersky bootloader signature certificate will not live long, and it will be added to global UEFI certificate revocation list, which will be installed on computers running Windows 10 via Windows Update
If you search around you'll also find that microsoft does publish secure boot revocations, contrary to what you claim.
You might think the 2025 update will solve the problem, but:
> Before following these steps for applying the mitigations, install the Windows monthly servicing update released on July 8, 2025, or a later update on supported Windows devices. This update includes mitigations for CVE-2023-24932 but they are not enabled by default. All Windows devices should complete this step regardless of your plan to enable the mitigations.
The current status for the update (https://support.microsoft.com/en-us/topic/how-to-manage-the-...) says:
> The Enforcement Phase will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins. When updates are released for the Enforcement Phase, they will include the following:
Basically, unless your company and sysadmin have enforced this fix (i.e. you're a home user), Microsoft hasn't revoked their keys.
Then there's CVE-2024-38058, a similar attack. Microsoft tried to roll out a fix, but that broke compatibility, and the fix was then rolled back. Again, that problem can be fixed with the solution for the previous CVE, but that is still not deployed by default.
https://neodyme.io/en/blog/bitlocker_screwed_without_a_screw... describes the TPM2 attack in detail as well as mitigations and solutions much better than I can.
The biggest weakness of secure boot was always third-party vendors shipping "insecure" bootloaders. It's a lot of work to verify signatures for every bit of data that gets loaded, especially on the PC platform.
Microsoft then made that system entirely useless by signing code that could be used to load unsigned code, like demonstrated here.
They then also refused to blacklist their own broken bootloader to save sysadmins the time (who would need to deploy new recovery images and boot media containing the fixed bootloader). That vulnerable bootloader is particularly bad because it can be used to have the TPM unlock itself and give up the Bitlocker key, which the Linux loaders shouldn'tbe capable of even if they apply the bypass mentioned in the article.
In a world where Microsoft cared about secure boot, they would blacklist the vulnerable Linux loaders as well as their own old bootloaders. Why Microsoft? Because they signed the files in the first place, only they can rescind the signatures. In that world, Linux users would call for Bill Gates' head for securing their security feature and sysadmins would be out for Steve Ballmer's blood for breaking their complex custom recovery system that nobody dares touch.
Now we'll be stuck in the worst of both worlds.
The reality is that many rich industries are built on the backs of illegal workers. If countries would punish those who hire illegal workers more than they do the illegal workers themselves, the resulting collapse of the agricultural and food industries alone should prove that the current systems are already being held up by people who do not participate in the welfare system.
The people who would've come through Ellis Island are still coming in, they're just not getting registered anymore, and the people and government have turned a blind eye so they can cheaply dismiss them when they're no longer necessary/when they need to act as a scapegoat.
It's very telling how all these examples are all "look, we made it recreate a shitter version of a thing that already exists in the training set".
Without enough examples to copy from (despite CPU manuals being available in the training set) the approach failed. I wonder how well it'll do when you throw it a new/imaginary instruction set/CPU architecture; I bet it'll fail in similar ways.
Quite a pain that companies refuse to take no for an answer :/
All you really need is a bunch of disk and an operating system with an ssh server. Even the likes of samba and nfs aren't even useful anymore.
I see the traditional "RAID with a SMB share" NAS devices less and less in stores.
If only storage target mode[1] had some form of authentication, it'd make setting up a barebones NAS an absolute breeze.
[1]: https://www.freedesktop.org/software/systemd/man/257/systemd...
Convincing a Linux user to paste rm -rf / into the terminal is not malware. It's social engineering.
Scanning binaries for known malware is already built into the OS.
The screenshots from the article clearly show a permission prompt for a program. Whether that's a binary or a shell script or something else doesn't matter, the infection stage should've been caught by anti malware rather than permission prompts.
Windows Defender does this already. If Apple's AV can't catch this, I think they may be relying on their DRM-as-a-security-measure (signatures, notarisation, etc.) a bit too much.