If I understand the issue correctly, it appears that this change primarily impacts casks on macOS. In fact it looks like it may only impact casks. Casks are used to install binary packaged software, often in the form of a dmg or pkg file on macOS. Most people I know are not installing too many casks, and most of the ones I've seen install signed binaries anyway. The important thing for me with this is that it doesnt appear to impact homebrew's ability to download, compile, and install open source software. And that is the main thing I use homebrew for. I believe that is true for most people too, but I fully expect to learn very quickly if there are a bunch of taps in use by people that distribute unsigned binary installers of software for macOS. :-)
> Most people I know are not installing too many casks
Casks are the only things Homebrew does that some other package manager available on macOS doesn't reliably do better. Nix, Pkgsrc, MacPorts, and (and now Spack) all have better fundamental designs;
sane, multi-user-friendly permissions; and enough isolation from the base system that they break neither each other nor manually-installed software.
I use Homebrew exclusively tucked away in isolated prefixes, only to install casks, and without ever putting any binaries it installs along the way on my PATH. I don't remember which programs it is, exactly, but I do use a few that are unsigned.
It also doesn't seem to me that the signing process is as vital in determining actual risk as the curation and moderation processes involved in maintaining "third-party" software distributions like Homebrew or Debian or whatever.
`--no-quarantine` in particular is one of the conveniences that makes Homebrew casks useful. If I have to give my consent anew for each app update, I might as well install the apps manually and live in the usual auto-update pop-up hell.
> Most people I know are not installing too many casks
I did a wipe and install of Tahoe like 2–3 weeks ago and used a Brewfile [1] I've had for years to install ~30 casks via Homebrew, including from the App Store, not to mention 50-60 formulas.
I haven't used Homebrew in a long time, but if I ever did it would be in the way that you describe (so far I've always found reasonable alternatives for the software I want). What I'm wondering is if this is entirely to support unsigned casks, why does Homebrew not simply resign the software itself at install time with an adhoc signature as though it had just built it?
Yeah, my nix-darwin config is pretty nice and perfectly hermetic and reproducible, save for a now-growing list of casks in my brew.nix that looks like this:
> 1password # breaks in nix, must go in /Applications folder
> softwareB # not available in nixpkgs
> softwareC # available in nixpkgs, but because nixpkgs
maintainers are hardline purists it takes 15 minutes to compile from source and ain't nobody got time for that
> softwareD # ostensibly available in nixpkgs, but the package is completely broken (more general case of 1password)
Why not wrap the binaries yourself in flake.nix you say? Well, sure, would love to, if it wasn't such a pain in the ass to do so for each one and keep them up to date.
> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile
What actually happened is that non free software may not be legal to distribute from nixpkgs caches, so you're on your own with building those. That's not really a purist approach.
Only because the purist inventors of nixpkgs structured the policy of what must go into nixpkgs to have this rule. Why doesn’t the same limitation exist for homebrew, for instance? It isn’t some idiosyncracy of the way they are building things, it was a conscious and deliberate policy decision.
And it might be the right one for what they are trying to achieve, but if the goal of the project is to make it more accessible and see more widespread adoption, stuff like this is a shot in the Achilles heel
If something gets built it likely means the sources available in some way, just not opensource. There may be many reasons they're preferred over a binary.
On the contrary, Nixpkgs is generally made by the most pragmatic people and takes a flexible approach to a lot of issues. For instance, very few package managers have packages for proprietary software like 1Password in their official repositories. Nixpkgs also doesn't insist on building everything from source when it's hard to do so. As a result, Nixpkgs contains many packages for NPM or Maven projects. Other package managers insist on packaging all its dependencies from source, which is why they're struggling to package software written in modern programming languages.
As for 1Password, it works fine on NixOS. When installing proprietary GUI apps like 1Password on macOS, I just use Casks. I suspect many people do the same, which might lead to the 1Password package not working as well on macOS because fewer people bother with it.
The Nixpkgs community is internally diverse, but broadly values both "purity" and pragmatism. You can see debates and compromises play out in PRs all the time, or read traces of such careful weighing in the source code of Nixpkgs itself.
For the record, the Nix community's largest public cache doesn't cache binaries of proprietary software because doing so would be illegal— the public doesn't generally have the rights to redistribute proprietary software.
The phenomenon of having to compile free software from source via Nix typically happens when free software depends on proprietary software (which is common on macOS). Maybe this could be ameliorated on a technical level, but I think it's mostly historical accident and ease of implementation that got us to the current situation, where the whole dependency tree has to have a free license for something to make it into the binary cache.
Yes the cask is fine. The problem with 1pass installed via nix is that it doesn’t put it in applications folder because that defeats the hermeticity of the solution. However the 1Password devs designed the binary on Mac to only boot out of applications folder, presumably for security reasons. Most other apps you can get around this by setting up trampoline links to the nix store versions, but if the app straight up refuses to boot anywhere else besides applications folder, you can’t use the typical nix installation path
IIRC there are some macOS APIs that you can only access if your app runs out of /Applications. There are some features of an app called "Secretive" (an SSH agent that stores keys in the Secure Enclave) that only work if you have the app installed under /Applications (whereas I'd normally install it under ~/Applications).
1pass probably does this to ensure that people can't accidentally install the app the "wrong way" and break some features.
Yep. It goes back to “some things nix does are straight up exclusive to the way macOS needs things to be”, as long as that dichotomy exists nix-Darwin will always have hacky idiosyncrasies like this. It’s not an easily solved problem, and it’s not necessarily Nix’s or Apple’s problem to fix. It’s just two antithetical design philosophies. I would love to see Apple support that kind of sandboxing Nix offers here for these apps though
What he is doing in there is kinda cool but the trampoline app solution is quite similar and unfortunately does not fix this problem. Fundamentally the problem is that when you install stuff with nix it gets a folder that is unique to that nix generation. That is by design nix, because you want to be able to go back and forth between generations etc. Apple does not think of things the same way. Applications is a single folder that you can’t subdivide with iterations and it’s “speshul”. These core philosophies are antithetical to each other. This is fine for Most applications who don’t need to be in Applications. You let Nix install into its own little /nix/ generation folder and then create a “trampoline” in applications which is basically like a symlink. Then your app shows up in spotlight etc. where this falls apart is applications like 1Password that MUST boot from the speshul Applications folder
However, you are right, it definitely makes some other pieces of this cleaner. In particular, if you just use homebrew directly with nix, you aren't deterministic or reproducible. You have an impure setup because if you remove a cask from the list, it doesn't actually delete it from homebrew, and you can't go back and forth with generations because homebrew is stuffing things in /applications. The project you linked forces brew stuff to behave like Nix applications and go in /nix instead, which allows it to be able to walk between generations. So it solves most of the issues with brew and nix but not all of them.
> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile from source and ain't nobody got time for that
Which package is that? Is it proprietary but source available? Any free software which is built from source is built by hydra and available from the binary cache to downstream users.
When Hashicorp did their rug pull, I just switched my team to OpenTofu as soon as it had a stable release. No regrets; it's been great. (I did evaluate both projects at that time, of course. But it ended up being a clear decision.)
> If I have to give my consent anew for each app update, I might as well install the apps manually and live in the usual auto-update pop-up hell.
Really? That's a whole lot of UI actions/clicks (and a variable number per .app) versus ... I think two always-the-same UI actions at most. Not like, a huge hassle either way, but I have trouble seeing how Homebrew's not still the winner here even without quarantine bypassing.
> The important thing for me with this is that it doesnt appear to impact homebrew's ability to download, compile, and install open source software. And that is the main thing I use homebrew for. I believe that is true for most people too
FWIW I don't think brew has been compiling on installation even open source things by default for a while now[1]:
The link shows close to 300 pages of precompiled packages available, and that section ends with the sentence "We aim to bottle everything".
I don't think this necessarily changes anything you've stated with regards to the flag being removed as described in the Github issue linked by OP, but I think it's still worth noting because this is markedly different than how homebrew distributed things in the past, so others might not be aware of this change either.
> FWIW I don't think brew has been compiling on installation even open source things by default for a while now
For built in formulas, no. For custom ones very much more so. I know I have a bunch I’ll never have bottles for and would thus always be compiled if used.
That's fair, but I was specifically responding to the part of OP's comment that said that compiling and installing comments was what they expected "most people" used homebrew for. I would expect the vast majority of homebrew users to be installing the built-in formulas for pretty much everything.
I do recognize that there's a bit of ambiguity around when the "compiling" happens, since even the binaries being distributed are still being compiled from homebrew's formulas. The main point I was trying to make was that there was a transition from the "compile everything on the user's local machine when installing" model that homebrew started with to "use the pre-built binaries that homebrew has compiled in advance for installing when possible if the user hasn't specifically expressed they want to compile it themselves". To be clear, I think this is a good thing, and it's a pretty huge quality of life improvement, but I've noticed a few times over the years that this change seems to have not been as widely noticed as I'd expect given how visible it seemed to me even as someone who only uses MacOS on my work machines and not my personal ones. I still sometimes get frustrated with homebrew feeling a bit slow compared to my preferred Linux package manager, but overall it's become far faster and less error-prone over the past decade, and I think it's worth calling out efforts they've taken (like pre-compiling and distributing binaries) that have made a noticeable impact.
In some ways, I think I think understanding the previous efforts they've taken might even help explain why they've chosen not to put in the effort to work around the quarantine issues (e.g. by using local signing like some other comments on this story have mentioned); they're a volunteer project that, unlike most standard package manages for Linux distros, are not in a position where they can easily influence the development of the OS features that might be useful for them. It makes sense to me that the most valuable use of their efforts would be on things that aren't swimming against the current of where MacOS is going. Getting to the point where they could have seamless binary installations at all can't have been an easy task, and the infrastructure needed for it takes additional effort beyond the local compilation model (which still exists). If cutting down on the scope in one dimension makes it easier for them to continue providing the overall feature set they have, this seems like a worthwhile tradeoff to me.
Also if you have an older version of macOS. It will try to take the compiled route for packages but also prints a stern warning that your setup is unsupported.
As an open-source developer, is there a way to have my apps pass Gatekeeper without paying the $100/year Apple ransom and notarizing them? I think it’s the crux of the problem.
As I’m writing these lines, Homebrew has 7656 casks in the official cask tap[1]. I’m not sure exactly how many of those are unsigned but if we assume 4000 then signing them all would be an additional $400,000/year extorted by Apple from the open-source community.
Defining HOMEBREW_CASK_OPTS=--no-quarantine in my shell configuration was a good way to avoid this issue without having to manually run dozens of xattr -d every time I run brew upgrade.
Now my only option left is to pull the trigger and make my system globally less secure: sudo spctl --master-disable
Unfortunately, disabling Gatekeeper doesn’t just allow unsigned apps to run: it also completely disable all verifications for signed apps: notarization checks, revocation checks, trust evaluation checks.
I’m worried app maintainers will start to indiscriminately run xattr -d no matter if the user actually wants that or not. There will not be any kind of standard way to do that so the experience will be very inconsistent between casks…
I hope Homebrew will start supporting hooks at a later point because it would allow users to automatically de-quarantine instead of having all maintainers add xattr -d garbage commands to all their casks.
You can still use Librewolf, if you manually remove the quarantine attribute after every update and reboot. It’s very annoying, but at least it’s possible for now
Not exactly, I have automated stuff which uses python and does rar and unrar and it's installed through brew, it is not a cask, but every time I do brew update, my code will fail to run because it was updated.
This is like buying a machine and not having the ability to do whatever you want with it.
Oh who are we kidding, that's what is happening anyways.
This is a silly distinction. You can always include pre-built object files in your "source code" formula, then the build step is just linking it into an executable locally. That would bypass the quarantine attribute and effectively retain the ability to distribute pre-built binaries without gatekeeper getting involved.
Seems like only a matter of time before someone at Apple realizes this and takes the necessary measures to protect you from yourself.
The linking step isn't even required. You can download any existing binary and codesign it yourself with your local developer certificate. You can even overwrite the existing signature.
I assume brew could even automate this, but are choosing not to for whatever reason.
If Homebrew auto-signed third-party code, that puts them on the line for the security of that code. The whole point of MacOS developer certificates is to increase the trustworthiness of the software you run on your machine. The trust comes from the formal relationship between Apple and the software developer, which includes a traceable financial transaction. If signed software proves to be malicious, attribution is trivial.
If the homebrew team signed everything, they would immediately become a target for bad actors. The bad actors would flood homebrew with malicious binaries, which homebrew would auto-sign, users would download & run, and the bad actors would laugh all the way to the bank.
Yeah, makes sense Homebrew doesn't sign everything with their own certs. I was suggesting that Homebrew could run codesign locally with the user's local certificate as part of the install process.
> The bad actors would flood homebrew with malicious binaries, which homebrew would auto-sign, users would download & run, and the bad actors would laugh all the way to the bank.
Every software distributor has this problem, code-signed or not. This is either already happening to Homebrew (and not using code signing) or there's some other reason that it isn't happening.
casks are mostly for GUI or other apps that need special installation like setting up background services. I've seen it used for IT laptop provisioning to automate the installation of things like Chrome, Slack, Visual Studio, from the command line.
Typical hn comment where major feature of a software is broken because of “reasons”. But it is fine because “I and most people don't use it”.
Hey if you are not using casks you are missing out. It's by far best way to install gui apps on a mac.
Once this doesn't work its serious problem for brew because there are package managers like nix that are arguably better for developers. Something like this could start slow death of brew just like macports did before.
My longstanding prediction that Gatekeeper will ever so slowly tighten so that people don't realise like a frog boiled in water is continuing to be true.
People did realize when the actual Gatekeeper change happened a year ago [1]. But your prediction still holds because frogs do realize when they're boiled in water [2].
The point is that by the time Gatekeeper closes tight enough that everything must run through Apple and it can't be disabled, most people wont notice and will be stuck with it.
Your assertion seems to imply that there will be a point of no return where users are no longer able to stop buying apple hardware to run the software they want, and that therefore people should do so now.
If that's not what you're saying then your point is effectively moot, because if indeed Apple's platform control gets too egregious for some individuals then those people will switch at that point so there's no point in panic-switching now just in case.
In other words, users will switch when what Apple is offering does not meet what those users require. Some users will literally never care because all the software they use is signed and gatekept and so on; some users have jumped ship already because they want to be able to change whatever they want whenever they want. If things continue to "slippery slope" then more people will hit their own tipping point but asserting that it's going to happen all at once and apply to everyone is nonsense.
> more people will hit their own tipping point but asserting that it's going to happen all at once and apply to everyone is nonsense.
the point of boiling the frog is to make sure it happens slowly, such that the alternative options can no longer compete and be an option.
computer manufacturers and hardware makers cannot be trusted to make their platform open, because it would be detrimental to their bottom line. So it must come from regulation - right to repair etc, are on the right path, but what must be done is prevention of platform lockdowns. An owner of the hardware must be able to override all locks from the manufacturer.
There is no reason to believe this is going to happen other than the hyper-cynical conspiracy theories.
It remains easy to disable Gatekeeper if you want. New MacBooks still allow you to install other OSes, even though that would be trivial to lock down with signed boot requirements.
So far, none of the frog in boiling water predictions have actually come true at all. It’s just people parroting the same conspiracy every time the word Gatekeeper comes up, just like we went through every time Secure Boot came up.
Fortunately, Linux laptops are getting better and better. I'm hopeful that by the time my M1 macBook Air gets slow enough to annoy me (maybe a year or two from now?), I'll be able to smoothly transition to Linux. I've already done it on the desktop!
Before macOS 26 I would have agreed with you. But after Tahoe my M1 MacBook Pro feels a lot slower.
Funny, there's even some regression in layer backed NSView rendering where the app I'm working on is faster (in some aspects) in a macOS 15 VM than on bare metal under macOS 26.
Just did this. I am so much happier. As a lifelong Apple user, and side-quest Linux user the choice is a no-brainer nowadays. Desktop Linux is honestly great now. I love(d) Apple but Tahoe was the straw that broke the camel's back for me.
My family have bought macs and been apple fanboys since the "Pizzabox" 6100 PowerPC. My dad handed me down a DuoDock when I was in middle school. We bought a G4 Cube, I had an iBook and Powerbook throughout college and throughout the 2010s.
In 2017 I built my first desktop PC from the ground up and got it running Windows/Linux. I just removed Windows after the 11 upgrade required TPM, and I bought a brand new Framework laptop which I love.
This is to say that Apple used to represent a sort of freedom to escape what used to be Microsoft's walled garden. Now it's just another dead-end closed ecosystem that I'm happy to leave behind.
> This is to say that Apple used to represent a sort of freedom to escape what used to be Microsoft's walled garden. Now it's just another dead-end closed ecosystem
So you haven’t had a Mac since 2017, but you believe all of us using Macs are stuck in some walled garden?
These comments are so weird. Gatekeeper can be turned off easily if that’s what you want. Most of us leave it on because it’s not actually a problem in practice. The homebrew change doesn’t even impact non-cask formulas.
It is said you only realise you are in jail once you feel the chains. And this is something Apple has tried to walk the line on, be locked down but in a fashion that causes the least push back on users.
Personally I never felt Mac OS was that locked down, but it has been over a decade since I last used it.
The only time I felt it was trying to delete 'Chess' only it to be listed as a vital system application. I know this isn't true but I would love it if Chess turned out to be a load bearing application for the entire OS. Like folks at Apple don't know why but if you remove it, everything stops.At least MS managed to remove the load bearing Space cadet pinball. Replaced it with a One drive popup that handles all memory management in the kernel ;)
Back to the original point, by comparison on iOS I definetly did feel the chains. One could fear Mac OS will turn into that but they haven't conditioned people yet.
I have to agree. Number of times it’s prevented me from running software I wanted to run: zero. Number of times it’s stopped me and said the equivalent of “are you really sure?”: a handful, maybe once a year on average.
And it’s not like I don’t use a gazillion third party apps and commands.
Same. I can see how it would look like a major problem if your only perspective was through clickbait headlines and angry comments from people who don’t use Macs anyway, though.
It reminds me of the distant cousin who lives out the countryside and prides themselves on not living in the city because the news tells them it’s a dangerous hellhole where everyone is getting mugged or shot on every street corner. When you immerse yourself in clickbait journalism the other side, whatever that may be, starts to look much worse than reality.
Apple does not support running other OS's on their hardware. This is bad in many senses but it is specially bad since it weakens competition and reduces incentives for Apple to improve their own OS, meaning it is bad even for their users in the long run.
If you choose to buy hardware from apple, you must consider that you're encouraging a behaviour that is bad for everyone, including yourself.
I'm not sure what you're talking about. Their bootloader explicitly supports other OSes. They make it easy to run Windows (even through a built-in app that helps you set it up). There are plenty of reasons to criticize Apple, but they literally don't do anything to prevent you from running another OS.
That’s true but that’s probably only so that it wouldn’t have been a subject when Apple Silicon Macs were released because Intel Macs weren’t locked.
In reality, the bootloader isn’t closed (yet) but the hardware is so much undocumented that it’s easy to understand that Apple doesn’t want anything else than their OS on your mac. The « alternative os » situation is actually worse than it used to be with Intel Macs and Apple is paying a lot of attention in never talking about this "feature".
IMO, they will just quietly remove this possibility on new generations when everyone will have forgotten that boot camp used to be a thing.
Eh, you may be right, but there's a big difference between "they are going to forbid other OSes by placing a software restriction where they explicitly permit things now" and "they already effectively forbid other OSes by not publishing developer documentation for proprietary hardware"--that's a tall order, and not a bar that many other hardware manufacturers meet either.
Like, could they lock down the bootloader? Sure. But that's effort they'd have to put in for minimal benefit at the moment. Opening up their hardware would be a lot more effort for questionable benefits (to Apple).
> they literally don't do anything to prevent you from running another OS.
Like not documenting their hardware? Like making Asahi Linux becoming a multi-year reverse engineering project that may possibly never achieve perfect compatibility?
> They make it easy to run Windows
On apple silicon without virtualisation? Sorry, didn't know that.
The point is that Apple could have easily locked down the bootloader and made it not possible at all to install something else. In designing the M1 hardware they explicitly went out of their way to make sure other operating systems could be installed and they’ve said as much. They took their smartphone SoCs and bootloader that never allowed alternate operating systems and added that feature in actively.
Technically Asahi Linux isn’t facing a much different situation than standard Linux distributions as they relate to x86 hardware. There are thousands of PC components that don’t provide any sort of Linux driver where contributors reverse engineer those drivers.
Sure, in the PC world a lot more vendors do voluntarily provide Linux drivers, and Apple will never to that for its hardware, and that specific point is a valid criticism.
As far as assisting in running Windows, my understanding is that the company that makes Parallels and Apple have some kind of relationship. Microsoft officially endorses Parallels.
You can complain about it being virtualization but it’s perfectly fine for desktop apps or even some more intensive apps. And it’s not really a very valid complaint considering that Microsoft doesn’t distribute a general purpose ARM distribution of Windows.
They aren't actively hindering that reverse engineering effort. They aren't _helping_ either, but I didn't claim that they were helping. For as long as I can remember, Apple's stance with Mac computers has been "We sell the computers to you in the way we think is best. If you want to tinker, that's on you." and I don't think that has materially changed.
Because computers don't boot the way they used to in the commodity BIOS era. The boot loader has to cryptographically check that it's valid operating system it's attempting to boot.
Well, Apple could follow industry standards, too. The argument was Apple approves alternate operating systems as evidenced by boot camp. That's demonstrably not true anymore.
Neither does any other hardware vendor, even the likes of Dell, Lenovo and Asus clearly state on their online shops that their laptops work best with Windows, even when something like Ubuntu or Red-Hat is an option.
> Gatekeeper will ever so slowly tighten so that people don't realise like a frog boiled in water is continuing to be true
Gatekeeper can be disabled. Given Cupertino’s pivot to services and the Mac’s limited install base relative to iPhones (and high penetration among developers) I’m doubtful they’d remove that option in the foreseeable future.
It really bothers me that Apple removed any convenient shortcut to bypass Gatekeeper like the old Control-click [1] hotkey. Apple's relentless ratcheting of the difficulty/annoyance of Gatekeeper has just about pushed me over the edge to completely disable it, despite the risk.
The ridiculous song and dance of "File is dangerous, delete it?"->No->Settings->Security->Open Anyway->"File is dangerous, delete it?"->No is getting ridiculously old after literally doing it a hundred times at this point. And soon enough Apple will inevitably come up with some additional hurdle like, idk, closing Settings three times in a row while reading a fingerprint during an odd numbered minute.
So in the name of "increased security" they've needlessly turned it into a binary thing where it's completely unprotected or accept my own computer that I paid for will deliberately waste my time constantly. It makes Windows 11 seem elegant in comparison where all I need to do is run Win11Debloat once on install and it gets out of my way.
Open Automator and make a droplet or service that runs `xattr -d com.apple.quarantine` on whatever file you give it. There’s a recursive option for xattr that I can’t remember but I add that one on too; I’ve unzipped stuff that had the flag and somehow ended up with hundreds of files I couldn’t open without GK prompts.
I didn’t say it was invalid, just that it was needless. When I bought the laptop Gatekeeper was a tolerable nuisance and I was fine with the tradeoff given the security benefits.
The removal of the hotkey (which also required changing a setting before it worked at all) didn’t actually make it harder for a regular user to access, just 5x as aggravating every time it's necessary.
If they made developers go through some long and tedious process to re-enable it I would grumble but understand, but the only solution to get back to the 2024 status quo being entirely disabling a critical security feature certainly doesn't benefit me in any way.
> The ridiculous song and dance of "File is dangerous, delete it?"->No->Settings->Security->Open Anyway->"File is dangerous, delete it?"->No is getting ridiculously old after literally doing it a hundred times at this point. And soon enough Apple will inevitably come up with some additional hurdle like, idk, closing Settings three times in a row while reading a fingerprint during an odd numbered minute.
> So in the name of "increased security" they've needlessly turned it into a binary thing where it's completely unprotected or accept my own computer that I paid for will deliberately waste my time constantly.
Gatekeeper isn’t changing. Homebrew’s policies are changing.
It also only applies to casks. If you don’t use homebrew casks, nothing is changing for you.
You can also disable Gatekeeper entirely. It’s very easy.
I don’t see what you think you’re predicting, unless you’re trying to imply that that Gatekeeper is a conspiratorial plot to turn your Mac into an iPhone. I predict we’re going to be seeing those conspiracy theories for decades while it never comes true. Apple doesn’t want to destroy the market for their $5000 laptops so they can sell us a $1000 iPad as our only computing device or send customers to competitors. This is like a replay of the sky is falling drama when secure boot was announced
Homebrew is not really pro in any way: they force updates, deprecate old software that is still widely in use, the maintainers are always very combative and dont allow any discussions or other opinions.
In the end it's a package manager for consumers that hand holds you and is not really useful in a pro context.
I've been meaning to jump to macports anyway, maybe ill do it now...
So-called “homebrew” has only ever grudgingly provided the barest minimum of hooks to locally build your own variants of their packages, and compares most unfavourably to, say, maintaining your own easily-rebased fork of a BSD-style ports tree. Don’t even get me started on its janky dependency resolution, versioning, “services”, and lifecycle.
The hostility and self-righteousness from the maintainers in the thread linked above just adds to the general shittiness of using it at all, and yet somehow it seems to be the lowest common denominator choice for far too many teams I’ve worked with, I suppose by sheer inertia.
I started on Macports 20 years ago, switched to homebrew because it was the new thing, and this year switched back to Macports on a brand new M4 mini, after having this gnawing feeling that I should have never switched after installing Macports on a PowerBook G4 running Tiger and building something relatively modern from source without any problems.
As someone who migrated from macports to Homebrew, I'd like to see a third option (or maybe re-investigate macports again to see what's changed recently).
Homebrew's insistence on leaving OSes behind that they deem to be "too old" is becoming a problem as the years click by. One of the reasons to use third party software and a third party package manager is to avoid Apple's own insistence on abandoning old OSes. Homebrew following their example is very disappointing.
EDIT: From the linked issue:
"Intel support is coming to an end from both Apple and Homebrew."
Deeply, deeply disappointing. I know Open Source doesn't owe us anything, but this seems like a terrible turn for what was once great software.
Nix is sort of that third option, though I really wish there was a well-documented way to use it on macOS as purely a binary/source package manager. A lot of stuff I read online goes into setting up nix-darwin to manage desktop settings and etc. and I just don't need or want that.
That being said, if you haven't used MacPorts in years, I'd say it's worth the jump. I recall moving from MacPorts in the first place because Homebrew was faster and allowed for customising packages.
When I switched back to MacPorts again, it was because Homebrew had become slow and no longer allowed package customisation. Now, MacPorts is much faster and has the variants system for package customisation.
Thank you for this helpful information. It might be worth a try. I initially moved to brew because it was "new", because I liked the command line interface, and because it seemed more "segregated" from the rest of the OS's files (/usr/local/Cellar and so on). But it's increasingly aggressive messages reminding me I am a second-class (or third-class) citizen due to the age of my OS is really off-putting.
I actually migrated from Homebrew to Macports after ending up in dependency hell in Homebrew with Postgresql + Postgis, and not being able to fix this properly even with my own brew recipes.
So for now that works a lot better in Macports. The portfile stuff needed some digging to understand, but that's doable.
Not sure what made you move from Macports to Homebrew. (Should I worry?)
"Homebrew's insistence on leaving OSes behind that they deem to be "too old" is becoming a problem as the years click by"
Indeed! I have a VERY usable Macbook Pro from 2015. Even with the newest version supported macOS version (11) Big Sur (which is still quite modern) it doesn't have any binaries for apps, which means it has to compile every single app and dependency.
I managed to update to macOS 14 (with the help of OpenCore Legacy Patcher).
But this just buys me one year to use Homebrew. Next year they will retire macOS 14.
And my machine is still very usable, but it will become junk from a developer perspective unless I have homebrew (or something similar).
It annoys me because I think this problem is fixable. Either community repos or more donations to homebrew to compile apps for older macs.
It's too bad that homebrew adopted the "Apple Attitude" around dealing with legacy OS versions. I don't recall ever seeing a message while working in Linux saying "Oh, you're using an OLD version of Linux, that's unsupported! You're a Tier-3 Loser and we don't guarantee this is going to work!"
Even developer tools on Windows tend to be fairly graceful about you running Windows 7 or whatever.
Somehow Apple and their entire ecosystem has adopted this "Latest Version Or GTFO" attitude towards users and developers.
How much are you willing to donate before concluding it's more efficient to just buy a new MacBook? Even the cheapest models now are faster, more energy efficient and more secure.
You don't have to throw the old one away if you can find a use case for running old software but I don't think there are many people running 'power user / developer' like tasks on old hardware, especially if their jobs depend on it.
im talking about developers for example, that may need specific/old versions of php or node or whatever, which then get deprecated and uninstallable via brew as soon as they officially reach EOL. Or once installed, get forcefully and inadvertently updated by brew.
On the other side is some consumer who uses brew to install youtube downloader and doesnt care about versions/upgrades, etc...
If you are a developer who needs a specific old version of PHP or Node or whatever and you're not using Docker then I have great news for you on how you can solve your problem.
yes, docker is a great solution nowadays for this problem, but it wasnt always like that.
In PHP land there is a tool called Laravel Valet, which relies heavily on homebrew and lets you switch PHP versions on the fly directly your system.
I just remember how much of a pain it was to set up because of homebrew's unnecessary restrictions and deprecations.
But once done it worked quite well.
I personally use and enjoy Homebrew for most of my development tasks. The thing I would not use it for is to exactly simulate a specific combination of tool versions.
Yes. The package manager's job is to give you some sensible version of some useful common standardized thing(s) you want to use. There might well be some legacy/current/edge options, but overall you are putting your trust in their judgement and assuming that they'll do something at least vaguely sensible.
If you want something specific than that: the package manager cannot help you here. This is no longer some random thing that you just use; it's one of your product's honest-to-goodness dependencies. You can't outsource this any more. You need to make your own arrangements to ensure that the specific version required is in use.
It works until PHP officially EOLs the version. Then brew stops supporting it and you have to install some finicky 3rd party taps/repos to get the older versions. A huge pain...
In the real world there are still apps running PHP 7.4 and even older!
Homebrew not allowing users to install EOL versions of software with no security patches or updates is a _good_ idea. Just because a fraction of a tiny minority needs some ancient version of PHP doesn't make it a good idea.
yea, that's why it's not "pro" grade, and that's my point.
"pro" users need EOL version support because sometimes some client still didn't want to update his age old web app the newest node or python or whatever. sometimes it's not up to the dev himself, and he needs to make money either way.
so in the end brew makes decisions for the most common denominator, and that will be the user that uses it to install youtube-dl and nothing more.
“Pro” users are using containers, venvs, version managers (nvm, rvm, etc.). They definitely aren’t installing project-specific stuff directly to the system.
> Homebrew is not really pro in any way: they force updates, deprecate old software that is still widely in use, the maintainers are always very combative and dont allow any discussions or other opinions.
Hehe, the classic rude and mean behavior from homebrew maintainers.
I get their motivation to remove the flag. In fact, it has always been better to run xattr in postinstall, this way the binary is free from quarantine even after updates.
But the way they communicate with people is unacceptable and just unnecessary.
Reading that discussion, I was very surprised at MikeMcQuaid’s reaction to xtqqczze’s concerns, which were calm, brief, and valid. In response, Mike was a dick.
Maybe it’s totally understandable that being a maintainer for the biggest mac package manager conditions a knee-jerk asshole response in a person.
There's a misunderstanding here what the issue tracker is for in Homebrew. In some projects, it's for free-for-all discussion. That's great if those projects want to use it that way.
In this issue's case, you have someone in leadership (p-linnane) communicating that work needs to be done, a maintainer (carlocab) communicating what needs to be done to make this change. xtqqczze's attempt to get us to move backwards on an already made decision doesn't help anyone. We have a discussions forum (and, well, the rest of the internet) for discussion of the pros and cons of decisions made. There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not.
As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests.
Go read through some merged pull requests some time and you will see moderately to very positive responses from me. That's because that's the work that keeps the project alive. It has almost died several times in the past and I've kept it going. You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.
Thanks for the response. Yes, I think some clarity about the purpose of the issue tracker would help someone unfamiliar with the project's maintenance better understand the conduct of the maintainers. If it is only for coordination of work tasks and not discussion of whether the work should be done, it would seem natural to have somewhere else where the discussion of the merits occurs.
> drive-by negativity by non-code-contributor users is the biggest existential threat
I do believe this, and it's what I was getting at with my "conditions a knee-jerk asshole response" comment. From the outside, I saw someone who wasn't being negative, but just seemed to have unaddressed concerns about the impact of the change. You, however, have been conditioned by hostile users over your many years of work to interpret this as negativity, because other, ruder people pile on to the valid concern in unhelpful ways, or the person with the concern wasn't willing to listen at all and just used a veneer of calm rationality to be a stick in the mud.
The point is, I get why you would be this way, but also that it doesn't look very good from the outside looking in. I know that you are doing unpaid labor and so nothing is owed, but still, both can be true.
I know some people don't like it, but I've always found discussions that are locked to collaborators only to be totally understandable for this reason. If you find yourself making "I know more about x than you ever will" comments to a person, you should probably instead just disregard them and carry on. Likewise, you do know more about x than I ever will, so you should probably just disregard me and carry on.
> There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not.
You could have just said this (maybe you did when linking the code of conduct) instead of writing a paragraph of confrontational arguments and it would have looked way better imho.
> You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.
If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.
Yup, you're right, I should have. We will adjust the CONTRIBUTING.md accordingly.
> If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.
I didn't say every OSS project, I said projects like Homebrew. I know that Homebrew would be dead without many of my personal interventions. You can believe me or not but, unless you're a Homebrew maintainer, it's unlikely your opinion about what happens behind the scenes is informed.
> As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests.
your explanation did nothing to speak to being a dick, did not attempt to apologize, only tried to justify the poor behavior.
I don't think I am a dick, I guess that went without saying.
I'll take critique from other maintainers who have done as much or more open source work for similar returns over similar time periods. Funnily enough, I'm friends with many, and they are supportive the vast majority of the time instead of critical. Maybe that's because they can relate and you cannot.
No one thinks they are a dick. But you are. At least in many instances as many of the comments here and elsewhere point out. I had similar experience trying to start a discussion about something in one of the Homebrew repositories.
The fact that you have many friends who confirm your bias of not being a dick...means exactly nothing. You have people telling you your words made them perceive your comment as being arrogant/blunt and your reply is: I'm successful open-source maintainer and have many friends who think I'm not arrogant and I only take critique from them. Have it your way. But in my eyes, you're being a dick. (Don't misinterpret this as my judgement of your engineering skills. I love Homebrew and it's an incredible feat. Congrats.)
If you love Homebrew, maybe you might want to consider if repeatedly calling me a dick or arrogant/blunt is a particularly nice way to treat someone who spends their spare time building software you rely on.
This, this is being a dick. Holding your project hostage because you want to flex your power over someone. It's entitled behavior. Glad I moved to MacPorts years ago.
I don't understand what this means, although I've read the whole thread. Does this mean people won't be able to use Homebrew to compile software from source (and run it)? Does it mean that they'll be able to use Homebrew to compile software from source, but not download prebuilt binaries (and run them)? Does it mean that they'll be able to download prebuilt binaries, but only run them if they're built by a developer that Apple has blessed?
I do understand that the effect is only to make Intel Macs adopt the same behavior ARM64 Macs already had, but I don't understand what that behavior is.
I see that someone named andrewmcwatters has posted a [dead] reply to my comment that doesn't answer my questions, just repeating the same jargon from the bug report that I don't know the meaning of.
> Does this mean people won't be able to use Homebrew to compile software from source (and run it)? Does it mean that they'll be able to use Homebrew to compile software from source, but not download prebuilt binaries (and run them)?
No, and no. This only affects Casks, which are prebuilt .app bundles that Homebrew has no part in building (either locally or remotely). Formulae (source builds) and bottles (builds of formulae within Homebrew) are not directly affected by any of this.
The answer to this is nuanced because of how it works, but the short answer is yes: you can build random things from source and run them, and you can download random binaries from the internet and run them. The only thing that Homebrew itself is changing is that it no longer provides an automatic way to lift the quarantine bit from a specific subset of binary packages (casks).
For Mac, yes and no. IIRC you don't need a developer's license to build and sign software for yourself. But you do need one to distribute pre-built software.
You can still run unsigned software, but you need to approve 2? prompts, and also allow exception for every executable by going to Privacy & Security tab in settings.
IIRC there is a CLI command for achieving the same.
You can’t run unsigned software on Apple silicon. Note that when you build your software if you use Apple’s tools it will inject an ad-hoc signature into the product.
You very much _can_ run unsigned software on Apple silicon. At work my department has a bit less than 50 engineers with Macs (M1 to M4) and nobody complained that they can't build and run our product (using GCC from Homebrew, not Clang from Apple). But it involves some jumping through hoops, yes.
As mentioned above you have to approve the binary two times (at least), being careful the first time because the dialog popup offers to remove the binary. Also since our product has some networking to do one has to mingle with firewall settings to allow the binary to do the networking.
To check I did this: removed the signature (LC_CODE_SIGNATURE section) using lief Python package (no affiliation, just looked suitable for the task), checked by otool that the section is indeed gone, started the binary - it worked. The spctl said that the binary is "rejected", but it says so about every non-Apple binary I checked on my machine so not informative. The codesign tool shows "is not signed at all" on the binary with stripped signature.
I'm not too well-versed in OSX system/dev tools, so if there is a more correct/precise method of checking the signatures I'd very much like to know.
The signature that gets added is vaguely a hash of the binary. You probably want to look at the UUID that gets injected into your binary instead of this.
This is my understanding after a moderate dive into the issue.
Binaries in macOS have a signature and a set of flags. One of those flags is the "quarantine" flag that, when set, refuses to run your binary until some extra security checks have been performed (checking against a malware database, asking the user for consent, etc). Once this check is done, the flag is unset.
Usually this flag has to be set by the app you use to download the binary - in most cases it would be the web browser, but here it would be Homebrew. They used to provide a --no-quarantine flag to prevent this bit from being set, but given some changes both in macOS and in the Homebrew project it's been decided to stop offering that option. You can still unset the flag by hand, no root required, but that's on you as a user.
I believe this is a strong nudge in the direction of "for a user-friendly experience you should sign your binaries", but not a full ban.
When they closed the discussion, they explicitly welcomed people to talk about it outside their issue tracker:
> Our issue trackers (other projects may differ) are used to track the work for maintainers or soliciting community contributions. They do not exist for people to debate the merits of decisions already made. We have Homebrew/discussions (and, well, the rest of the internet) for that.
They just don't want discussion about the merits of a settled decision to interfere with their work tracking when they provide a perfectly good discussion forum[1] for that.
There'll be some way to make it work, possibly indeed that the Homebrew people get approved by Apple, because MacPorts works ok, and it seems to be downloading precompiled binaries (and if it isn't, then my Mac is actually faster than I've ever seen it run). And if MacPorts can do it, presumably Homebrew can do it too.
Building stuff yourself remains an option, even if you're unapproved. The toolchain pops the codesign step in at some point, I guess, and if you built it locally then you can run it locally. I just did cc -o on some bit of code on an Apple Silicon Mac, and the resulting binary did run.
(You can also run binaries that unapproved people built on other systems, but it's a minor pain, as you have to explicitly opt in to allowing each runnable file to run.)
MacPorts and Homebrew behave identically here: precompiled binaries are not affected, only .app (and similar) bundles.
(People find this confusing, because Homebrew does a superset of what MacPorts does: it distributes both source/binary packages and it distributes "casks", which are essentially a CLI-friendly version of the App Store and come with macOS's additional restrictions on applications. This only affects casks.)
The hierarchy is actually a little more complicated than this. MacPorts can and does build open source GUI apps (in fact it largely rejects binaries for them, preferring to build them directly). Homebrew rejects GUI apps from being built from source. Because Homebrew downloads apps from the internet, it makes them with the quarantine attribute, which means more apps that it handles will be flagged by Gatekeeper.
I see, thanks! Is cc installed by default? I remember when my ex-wife had a Mac she had to sign up for Apple's developer program to get compilers installed.
No idea what you get out of the box, or what /usr/bin/cc actually is and does, but it looks like the underlying compiler is the clang that came with Xcode, which I installed from the app store. I do have an Apple account, but I don't think it's signed up to Apple's developer program... at least, probably not? I'm not paying them for this, anyway.
All it means is that applications downloaded/installed via Homebrew will no longer be able to bypass the Gatekeeper signing/notarization requirement on Intel platforms (already is the case on Arm).
If you didn't need to install a cask with this flag before you won't be impacted by the deprecation.
The loss of the --no-gatekeeper option isn't that big of a deal. It just removed the com.apple.quarantine xattr from the installed cask (which you can easily do yourself, or just allow the app from System Settings after Gatekeeper blocks it).
The more impactful change is the move to require all casks[0] (not just new ones) to pass Gatekeeper checks (so signed and notarized through the Apple Developer Program)[1][2]. There are a multitude of open-source applications which aren't signed and notarized through the Apple Developer Program (some due to the $99 per year cost, some due to needing to provide a legal identity and having that in the certificate, some who object to needing to do it at all). What this means is that you'll have to install these manually or use a 3rd-party tap (package repository) to install them.
Of course, Apple could solve this by providing a way for open-source projects to sign and notarize their apps without having to pay $99 per year and associate a legal identity. They've already got Xcode Cloud, they could allow use of that to build, sign, and notarize only from the publicly available source.
[0]: These are GUI applications (i.e. .app), where Homebrew downloads the official build of the app. CLI tools are done differently (the Homebrew project builds these from source), and nothing's changing there.
Can someone explain why disallowing Gatekeeper bypass via Homebrew is related to macOS disallowing unsigned ARM64 binaries to run? My understanding is that `—no-quarantine` just removes the `com.apple.quarantine` attribute from a downloaded application. If the application is unsigned then removing the attribute wouldn’t allow it to run anyways. There’s no way to disable the signature check because it’s a kernel level check. However, macOS will accept an adhoc signature. Because of this, to me it seems like Gatekeeper bypass and unsigned software are orthogonal topics. No matter if I remove the Gatekeeper signature or not, unsigned code still won’t run unless I add an adhoc signature. On the other hand, if I distribute software with an adhoc signature, macOS wouldn’t prevent someone else from running it as long as they remove the quarantine attribute. Am I missing something?
The only thing signaling Gatekeeper to do the deep checks and also to block execution is the presence of that file attribute. When GK was first introduced in Tiger that’s literally all it consisted of; a warning/reminder that “hey slack jawed user, you downloaded this executable from the internet, be sure you trust it!” and once they said OK, the attribute was cleared and you’re not gonna get bothered again.
The AMFI checks happen on every execution of any executable. Xprotect is also running execution based checks on first run and randomly later on to check for signatures of known malware. Gatekeeper is the umbrella term for all of this on the Mac, but its still kicked off, to the user at least, as that prompt “hey champ you downloaded this from the internet and the developer didn’t want to upload this binary to Apple for scans, move it to your trash”.
Long story short, if you remove the quarantine bit, you can run whatever the fuck you want so long as Xprotect doesn’t detect anything in its YARA rules files.
1. Does this mean it’s a little disingenuous for the Homebrew maintainers to claim that this change has anything to do with app signing, given that they reference the impossibility of unsigned applications in the issue?
2. Does this mean that if a developer self-signs their app but doesn’t notarize it that it will meet Homebrew’s criteria of “passing Gatekeeper checks”?
1. Yes. (Either that or they know something we don't about Apple's future plans.)
2. No, as Gatekeeper checks both for a valid signature from an Apple Developer Program certificate as well as notarization.
It seems the maintainers are very eager to lock issues and threads on GitHub that receive any pushback to this decision. Where is this coming from? I thought Homebrew was pro-user software, which requiring Apple's approval to run software on my computer is ostensibly not.
if you read any old issues on the homebrew github you can see how these maintainers are always very aggressive and anti-discussion, especially the main guy.
Yeah, I’ve been noticing an alarming number of casks marked to be depreciated… at the same time gatekeeper has gotten so restrictive it won’t let me (easily) open a video files that I downloaded from the internet
Yeah, I noticed the same on my Macbook. I mainly use it for theater stuff (Qlab) and remoting into my main Windows desktop environment. I just stopped doing some of the workflows on Mac and do them on Windows because I didn't feel like trying to figure out why macOS wouldn't let GIMP open an image I downloaded from the internet. So dumb.
- try the usual tricks (holding alt and right clicking, i guess), no
- drag and drop file into Code, no
- right click>get info, lo and behold: the entire file contents displayed in the Get Info preview pane for me to copy
I'm actually getting a Windows laptop to do some testing on and i might just abandon Mac for the most part after that. Eating up five minutes of my day to figure out how to edit a file i created myself is just too much sometimes
I ran into this exact same thing recently with CSVs downloaded from my own app. I tried a few different filetypes and was baffled how seemingly any filetype I downloaded triggered Gatekeeper regardless of the app I set to open it (including stock apps).
I eventually found on Reddit that setting the default via the Get Info dialog was the only path that worked, so now I can click a CSV and open it in VS Code without needing to send Apple my passport and fingerprints. I keep seeing mixed opinions whether it's a bug that Get Info associations work differently vs the right click context menu, or if it's a deliberately obtuse garden path like the Settings/Open Anyway routine and "working" as intended.
Either way I hate it but it would be slightly more forgivable as a bug (assuming it was then fixed).
Huh? JSON? Did you insert executable preamble bytes and chmod the file to execute or something? Where is this file? Can you post a link?
My work issued MacBook is incapable of running unsigned binaries enforced by the MDM kext, and I do all sorts of development all day long. Occasionally I have to resign a precompiled dylib if it was compiled on a coworkers machines, but that’s it. I have never seen anything like you’re describing.
Alacritty is seemingly affected by this, which sucks for people who install it from homebrew because there's no way the developers are going to shell out to Apple for the signature.
You can either use the tap which is posted in another one of my replies, or install it from the releases and remove the quarantine flag yourself as describes in both the issue I linked and my blog post from 4 years ago. Or you can build it yourself with `make app`.
I don't know much about macOS these days, but I was under the impression that Casks were for applications, and normal formula were for things installed in your PATH as standalone binaries. The .app needs a few extra things bundled up.
I think of homebrew as a curation service; it lets me name a piece of software and install it without having to any special diligence on it. In that use case, I _want_ them to enforce code-signing requirements; that reduces the risk that some software-supply-chain compromise will spread to my computer.
I do want the ability to install unsigned software, either because I wrote/compiled it myself locally and can't be arsed with signing, or because I'm getting it from a non-public source that doesn't want to share a copy with Apple, or because it's from a developer I trust who can't be arsed. But I never want to get unsigned software _from a curation service_.
Protecting the user from things they don’t realize are apps or new apps on general is important.
But the amount of overreach in gatekeeper to try and make the failed Mac App Store profitable and milk $90 a year at the expense of apps users want to run is egregious.
I personally think $90 per year is reasonable and not 'milking' - I don't think it's large enough to suspect Apple making bank on this, but does represent a certain level of commitment from a dev and prevents users from spamming developer accounts.
The only scenario in which I think it's excessive is broke student devs, not sure if there's a scheme to waive the fee for them.
Not allowing regular folks to run unsigned apps is something I also agree with -though I would love if Apple allowed us to trust third-party root certs so that apps would be both signed and free of Apple's control.
I find it hard to believe that charging people is the only way to stop people people from making multiple/spam accounts. It seems like it's just the easiest and most profitable. And, if it is the only option, then why does an account that has been paying Apple $90 a year for a decade still need to keep paying them: it's seems unlikely to be a spam account at that point.
>Not allowing regular folks to run unsigned apps is something I also agree with -though I would love if Apple allowed us to trust third-party root certs so that apps would be both signed and free of Apple's control.
Rolling up the ladder much? Most who can program nowadays in one form or another owe the learning experience to the fact we could write and run unsigned apps without nannery measures like Gatekeeper.
I flat out refuse henceforth the do anything that encourages mind share on fundamentally anti-user, gatekept platforms.
The reason you can go anywhere on the internet and trust at least that the website you're viewing is in the form the creator intended is that HTTPS exists - which requires that a trusted entity has issued a cert that proves the domain is indeed held by the person and what goes on in that domain hasn't been tampered with externally.
That is the default on the internet, and even enforced. I'm merely saying that for average users (or power users even, who understand the risks) the default should be that the same guarantees apply to desktop apps as well (especially considering those usually have far more access).
HTTPS shows that such a world where people live with this restriction is possible and practical, and far from the jackbooted tyranny you describe.
The contrast between the steadily shrinking freedoms in Apple-land and the open computing approach underlying all today's the Valve announcements is fascinating.
I switched from Linux to macOS with osx 10.2.8 because it was a much better unix desktop experience. Lately, more and more I've been feeling a lot like linux is a better desktop experience.
Yeah yeah, I'm sure there's a whole line of people who'd like to mock this entire decision, but I assure you that back then, a lot of us would rather use our desktop OS than fix our desktop OSes broken 802.11b, audio, graphics, etc.. And back then, osx shipped x11, and you could `ssh -Y` and `xnest` and all that fun stuff. Plus linux (and other unixes) never left my side for headless work.
Top this off with all the Android lockdown, and I feel like linux and FLOSS has maybe never been as important as it is now.
It may be Apple policy to prevent users from doing what they want because "security" is the most important thing for a their bank/shopping terminals. But I thought the whole point of using homebrew was to empower the user to use Apple devices like a normal computer without the hassle of having to do it manually? The developer has made it clear this is not the use case and that it helped with it was unintentional and undesired. The actual use case for homebrew remains unclear given this new information.
Well, 2. is what the people are asking for but aren't getting. They want deprecation and a ENV flag to enable. It'd be enough. But even that isn't being allowed which is weird for a power-user program. I can't help but think, "Don't obey in advance."
They're deprecating it and removing it. What is required is deprecating it and leaving it in (with env flag to enable) till it actually breaks rather than obeying in advance.
For a quick background, Apple doesn't allow the typical quarantine bypass of Gatekeeper for ARM64 binaries. It must be digitally signed to run. And Intel based Macs are a dead end with macOS Tahoe being the last OS released for them. So, brew is disabling the --no-quarantine switch in their next major release or so.
From the post: "What alternatives to the feature have been considered?
None. Macs with Apple silicon are the platform that will be supported in the future, and Apple is making it harder to bypass Gatekeeper as is."
While it is true that macOS requires binaries to have a digital signature, that can just be an ad-hoc signature. Other than that, not much has changed. Gatekeeper (and the ability to bypass it for specific apps/binaries) works much the same for unsigned Intel binaries as for ad-hoc signed Apple Silicon binaries.
This has turned into a such a pain point for me I'm probably just going to ditch MacOS on my next hardware refresh and insist on a Linux-based workstation. I already use Linux for everything else, changing for $DAY_JOB is trivial.
Hmm. I use arm64 macports instead of homebrew, and as far as I know, I download prebuilt binaries from macports without issue even on Tahoe -- are they signing them with an approved account? Or did they force me to build everything from scratch, like the old days, and I haven't noticed?
This doesn't affect most prebuilt binaries. It specifically affects what Homebrew calls "casks," which are redistributions of .app bundles (which come with additional restrictions via Gatekeeper, unlike a "simple" binary).
Now, unsurprisingly, more and more distributers are falling in line, and it's all mostly theater.
Where is our modern Stallman, how have we let these massive platform OS providers assert this much control over the developer ecosystem.
They collect $99/yr for the right to give away free software! Madness. And they lie about the safety of the system. How about focus on keeping the OS secure and maintaining process isolation, and let users run what they want.
This is true, but also misleading: Homebrew did what every major "distro-level" package manager did, which was conform to PEP 668[1].
(This, as it turns out, was a great idea. A single global shared environment that pip used by default was one of the single greatest sources of user frustration in Python.)
Homebrew is famous for making life hard for users. It makes "design decisions" that often conflict with users' needs, all in order to live up to the personal preferences of the project leads.
Personally I use asdf to manage my software on Macs. It too has also changed its design recently to become user-hostile (the command-line tool no longer prints the options for the commands, and it's full of bugs since a recent major version change).
For anyone looking to make an alternative to Homebrew: check out asdf's plugin system! It is insanely easy for anyone to make an asdf plugin, install it, use it. It's just a directory of plaintext files/scripts somewhere on the web. I made a couple plugins for unpackaged apps within like 30 minutes of learning how plugins worked. Very "unix philosophy" (in a good way)
(aside: I'm not a "Mac person" (forced to use one by work), so I know this is an unpopular opinion, but Macs feel worse to use than either Windows or Linux. At least Windows has WSL2 if you like command-lines (or PowerShell if you're into that). OTOH Macs ship with insanely outdated incompatible tools, and the 3rd-party options are annoying as hell. Why do technical people keep using Macs?)
Apple loves to change which tools they ship, too, it at least have for the last few years as system updates were routinely breaking our build scripts at work, mostly when Apple would replace a GNU tool with a BSD tool without warning i think.
I agree though, Finder is a joke, the macOS system preferences has gotten incredibly cluttered and hard to use, the ever stricter code signing and download-opening restrictions are frustrating, and i can't even just install and run the docker CLI--docker on Mac requires Desktop and commercial use of Desktop requires a license.
All 3 systems have things about them that annoy me, but I'm with you that Mac is my least favorite. And it kinda sucks because the global text shortcuts (command-arrow, command-delete etc) are really handy and hard to replicate on other systems, and at least traditionally it's been a very pretty and well integrated desktop, the system itself just drives me up a wall.
> Apple loves to change which tools they ship, too, it at least have for the last few years as system updates were routinely breaking our build scripts at work, mostly when Apple would replace a GNU tool with a BSD tool without warning i think.
It's a licensing issue; Apple has never shipped GPLv3 software. This has been discussed dozens of times on HN.
Of course you can use Homebrew to install a GNU toolchain to your heart's content.
Just FYI: macOS has been a BSD-derived operating system from the beginning, using stuff from FreeBSD, OpenBSD and NetBSD on a Mach kernel. It’s a certified UNIX™ operating system.
And because GPLv3 is incompatible with how Apple operates, they ship versions of pre-GPLv3 software like Bash 3.2.
Apple now ships openrsync [1] as a replacement for rsync due to licensing issues.
Well there's now an MIT-licensed Rust rewrite of GNU coretools. Maybe in a few years they'll ship that, and we won't have to faff about with crappy 3rd party solutions. (I mean, seriously, when Windows ships with better dev tools than you? That's embarrassing.)
I'd have sworn they used to ship nano instead of pico; but i could be misremembering, regardless, the behavior of the tools changed and the only solution was install the gnu version from brew (and later, move the whole build to docker when Apple broke something else that used to work fine on both Mac and Linux)
> i can't even just install and run the docker CLI--docker on Mac requires Desktop and commercial use of Desktop requires a license.
That's not on Apple. Docker needs the Linux kernel (for Linux containers), so it's no different to needing something like Docker Desktop to use Docker on Windows. Yeah, Docker changed the license on Docker Desktop, but there's plenty of alternatives (Podman Desktop, Rancher Desktop, Colima, Apple's own container tool, or just running a Linux VM in Lima).
(I may be wrong here but) under the hood Docker on macOS runs a small Linux VM where all containers live, exactly because containers are basically Linux namespaces on steroids so not portable 1:1 to anywhere.
It's somewhat bizarre to me for this to impact "casks" but not "bottles". Bottles are all ad-hoc signed and presumably have the quarantine attribute removed manually since I do not see Gatekeeper warnings for bottles I install via Homebrew.
Downloaded files that are not executable or contains any executables in their archives don’t receive the quarantine bit. Non-quarantined executables don’t even require the ad-hoc signing as far as I know. It’s there to prevent lateral movement of executables: not to allow it to run on your computer, but to prevent it from running on someone else’s.
Breaking the momentum and institutional adoption of homebrew is non-trivial but the developer community needs to band together unless we want to be slaves to Apple's whims forever. The current homebrew maintain Mike McQuaid clearly had no interest in listening to users.
Mike McQuaid has been doing this a long time and there are more egregious examples in the past. I got off the Homebrew train when Little Snitch caught Homebrew phoning home without my consent and the response from him was, the developers have already decided to implement telemetry in an opt-out fashion and any pushback to that already made decision is "abusive" to the maintainers.
The Homebrew maintainers are not trustworthy. Don't use their software. If a fork was going to be feasible, it already would have happened.
Unfortunately, requires root, no Intel mac, no reuse of the large brew manifest library... The first 3 opened issues capture the core deficiencies perfectly
Does this mean if I publish my own cask for pre built binaries, people will no longer be able to use it unless I do something with Homebrew's Gatekeeper?
If yes, this sounds a lot like the android side loading the Google just reversed
"Locking this thread. Not interested in arguing the merits of this. It's already been communicated to third parties."
Well!
Note: I think one problem of homebrew is called ... Apple. That is, they depend on whatever Apple decides.
Granted, this is similar to Microsoft; and to some extent to Linux, though people can make more modifications on Linux normally.
I am a Linux users so this does not affect me, and I also wrote my own "package" manager (basically just some ruby scripts to compile things from source), but at the same time I also think that at the end of the day, the user should decide what he or she wants. This is also why my scripts support systemd - I don't use/need systemd myself, but my tools should be agnostic, so I don't project my own opinion onto them.
There is of course a limitation, which is available time - often I just lack time to support xyz. But I keep that spirit alive - software should serve the human, not the other way around. (I have no substantial opinion on the feature itself here, that is to me it seems ok to remove it; the larger question is who dictates something onto users and what workarounds exist. Do workarounds exist? From reading the issue tracker, it seems the homebrew maintainers say that there are no workarounds, and thus it should be removed. If that is true then they have a point, but people also downvoted that, so perhaps there are workarounds - in which case these should be supported. I really don't know myself - to me apple is more like a glorified Windows, so basically the same. All software should be liberated eventually.)
To clarify, the macOS kernel requires a signature on all Apple Silicon binaries, but this can just be an ad-hoc signature. Ad-hoc signed Apple Silicon applications are treated much the same as unsigned Intel ones.
Technically true, but misleading. The macOS kernel won't execute an Apple Silicon binary that doesn't have a signature, but as Apple documents, an ad-hoc signature is enough to meet that requirement. That won't get you past Gatekeeper, but that's no different to how it is with unsigned Intel binaries.
I use Nix for my CLI needs but homebrew for GUI programs, anyone know of any good alternative? A lot of casks will be removed, like mktvoolnix-app (the GUI program, not the CLI tool). Also this Mike guy is insufferable.
I can run whatever I want on my Windows and Linux machines. I wouldn't put up with this, but I guess some people really feel they need their silly fruit computers.
If I understand the issue correctly, it appears that this change primarily impacts casks on macOS. In fact it looks like it may only impact casks. Casks are used to install binary packaged software, often in the form of a dmg or pkg file on macOS. Most people I know are not installing too many casks, and most of the ones I've seen install signed binaries anyway. The important thing for me with this is that it doesnt appear to impact homebrew's ability to download, compile, and install open source software. And that is the main thing I use homebrew for. I believe that is true for most people too, but I fully expect to learn very quickly if there are a bunch of taps in use by people that distribute unsigned binary installers of software for macOS. :-)
> Most people I know are not installing too many casks
Casks are the only things Homebrew does that some other package manager available on macOS doesn't reliably do better. Nix, Pkgsrc, MacPorts, and (and now Spack) all have better fundamental designs; sane, multi-user-friendly permissions; and enough isolation from the base system that they break neither each other nor manually-installed software.
I use Homebrew exclusively tucked away in isolated prefixes, only to install casks, and without ever putting any binaries it installs along the way on my PATH. I don't remember which programs it is, exactly, but I do use a few that are unsigned.
It also doesn't seem to me that the signing process is as vital in determining actual risk as the curation and moderation processes involved in maintaining "third-party" software distributions like Homebrew or Debian or whatever.
`--no-quarantine` in particular is one of the conveniences that makes Homebrew casks useful. If I have to give my consent anew for each app update, I might as well install the apps manually and live in the usual auto-update pop-up hell.
> Most people I know are not installing too many casks
I did a wipe and install of Tahoe like 2–3 weeks ago and used a Brewfile [1] I've had for years to install ~30 casks via Homebrew, including from the App Store, not to mention 50-60 formulas.
As of today, I have 44 casks.
[1]: https://docs.brew.sh/Brew-Bundle-and-Brewfile
I do something similar. I bootstrap all my new installs with brew cask https://github.com/fastily/autobots/tree/master/macOS/setup
I bootstrap it using Brewfile (plaintext file read by Homebrew), which supports Casks too.
Same here.
Probably easy enough to write a script that will iterate that list and run the proper xattr command to remove each from quarantine.
I haven't used Homebrew in a long time, but if I ever did it would be in the way that you describe (so far I've always found reasonable alternatives for the software I want). What I'm wondering is if this is entirely to support unsigned casks, why does Homebrew not simply resign the software itself at install time with an adhoc signature as though it had just built it?
Yeah, my nix-darwin config is pretty nice and perfectly hermetic and reproducible, save for a now-growing list of casks in my brew.nix that looks like this:
> 1password # breaks in nix, must go in /Applications folder
> softwareB # not available in nixpkgs
> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile from source and ain't nobody got time for that
> softwareD # ostensibly available in nixpkgs, but the package is completely broken (more general case of 1password)
Why not wrap the binaries yourself in flake.nix you say? Well, sure, would love to, if it wasn't such a pain in the ass to do so for each one and keep them up to date.
> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile
What actually happened is that non free software may not be legal to distribute from nixpkgs caches, so you're on your own with building those. That's not really a purist approach.
Only because the purist inventors of nixpkgs structured the policy of what must go into nixpkgs to have this rule. Why doesn’t the same limitation exist for homebrew, for instance? It isn’t some idiosyncracy of the way they are building things, it was a conscious and deliberate policy decision.
And it might be the right one for what they are trying to achieve, but if the goal of the project is to make it more accessible and see more widespread adoption, stuff like this is a shot in the Achilles heel
Why can't you distribute it from the developer's website?
You can. For example: https://github.com/NixOS/nixpkgs/blob/fde16189feaa6eaa81bcf9...
If something gets built it likely means the sources available in some way, just not opensource. There may be many reasons they're preferred over a binary.
> nixpkgs maintainers are hardline purists
On the contrary, Nixpkgs is generally made by the most pragmatic people and takes a flexible approach to a lot of issues. For instance, very few package managers have packages for proprietary software like 1Password in their official repositories. Nixpkgs also doesn't insist on building everything from source when it's hard to do so. As a result, Nixpkgs contains many packages for NPM or Maven projects. Other package managers insist on packaging all its dependencies from source, which is why they're struggling to package software written in modern programming languages.
As for 1Password, it works fine on NixOS. When installing proprietary GUI apps like 1Password on macOS, I just use Casks. I suspect many people do the same, which might lead to the 1Password package not working as well on macOS because fewer people bother with it.
The Nixpkgs community is internally diverse, but broadly values both "purity" and pragmatism. You can see debates and compromises play out in PRs all the time, or read traces of such careful weighing in the source code of Nixpkgs itself.
For the record, the Nix community's largest public cache doesn't cache binaries of proprietary software because doing so would be illegal— the public doesn't generally have the rights to redistribute proprietary software.
The phenomenon of having to compile free software from source via Nix typically happens when free software depends on proprietary software (which is common on macOS). Maybe this could be ameliorated on a technical level, but I think it's mostly historical accident and ease of implementation that got us to the current situation, where the whole dependency tree has to have a free license for something to make it into the binary cache.
The 1Password cask will almost certainly continue to work. 1Password distributes a signed installer.
Yes the cask is fine. The problem with 1pass installed via nix is that it doesn’t put it in applications folder because that defeats the hermeticity of the solution. However the 1Password devs designed the binary on Mac to only boot out of applications folder, presumably for security reasons. Most other apps you can get around this by setting up trampoline links to the nix store versions, but if the app straight up refuses to boot anywhere else besides applications folder, you can’t use the typical nix installation path
IIRC there are some macOS APIs that you can only access if your app runs out of /Applications. There are some features of an app called "Secretive" (an SSH agent that stores keys in the Secure Enclave) that only work if you have the app installed under /Applications (whereas I'd normally install it under ~/Applications).
1pass probably does this to ensure that people can't accidentally install the app the "wrong way" and break some features.
Yep. It goes back to “some things nix does are straight up exclusive to the way macOS needs things to be”, as long as that dichotomy exists nix-Darwin will always have hacky idiosyncrasies like this. It’s not an easily solved problem, and it’s not necessarily Nix’s or Apple’s problem to fix. It’s just two antithetical design philosophies. I would love to see Apple support that kind of sandboxing Nix offers here for these apps though
Brew-Nix might be able to cover some of those gaps, but probably not all of them. But almost certainly SoftwareC, at least!
https://github.com/BatteredBunny/brew-nix
What he is doing in there is kinda cool but the trampoline app solution is quite similar and unfortunately does not fix this problem. Fundamentally the problem is that when you install stuff with nix it gets a folder that is unique to that nix generation. That is by design nix, because you want to be able to go back and forth between generations etc. Apple does not think of things the same way. Applications is a single folder that you can’t subdivide with iterations and it’s “speshul”. These core philosophies are antithetical to each other. This is fine for Most applications who don’t need to be in Applications. You let Nix install into its own little /nix/ generation folder and then create a “trampoline” in applications which is basically like a symlink. Then your app shows up in spotlight etc. where this falls apart is applications like 1Password that MUST boot from the speshul Applications folder
However, you are right, it definitely makes some other pieces of this cleaner. In particular, if you just use homebrew directly with nix, you aren't deterministic or reproducible. You have an impure setup because if you remove a cask from the list, it doesn't actually delete it from homebrew, and you can't go back and forth with generations because homebrew is stuffing things in /applications. The project you linked forces brew stuff to behave like Nix applications and go in /nix instead, which allows it to be able to walk between generations. So it solves most of the issues with brew and nix but not all of them.
> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile from source and ain't nobody got time for that
Which package is that? Is it proprietary but source available? Any free software which is built from source is built by hydra and available from the binary cache to downstream users.
Terraform is a notable example yeah. Takes like 7 minutes to compile it when you would get it in seconds by pulling the binary
When Hashicorp did their rug pull, I just switched my team to OpenTofu as soon as it had a stable release. No regrets; it's been great. (I did evaluate both projects at that time, of course. But it ended up being a clear decision.)
> If I have to give my consent anew for each app update, I might as well install the apps manually and live in the usual auto-update pop-up hell.
Really? That's a whole lot of UI actions/clicks (and a variable number per .app) versus ... I think two always-the-same UI actions at most. Not like, a huge hassle either way, but I have trouble seeing how Homebrew's not still the winner here even without quarantine bypassing.
Spack is a really unfortunate name for a project given that it's a slur derived from 'spastic' in the UK.
Can you just "pronounce" it (even in your head) S-pack, as in "source package"?
> The important thing for me with this is that it doesnt appear to impact homebrew's ability to download, compile, and install open source software. And that is the main thing I use homebrew for. I believe that is true for most people too
FWIW I don't think brew has been compiling on installation even open source things by default for a while now[1]:
> Homebrew provides pre-built binary packages for many formulae. These are referred to as bottles and are available at https://github.com/Homebrew/homebrew-core/packages.
The link shows close to 300 pages of precompiled packages available, and that section ends with the sentence "We aim to bottle everything".
I don't think this necessarily changes anything you've stated with regards to the flag being removed as described in the Github issue linked by OP, but I think it's still worth noting because this is markedly different than how homebrew distributed things in the past, so others might not be aware of this change either.
[1]: I assume the heading title for this docs section predates this change, but the docs section I'm referencing is https://docs.brew.sh/FAQ#why-do-you-compile-everything
> FWIW I don't think brew has been compiling on installation even open source things by default for a while now
For built in formulas, no. For custom ones very much more so. I know I have a bunch I’ll never have bottles for and would thus always be compiled if used.
That's fair, but I was specifically responding to the part of OP's comment that said that compiling and installing comments was what they expected "most people" used homebrew for. I would expect the vast majority of homebrew users to be installing the built-in formulas for pretty much everything.
I do recognize that there's a bit of ambiguity around when the "compiling" happens, since even the binaries being distributed are still being compiled from homebrew's formulas. The main point I was trying to make was that there was a transition from the "compile everything on the user's local machine when installing" model that homebrew started with to "use the pre-built binaries that homebrew has compiled in advance for installing when possible if the user hasn't specifically expressed they want to compile it themselves". To be clear, I think this is a good thing, and it's a pretty huge quality of life improvement, but I've noticed a few times over the years that this change seems to have not been as widely noticed as I'd expect given how visible it seemed to me even as someone who only uses MacOS on my work machines and not my personal ones. I still sometimes get frustrated with homebrew feeling a bit slow compared to my preferred Linux package manager, but overall it's become far faster and less error-prone over the past decade, and I think it's worth calling out efforts they've taken (like pre-compiling and distributing binaries) that have made a noticeable impact.
In some ways, I think I think understanding the previous efforts they've taken might even help explain why they've chosen not to put in the effort to work around the quarantine issues (e.g. by using local signing like some other comments on this story have mentioned); they're a volunteer project that, unlike most standard package manages for Linux distros, are not in a position where they can easily influence the development of the OS features that might be useful for them. It makes sense to me that the most valuable use of their efforts would be on things that aren't swimming against the current of where MacOS is going. Getting to the point where they could have seamless binary installations at all can't have been an easy task, and the infrastructure needed for it takes additional effort beyond the local compilation model (which still exists). If cutting down on the scope in one dimension makes it easier for them to continue providing the overall feature set they have, this seems like a worthwhile tradeoff to me.
Also if you have an older version of macOS. It will try to take the compiled route for packages but also prints a stern warning that your setup is unsupported.
You can tell this in how fast things "pour". There's no way things are compiling from source that fast.
Sigh, I'm so over homebrew's hipster rubyist brewery analogy
[flagged]
Homebrew Project Leader here.
Yes, this only affects casks, not formulae, whether formulae are built from source or use Homebrew's bottles (binary packages) or bottles from taps.
As an open-source developer, is there a way to have my apps pass Gatekeeper without paying the $100/year Apple ransom and notarizing them? I think it’s the crux of the problem.
As I’m writing these lines, Homebrew has 7656 casks in the official cask tap[1]. I’m not sure exactly how many of those are unsigned but if we assume 4000 then signing them all would be an additional $400,000/year extorted by Apple from the open-source community.
Defining HOMEBREW_CASK_OPTS=--no-quarantine in my shell configuration was a good way to avoid this issue without having to manually run dozens of xattr -d every time I run brew upgrade.
Now my only option left is to pull the trigger and make my system globally less secure: sudo spctl --master-disable
Unfortunately, disabling Gatekeeper doesn’t just allow unsigned apps to run: it also completely disable all verifications for signed apps: notarization checks, revocation checks, trust evaluation checks.
[1] curl https://formulae.brew.sh/api/cask.json | jq 'length'
You can make your own tap (which is just a GitHub repo) and manually clear the quarantine flag in a postflight step. E.g., see https://github.com/alacritty/alacritty/issues/8749
Users will need to `brew install myorg/mytap/appname` instead of just `brew install appname`, but I think that's the only real option at this point.
I’m worried app maintainers will start to indiscriminately run xattr -d no matter if the user actually wants that or not. There will not be any kind of standard way to do that so the experience will be very inconsistent between casks…
I hope Homebrew will start supporting hooks at a later point because it would allow users to automatically de-quarantine instead of having all maintainers add xattr -d garbage commands to all their casks.
Two popular apps mentioned in the earlier discussion in Homebrew repo are Librewolf and Freetube.
https://github.com/orgs/Homebrew/discussions/6334
I actually tried to install Librewolf today and it wouldn’t go because of gatekeeper. Ended up on Waterfox instead.
Would’ve preferred Librewolf because that’s what I run on my other desktop running Linux but what can you do…
You can still use Librewolf, if you manually remove the quarantine attribute after every update and reboot. It’s very annoying, but at least it’s possible for now
xattr -dr com.apple.quarantine /Applications/LibreWolf.app
Oh wow, thanks for that, makes things even easier than “Find app and ctrl click”.
...or automatically remove the quarantine attribute: https://news.ycombinator.com/item?id=45913209
Not exactly, I have automated stuff which uses python and does rar and unrar and it's installed through brew, it is not a cask, but every time I do brew update, my code will fail to run because it was updated.
This is like buying a machine and not having the ability to do whatever you want with it.
Oh who are we kidding, that's what is happening anyways.
This is a silly distinction. You can always include pre-built object files in your "source code" formula, then the build step is just linking it into an executable locally. That would bypass the quarantine attribute and effectively retain the ability to distribute pre-built binaries without gatekeeper getting involved.
Seems like only a matter of time before someone at Apple realizes this and takes the necessary measures to protect you from yourself.
The linking step isn't even required. You can download any existing binary and codesign it yourself with your local developer certificate. You can even overwrite the existing signature.
I assume brew could even automate this, but are choosing not to for whatever reason.
If Homebrew auto-signed third-party code, that puts them on the line for the security of that code. The whole point of MacOS developer certificates is to increase the trustworthiness of the software you run on your machine. The trust comes from the formal relationship between Apple and the software developer, which includes a traceable financial transaction. If signed software proves to be malicious, attribution is trivial.
If the homebrew team signed everything, they would immediately become a target for bad actors. The bad actors would flood homebrew with malicious binaries, which homebrew would auto-sign, users would download & run, and the bad actors would laugh all the way to the bank.
Yeah, makes sense Homebrew doesn't sign everything with their own certs. I was suggesting that Homebrew could run codesign locally with the user's local certificate as part of the install process.
> The bad actors would flood homebrew with malicious binaries, which homebrew would auto-sign, users would download & run, and the bad actors would laugh all the way to the bank.
Every software distributor has this problem, code-signed or not. This is either already happening to Homebrew (and not using code signing) or there's some other reason that it isn't happening.
> The whole point of MacOS developer certificates is to increase the trustworthiness of the software you run on your machine.
Tim Cook is laughing all the way to the bank on that one
casks are mostly for GUI or other apps that need special installation like setting up background services. I've seen it used for IT laptop provisioning to automate the installation of things like Chrome, Slack, Visual Studio, from the command line.
Casks save so much time compared to the normal way of installing Mac apps regardless of any background services.
I have a good number of casks. I think, anyway, since I use homebrew to install a bunch of proprietary software.
> Most people I know are not installing too many casks, and most of the ones I've seen install signed binaries anyway.
I install any GUI program I can via Homebrew, there’s at least 30 casks installed currently. Don’t know how many were signed though.
Typical hn comment where major feature of a software is broken because of “reasons”. But it is fine because “I and most people don't use it”.
Hey if you are not using casks you are missing out. It's by far best way to install gui apps on a mac.
Once this doesn't work its serious problem for brew because there are package managers like nix that are arguably better for developers. Something like this could start slow death of brew just like macports did before.
My longstanding prediction that Gatekeeper will ever so slowly tighten so that people don't realise like a frog boiled in water is continuing to be true.
People did realize when the actual Gatekeeper change happened a year ago [1]. But your prediction still holds because frogs do realize when they're boiled in water [2].
[1] https://arstechnica.com/gadgets/2024/08/macos-15-sequoia-mak..., https://www.macrumors.com/2024/08/06/macos-sequoia-gatekeepe..., https://daringfireball.net/linked/2024/08/07/mac-os-15-sequo.... Top HN comment on Sequoia's announcement mentions it: https://news.ycombinator.com/item?id=41559761
[2] https://en.wikipedia.org/wiki/Boiling_frog#Experiments_and_a...
The point is that by the time Gatekeeper closes tight enough that everything must run through Apple and it can't be disabled, most people wont notice and will be stuck with it.
Your assertion seems to imply that there will be a point of no return where users are no longer able to stop buying apple hardware to run the software they want, and that therefore people should do so now.
If that's not what you're saying then your point is effectively moot, because if indeed Apple's platform control gets too egregious for some individuals then those people will switch at that point so there's no point in panic-switching now just in case.
In other words, users will switch when what Apple is offering does not meet what those users require. Some users will literally never care because all the software they use is signed and gatekept and so on; some users have jumped ship already because they want to be able to change whatever they want whenever they want. If things continue to "slippery slope" then more people will hit their own tipping point but asserting that it's going to happen all at once and apply to everyone is nonsense.
> more people will hit their own tipping point but asserting that it's going to happen all at once and apply to everyone is nonsense.
the point of boiling the frog is to make sure it happens slowly, such that the alternative options can no longer compete and be an option.
computer manufacturers and hardware makers cannot be trusted to make their platform open, because it would be detrimental to their bottom line. So it must come from regulation - right to repair etc, are on the right path, but what must be done is prevention of platform lockdowns. An owner of the hardware must be able to override all locks from the manufacturer.
iPhone is already a dictator state.
We need an antitrust breakup of Apple. And Google.
These companies are rotten.
There is no reason to believe this is going to happen other than the hyper-cynical conspiracy theories.
It remains easy to disable Gatekeeper if you want. New MacBooks still allow you to install other OSes, even though that would be trivial to lock down with signed boot requirements.
So far, none of the frog in boiling water predictions have actually come true at all. It’s just people parroting the same conspiracy every time the word Gatekeeper comes up, just like we went through every time Secure Boot came up.
Fortunately, Linux laptops are getting better and better. I'm hopeful that by the time my M1 macBook Air gets slow enough to annoy me (maybe a year or two from now?), I'll be able to smoothly transition to Linux. I've already done it on the desktop!
> by the time my M1 macBook Air gets slow enough to annoy me (maybe a year or two from now?)
It should be good for at least 5 years from now, if not more.
Before macOS 26 I would have agreed with you. But after Tahoe my M1 MacBook Pro feels a lot slower.
Funny, there's even some regression in layer backed NSView rendering where the app I'm working on is faster (in some aspects) in a macOS 15 VM than on bare metal under macOS 26.
Are you running any electron apps that have not yet been updated to use the most recent upstream electron?
https://furbo.org/2025/10/06/tahoe-electron-detector/
I've got a couple things that I use which aren't yet up-to-date, and are blocking my upgrade.
Probably not if you bought the 8GB version :D
My 8GB M1 Air is still running as well today as the day I bought it.
And it will run at the same speed. But I would guess a lot of apps will requier more ram at some point.
OP said it should last for " at least 5 years from now, if not more." which I doubt. Maybe for light webbrowsing.
Finger crossed for mine as well!
Just did this. I am so much happier. As a lifelong Apple user, and side-quest Linux user the choice is a no-brainer nowadays. Desktop Linux is honestly great now. I love(d) Apple but Tahoe was the straw that broke the camel's back for me.
i use arch btw
My family have bought macs and been apple fanboys since the "Pizzabox" 6100 PowerPC. My dad handed me down a DuoDock when I was in middle school. We bought a G4 Cube, I had an iBook and Powerbook throughout college and throughout the 2010s.
In 2017 I built my first desktop PC from the ground up and got it running Windows/Linux. I just removed Windows after the 11 upgrade required TPM, and I bought a brand new Framework laptop which I love.
This is to say that Apple used to represent a sort of freedom to escape what used to be Microsoft's walled garden. Now it's just another dead-end closed ecosystem that I'm happy to leave behind.
> This is to say that Apple used to represent a sort of freedom to escape what used to be Microsoft's walled garden. Now it's just another dead-end closed ecosystem
So you haven’t had a Mac since 2017, but you believe all of us using Macs are stuck in some walled garden?
These comments are so weird. Gatekeeper can be turned off easily if that’s what you want. Most of us leave it on because it’s not actually a problem in practice. The homebrew change doesn’t even impact non-cask formulas.
It is said you only realise you are in jail once you feel the chains. And this is something Apple has tried to walk the line on, be locked down but in a fashion that causes the least push back on users.
Personally I never felt Mac OS was that locked down, but it has been over a decade since I last used it.
The only time I felt it was trying to delete 'Chess' only it to be listed as a vital system application. I know this isn't true but I would love it if Chess turned out to be a load bearing application for the entire OS. Like folks at Apple don't know why but if you remove it, everything stops.At least MS managed to remove the load bearing Space cadet pinball. Replaced it with a One drive popup that handles all memory management in the kernel ;)
Back to the original point, by comparison on iOS I definetly did feel the chains. One could fear Mac OS will turn into that but they haven't conditioned people yet.
I have to agree. Number of times it’s prevented me from running software I wanted to run: zero. Number of times it’s stopped me and said the equivalent of “are you really sure?”: a handful, maybe once a year on average.
And it’s not like I don’t use a gazillion third party apps and commands.
Same. I can see how it would look like a major problem if your only perspective was through clickbait headlines and angry comments from people who don’t use Macs anyway, though.
It reminds me of the distant cousin who lives out the countryside and prides themselves on not living in the city because the news tells them it’s a dangerous hellhole where everyone is getting mugged or shot on every street corner. When you immerse yourself in clickbait journalism the other side, whatever that may be, starts to look much worse than reality.
running VMs on apple chips has been rather difficult for me. other than that, yeah.
Apple does not support running other OS's on their hardware. This is bad in many senses but it is specially bad since it weakens competition and reduces incentives for Apple to improve their own OS, meaning it is bad even for their users in the long run.
If you choose to buy hardware from apple, you must consider that you're encouraging a behaviour that is bad for everyone, including yourself.
I'm not sure what you're talking about. Their bootloader explicitly supports other OSes. They make it easy to run Windows (even through a built-in app that helps you set it up). There are plenty of reasons to criticize Apple, but they literally don't do anything to prevent you from running another OS.
> Their bootloader explicitly supports other OSes
That’s true but that’s probably only so that it wouldn’t have been a subject when Apple Silicon Macs were released because Intel Macs weren’t locked.
In reality, the bootloader isn’t closed (yet) but the hardware is so much undocumented that it’s easy to understand that Apple doesn’t want anything else than their OS on your mac. The « alternative os » situation is actually worse than it used to be with Intel Macs and Apple is paying a lot of attention in never talking about this "feature".
IMO, they will just quietly remove this possibility on new generations when everyone will have forgotten that boot camp used to be a thing.
Eh, you may be right, but there's a big difference between "they are going to forbid other OSes by placing a software restriction where they explicitly permit things now" and "they already effectively forbid other OSes by not publishing developer documentation for proprietary hardware"--that's a tall order, and not a bar that many other hardware manufacturers meet either.
Like, could they lock down the bootloader? Sure. But that's effort they'd have to put in for minimal benefit at the moment. Opening up their hardware would be a lot more effort for questionable benefits (to Apple).
> they literally don't do anything to prevent you from running another OS.
Like not documenting their hardware? Like making Asahi Linux becoming a multi-year reverse engineering project that may possibly never achieve perfect compatibility?
> They make it easy to run Windows
On apple silicon without virtualisation? Sorry, didn't know that.
The point is that Apple could have easily locked down the bootloader and made it not possible at all to install something else. In designing the M1 hardware they explicitly went out of their way to make sure other operating systems could be installed and they’ve said as much. They took their smartphone SoCs and bootloader that never allowed alternate operating systems and added that feature in actively.
Technically Asahi Linux isn’t facing a much different situation than standard Linux distributions as they relate to x86 hardware. There are thousands of PC components that don’t provide any sort of Linux driver where contributors reverse engineer those drivers.
Sure, in the PC world a lot more vendors do voluntarily provide Linux drivers, and Apple will never to that for its hardware, and that specific point is a valid criticism.
As far as assisting in running Windows, my understanding is that the company that makes Parallels and Apple have some kind of relationship. Microsoft officially endorses Parallels.
You can complain about it being virtualization but it’s perfectly fine for desktop apps or even some more intensive apps. And it’s not really a very valid complaint considering that Microsoft doesn’t distribute a general purpose ARM distribution of Windows.
> Technically Asahi Linux isn’t facing a much different situation than standard Linux distributions as they relate to x86 hardware.
Very very different.
> There are thousands of PC components that don’t provide any sort of Linux driver where contributors reverse engineer those drivers.
Increasingly more rare. Maybe that only happens thèse d'ays on extremely specialized hardware.
It’s only rare these days because Linux spent decades clawing its way into data centers and workstations.
You can find a somewhat similar situation on Linux, with other non-Apple ARM hardware.
> Like not documenting their hardware?
They aren't actively hindering that reverse engineering effort. They aren't _helping_ either, but I didn't claim that they were helping. For as long as I can remember, Apple's stance with Mac computers has been "We sell the computers to you in the way we think is best. If you want to tinker, that's on you." and I don't think that has materially changed.
Apple Silicon cannot boot Windows ARM and Apple is dropping boot camp support alongside x86 support in the near future.
> Apple Silicon cannot boot Windows ARM
That's totally up to Microsoft… they could done a licensing deal with Apple years ago to enable Windows ARM to run natively on Apple Silicon hardware.
Why does this need a licensing deal? Windows didn't need a licensing deal to run on commodity PC hardware back in the day.
Because computers don't boot the way they used to in the commodity BIOS era. The boot loader has to cryptographically check that it's valid operating system it's attempting to boot.
This. It’s technically possible (the same way Asahi uses), but Microsoft has to bring the support in Windows.
Well, Apple could follow industry standards, too. The argument was Apple approves alternate operating systems as evidenced by boot camp. That's demonstrably not true anymore.
> Apple does not support running other OS's on their hardware.
The bootloader was intentionally left open to other OSes. You should look into Asahi Linux.
Neither does any other hardware vendor, even the likes of Dell, Lenovo and Asus clearly state on their online shops that their laptops work best with Windows, even when something like Ubuntu or Red-Hat is an option.
Also they hardly ship any updates.
Asahi Linux[1] is unbelievably great on Apple Silicon. It's honestly the best Linux install experience I've ever had.
1. https://asahilinux.org/
Yes, but only on M1 and maybe M2 devices. Doesn't work at all on M4.
Stability is an issue (as I tested it with M1 Pro throughout the years).
Not all of the hardware features are supported. For example no external monitors through the usb-c port.
Also the project seems somewhat dead, having some core developers leave the project.
I had high hopes for Asahi but currently it doesn't seem like it will ever be fully production ready for currently relevant hardware.
Unfortunately, while Asahi Linux runs fine on M1 and M2 with some missing capabilities, it doesn't run at all on M3, M4 or M5.
The M1 and M2 are still great laptops, so it's still a good experience if you're looking for a second-hand Linux laptop with Apple quality hardwre.
> Gatekeeper will ever so slowly tighten so that people don't realise like a frog boiled in water is continuing to be true
Gatekeeper can be disabled. Given Cupertino’s pivot to services and the Mac’s limited install base relative to iPhones (and high penetration among developers) I’m doubtful they’d remove that option in the foreseeable future.
It really bothers me that Apple removed any convenient shortcut to bypass Gatekeeper like the old Control-click [1] hotkey. Apple's relentless ratcheting of the difficulty/annoyance of Gatekeeper has just about pushed me over the edge to completely disable it, despite the risk.
The ridiculous song and dance of "File is dangerous, delete it?"->No->Settings->Security->Open Anyway->"File is dangerous, delete it?"->No is getting ridiculously old after literally doing it a hundred times at this point. And soon enough Apple will inevitably come up with some additional hurdle like, idk, closing Settings three times in a row while reading a fingerprint during an odd numbered minute.
So in the name of "increased security" they've needlessly turned it into a binary thing where it's completely unprotected or accept my own computer that I paid for will deliberately waste my time constantly. It makes Windows 11 seem elegant in comparison where all I need to do is run Win11Debloat once on install and it gets out of my way.
[1] https://developer.apple.com/news/?id=saqachfa
Open Automator and make a droplet or service that runs `xattr -d com.apple.quarantine` on whatever file you give it. There’s a recursive option for xattr that I can’t remember but I add that one on too; I’ve unzipped stuff that had the flag and somehow ended up with hundreds of files I couldn’t open without GK prompts.
Thanks! I'll give that a try.
> in the name of "increased security" they've needlessly turned it into a binary thing where it's completely unprotected
Why isn't a binary condition valid? Isn't that the ethos inherent to a literal walled garden?
If you're inside, trust us. If you're outside, you don't, but don't expect us to bail you out.
I didn’t say it was invalid, just that it was needless. When I bought the laptop Gatekeeper was a tolerable nuisance and I was fine with the tradeoff given the security benefits.
The removal of the hotkey (which also required changing a setting before it worked at all) didn’t actually make it harder for a regular user to access, just 5x as aggravating every time it's necessary.
If they made developers go through some long and tedious process to re-enable it I would grumble but understand, but the only solution to get back to the 2024 status quo being entirely disabling a critical security feature certainly doesn't benefit me in any way.
> The ridiculous song and dance of "File is dangerous, delete it?"->No->Settings->Security->Open Anyway->"File is dangerous, delete it?"->No is getting ridiculously old after literally doing it a hundred times at this point. And soon enough Apple will inevitably come up with some additional hurdle like, idk, closing Settings three times in a row while reading a fingerprint during an odd numbered minute.
> So in the name of "increased security" they've needlessly turned it into a binary thing where it's completely unprotected or accept my own computer that I paid for will deliberately waste my time constantly.
Remember when Apple made fun of Microsoft for doing exactly this? https://www.youtube.com/watch?v=8CwoluNRSSc
The writing was on the wall from the first implementation. But we all kept getting downvoted when pointing out the road ahead.
Shut up and buy the sock.
I hate that analogy—frogs jump out.
I thought the problem with the analogy was that they died instantly?
Gatekeeper isn’t changing. Homebrew’s policies are changing.
It also only applies to casks. If you don’t use homebrew casks, nothing is changing for you.
You can also disable Gatekeeper entirely. It’s very easy.
I don’t see what you think you’re predicting, unless you’re trying to imply that that Gatekeeper is a conspiratorial plot to turn your Mac into an iPhone. I predict we’re going to be seeing those conspiracy theories for decades while it never comes true. Apple doesn’t want to destroy the market for their $5000 laptops so they can sell us a $1000 iPad as our only computing device or send customers to competitors. This is like a replay of the sky is falling drama when secure boot was announced
Homebrew is not really pro in any way: they force updates, deprecate old software that is still widely in use, the maintainers are always very combative and dont allow any discussions or other opinions.
In the end it's a package manager for consumers that hand holds you and is not really useful in a pro context.
I've been meaning to jump to macports anyway, maybe ill do it now...
So-called “homebrew” has only ever grudgingly provided the barest minimum of hooks to locally build your own variants of their packages, and compares most unfavourably to, say, maintaining your own easily-rebased fork of a BSD-style ports tree. Don’t even get me started on its janky dependency resolution, versioning, “services”, and lifecycle.
The hostility and self-righteousness from the maintainers in the thread linked above just adds to the general shittiness of using it at all, and yet somehow it seems to be the lowest common denominator choice for far too many teams I’ve worked with, I suppose by sheer inertia.
I started on Macports 20 years ago, switched to homebrew because it was the new thing, and this year switched back to Macports on a brand new M4 mini, after having this gnawing feeling that I should have never switched after installing Macports on a PowerBook G4 running Tiger and building something relatively modern from source without any problems.
I know, is there any point in calling it Homebrew anymore when it's like an extension of the App Store?
As someone who migrated from macports to Homebrew, I'd like to see a third option (or maybe re-investigate macports again to see what's changed recently).
Homebrew's insistence on leaving OSes behind that they deem to be "too old" is becoming a problem as the years click by. One of the reasons to use third party software and a third party package manager is to avoid Apple's own insistence on abandoning old OSes. Homebrew following their example is very disappointing.
EDIT: From the linked issue:
Deeply, deeply disappointing. I know Open Source doesn't owe us anything, but this seems like a terrible turn for what was once great software.Nix is sort of that third option, though I really wish there was a well-documented way to use it on macOS as purely a binary/source package manager. A lot of stuff I read online goes into setting up nix-darwin to manage desktop settings and etc. and I just don't need or want that.
That being said, if you haven't used MacPorts in years, I'd say it's worth the jump. I recall moving from MacPorts in the first place because Homebrew was faster and allowed for customising packages.
When I switched back to MacPorts again, it was because Homebrew had become slow and no longer allowed package customisation. Now, MacPorts is much faster and has the variants system for package customisation.
Thank you for this helpful information. It might be worth a try. I initially moved to brew because it was "new", because I liked the command line interface, and because it seemed more "segregated" from the rest of the OS's files (/usr/local/Cellar and so on). But it's increasingly aggressive messages reminding me I am a second-class (or third-class) citizen due to the age of my OS is really off-putting.
I actually migrated from Homebrew to Macports after ending up in dependency hell in Homebrew with Postgresql + Postgis, and not being able to fix this properly even with my own brew recipes.
So for now that works a lot better in Macports. The portfile stuff needed some digging to understand, but that's doable.
Not sure what made you move from Macports to Homebrew. (Should I worry?)
"Homebrew's insistence on leaving OSes behind that they deem to be "too old" is becoming a problem as the years click by"
Indeed! I have a VERY usable Macbook Pro from 2015. Even with the newest version supported macOS version (11) Big Sur (which is still quite modern) it doesn't have any binaries for apps, which means it has to compile every single app and dependency.
I managed to update to macOS 14 (with the help of OpenCore Legacy Patcher).
But this just buys me one year to use Homebrew. Next year they will retire macOS 14.
And my machine is still very usable, but it will become junk from a developer perspective unless I have homebrew (or something similar).
It annoys me because I think this problem is fixable. Either community repos or more donations to homebrew to compile apps for older macs.
It's too bad that homebrew adopted the "Apple Attitude" around dealing with legacy OS versions. I don't recall ever seeing a message while working in Linux saying "Oh, you're using an OLD version of Linux, that's unsupported! You're a Tier-3 Loser and we don't guarantee this is going to work!"
Even developer tools on Windows tend to be fairly graceful about you running Windows 7 or whatever.
Somehow Apple and their entire ecosystem has adopted this "Latest Version Or GTFO" attitude towards users and developers.
I went through the same experience with an old macbook. Switching to macports solved that problem.
How much are you willing to donate before concluding it's more efficient to just buy a new MacBook? Even the cheapest models now are faster, more energy efficient and more secure. You don't have to throw the old one away if you can find a use case for running old software but I don't think there are many people running 'power user / developer' like tasks on old hardware, especially if their jobs depend on it.
> I'd like to see a third option
Nix, perhaps?
Also Pkgsrc
if you're good with tools that don't support global installs there are also Spack, Mise, and pkgx
none of those are quite suitable for managing macOS app bundles, though.
Make Fink modern. ;)
(Part /s, part not)
Honestly conda does a lot of heavy lifting for me. I know people have strong feelings about it on here but it works great for my purposes.
What is the pro vs consumer distinction here? What consumers use homebrew?
im talking about developers for example, that may need specific/old versions of php or node or whatever, which then get deprecated and uninstallable via brew as soon as they officially reach EOL. Or once installed, get forcefully and inadvertently updated by brew.
On the other side is some consumer who uses brew to install youtube downloader and doesnt care about versions/upgrades, etc...
If you are a developer who needs a specific old version of PHP or Node or whatever and you're not using Docker then I have great news for you on how you can solve your problem.
When all you have is a hammer, everything looks like a nail.
yes, docker is a great solution nowadays for this problem, but it wasnt always like that. In PHP land there is a tool called Laravel Valet, which relies heavily on homebrew and lets you switch PHP versions on the fly directly your system. I just remember how much of a pain it was to set up because of homebrew's unnecessary restrictions and deprecations. But once done it worked quite well.
so don't use brew at all? Great, what else should we not use?
I personally use and enjoy Homebrew for most of my development tasks. The thing I would not use it for is to exactly simulate a specific combination of tool versions.
Yes. The package manager's job is to give you some sensible version of some useful common standardized thing(s) you want to use. There might well be some legacy/current/edge options, but overall you are putting your trust in their judgement and assuming that they'll do something at least vaguely sensible.
If you want something specific than that: the package manager cannot help you here. This is no longer some random thing that you just use; it's one of your product's honest-to-goodness dependencies. You can't outsource this any more. You need to make your own arrangements to ensure that the specific version required is in use.
[dead]
brew install php@X.Y doesn’t work for you?
Although I should say that I haven’t tried to go back many major versions, I wonder if they provide 7.x for example.
It works until PHP officially EOLs the version. Then brew stops supporting it and you have to install some finicky 3rd party taps/repos to get the older versions. A huge pain...
In the real world there are still apps running PHP 7.4 and even older!
I seriously can't accept this as valid criticism.
Homebrew not allowing users to install EOL versions of software with no security patches or updates is a _good_ idea. Just because a fraction of a tiny minority needs some ancient version of PHP doesn't make it a good idea.
yea, that's why it's not "pro" grade, and that's my point.
"pro" users need EOL version support because sometimes some client still didn't want to update his age old web app the newest node or python or whatever. sometimes it's not up to the dev himself, and he needs to make money either way.
so in the end brew makes decisions for the most common denominator, and that will be the user that uses it to install youtube-dl and nothing more.
“Pro” users are using containers, venvs, version managers (nvm, rvm, etc.). They definitely aren’t installing project-specific stuff directly to the system.
> is not really useful in a pro context.
Huh, I guess I didn't use it in a "pro" context for 14 years then? Must have imagined that.
> Homebrew is not really pro in any way: they force updates, deprecate old software that is still widely in use, the maintainers are always very combative and dont allow any discussions or other opinions.
No different than Apple themselves!
Hehe, the classic rude and mean behavior from homebrew maintainers.
I get their motivation to remove the flag. In fact, it has always been better to run xattr in postinstall, this way the binary is free from quarantine even after updates.
But the way they communicate with people is unacceptable and just unnecessary.
Reading that discussion, I was very surprised at MikeMcQuaid’s reaction to xtqqczze’s concerns, which were calm, brief, and valid. In response, Mike was a dick.
Maybe it’s totally understandable that being a maintainer for the biggest mac package manager conditions a knee-jerk asshole response in a person.
There's a misunderstanding here what the issue tracker is for in Homebrew. In some projects, it's for free-for-all discussion. That's great if those projects want to use it that way.
In this issue's case, you have someone in leadership (p-linnane) communicating that work needs to be done, a maintainer (carlocab) communicating what needs to be done to make this change. xtqqczze's attempt to get us to move backwards on an already made decision doesn't help anyone. We have a discussions forum (and, well, the rest of the internet) for discussion of the pros and cons of decisions made. There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not.
As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests.
Go read through some merged pull requests some time and you will see moderately to very positive responses from me. That's because that's the work that keeps the project alive. It has almost died several times in the past and I've kept it going. You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.
Thanks for the response. Yes, I think some clarity about the purpose of the issue tracker would help someone unfamiliar with the project's maintenance better understand the conduct of the maintainers. If it is only for coordination of work tasks and not discussion of whether the work should be done, it would seem natural to have somewhere else where the discussion of the merits occurs.
> drive-by negativity by non-code-contributor users is the biggest existential threat
I do believe this, and it's what I was getting at with my "conditions a knee-jerk asshole response" comment. From the outside, I saw someone who wasn't being negative, but just seemed to have unaddressed concerns about the impact of the change. You, however, have been conditioned by hostile users over your many years of work to interpret this as negativity, because other, ruder people pile on to the valid concern in unhelpful ways, or the person with the concern wasn't willing to listen at all and just used a veneer of calm rationality to be a stick in the mud.
The point is, I get why you would be this way, but also that it doesn't look very good from the outside looking in. I know that you are doing unpaid labor and so nothing is owed, but still, both can be true.
I know some people don't like it, but I've always found discussions that are locked to collaborators only to be totally understandable for this reason. If you find yourself making "I know more about x than you ever will" comments to a person, you should probably instead just disregard them and carry on. Likewise, you do know more about x than I ever will, so you should probably just disregard me and carry on.
> There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not.
You could have just said this (maybe you did when linking the code of conduct) instead of writing a paragraph of confrontational arguments and it would have looked way better imho.
> You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.
If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.
> You could have just said this
Yup, you're right, I should have. We will adjust the CONTRIBUTING.md accordingly.
> If this was true every oss project would either be dead or be entirely comprised of dicks, neither of which are the case.
I didn't say every OSS project, I said projects like Homebrew. I know that Homebrew would be dead without many of my personal interventions. You can believe me or not but, unless you're a Homebrew maintainer, it's unlikely your opinion about what happens behind the scenes is informed.
> As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests.
your explanation did nothing to speak to being a dick, did not attempt to apologize, only tried to justify the poor behavior.
I don't think I am a dick, I guess that went without saying.
I'll take critique from other maintainers who have done as much or more open source work for similar returns over similar time periods. Funnily enough, I'm friends with many, and they are supportive the vast majority of the time instead of critical. Maybe that's because they can relate and you cannot.
No one thinks they are a dick. But you are. At least in many instances as many of the comments here and elsewhere point out. I had similar experience trying to start a discussion about something in one of the Homebrew repositories.
The fact that you have many friends who confirm your bias of not being a dick...means exactly nothing. You have people telling you your words made them perceive your comment as being arrogant/blunt and your reply is: I'm successful open-source maintainer and have many friends who think I'm not arrogant and I only take critique from them. Have it your way. But in my eyes, you're being a dick. (Don't misinterpret this as my judgement of your engineering skills. I love Homebrew and it's an incredible feat. Congrats.)
If you love Homebrew, maybe you might want to consider if repeatedly calling me a dick or arrogant/blunt is a particularly nice way to treat someone who spends their spare time building software you rely on.
This, this is being a dick. Holding your project hostage because you want to flex your power over someone. It's entitled behavior. Glad I moved to MacPorts years ago.
Your users don't owe you anything. Act "nice" and you'll get "nice" back. Act "blunt" and you'll get "blunt" back.
> Maybe that's because they can relate and you cannot.
Now you're deflecting. I passed no judgement i made an observation of your statement and you took it personally.
they pretended to have a discussion so they look good.
I don't understand what this means, although I've read the whole thread. Does this mean people won't be able to use Homebrew to compile software from source (and run it)? Does it mean that they'll be able to use Homebrew to compile software from source, but not download prebuilt binaries (and run them)? Does it mean that they'll be able to download prebuilt binaries, but only run them if they're built by a developer that Apple has blessed?
I do understand that the effect is only to make Intel Macs adopt the same behavior ARM64 Macs already had, but I don't understand what that behavior is.
I see that someone named andrewmcwatters has posted a [dead] reply to my comment that doesn't answer my questions, just repeating the same jargon from the bug report that I don't know the meaning of.
> Does this mean people won't be able to use Homebrew to compile software from source (and run it)? Does it mean that they'll be able to use Homebrew to compile software from source, but not download prebuilt binaries (and run them)?
No, and no. This only affects Casks, which are prebuilt .app bundles that Homebrew has no part in building (either locally or remotely). Formulae (source builds) and bottles (builds of formulae within Homebrew) are not directly affected by any of this.
Can any random person build things from source, or do they need to be blessed by Apple?
The answer to this is nuanced because of how it works, but the short answer is yes: you can build random things from source and run them, and you can download random binaries from the internet and run them. The only thing that Homebrew itself is changing is that it no longer provides an automatic way to lift the quarantine bit from a specific subset of binary packages (casks).
I see, thanks!
For Mac, yes and no. IIRC you don't need a developer's license to build and sign software for yourself. But you do need one to distribute pre-built software.
You can still run unsigned software, but you need to approve 2? prompts, and also allow exception for every executable by going to Privacy & Security tab in settings.
IIRC there is a CLI command for achieving the same.
You can’t run unsigned software on Apple silicon. Note that when you build your software if you use Apple’s tools it will inject an ad-hoc signature into the product.
You very much _can_ run unsigned software on Apple silicon. At work my department has a bit less than 50 engineers with Macs (M1 to M4) and nobody complained that they can't build and run our product (using GCC from Homebrew, not Clang from Apple). But it involves some jumping through hoops, yes.
What are the hoops?
As mentioned above you have to approve the binary two times (at least), being careful the first time because the dialog popup offers to remove the binary. Also since our product has some networking to do one has to mingle with firewall settings to allow the binary to do the networking.
I see, thanks!
this is completely false, compile a binary strip the signature and see for yourself.
AS requires code sign with adhoc, minimum.
To check I did this: removed the signature (LC_CODE_SIGNATURE section) using lief Python package (no affiliation, just looked suitable for the task), checked by otool that the section is indeed gone, started the binary - it worked. The spctl said that the binary is "rejected", but it says so about every non-Apple binary I checked on my machine so not informative. The codesign tool shows "is not signed at all" on the binary with stripped signature. I'm not too well-versed in OSX system/dev tools, so if there is a more correct/precise method of checking the signatures I'd very much like to know.
hmmm this is really bizarre.
are you running < 15.1?
That seems like it would interfere with reproducible builds.
The signature that gets added is vaguely a hash of the binary. You probably want to look at the UUID that gets injected into your binary instead of this.
This is my understanding after a moderate dive into the issue.
Binaries in macOS have a signature and a set of flags. One of those flags is the "quarantine" flag that, when set, refuses to run your binary until some extra security checks have been performed (checking against a malware database, asking the user for consent, etc). Once this check is done, the flag is unset.
Usually this flag has to be set by the app you use to download the binary - in most cases it would be the web browser, but here it would be Homebrew. They used to provide a --no-quarantine flag to prevent this bit from being set, but given some changes both in macOS and in the Homebrew project it's been decided to stop offering that option. You can still unset the flag by hand, no root required, but that's on you as a user.
I believe this is a strong nudge in the direction of "for a user-friendly experience you should sign your binaries", but not a full ban.
Or more explicitly, "for a user-friendly experience you should pay apple and ask them please to sign your binaries every year"
I don't know either (right now). They closed the discussion, so they don't want people to talk about it.
Perhaps someone with more information will chime in, who isn't a homebrew maintainer.
When they closed the discussion, they explicitly welcomed people to talk about it outside their issue tracker:
> Our issue trackers (other projects may differ) are used to track the work for maintainers or soliciting community contributions. They do not exist for people to debate the merits of decisions already made. We have Homebrew/discussions (and, well, the rest of the internet) for that.
They just don't want discussion about the merits of a settled decision to interfere with their work tracking when they provide a perfectly good discussion forum[1] for that.
[1](https://github.com/orgs/Homebrew/discussions)
There'll be some way to make it work, possibly indeed that the Homebrew people get approved by Apple, because MacPorts works ok, and it seems to be downloading precompiled binaries (and if it isn't, then my Mac is actually faster than I've ever seen it run). And if MacPorts can do it, presumably Homebrew can do it too.
Building stuff yourself remains an option, even if you're unapproved. The toolchain pops the codesign step in at some point, I guess, and if you built it locally then you can run it locally. I just did cc -o on some bit of code on an Apple Silicon Mac, and the resulting binary did run.
(You can also run binaries that unapproved people built on other systems, but it's a minor pain, as you have to explicitly opt in to allowing each runnable file to run.)
MacPorts and Homebrew behave identically here: precompiled binaries are not affected, only .app (and similar) bundles.
(People find this confusing, because Homebrew does a superset of what MacPorts does: it distributes both source/binary packages and it distributes "casks", which are essentially a CLI-friendly version of the App Store and come with macOS's additional restrictions on applications. This only affects casks.)
The hierarchy is actually a little more complicated than this. MacPorts can and does build open source GUI apps (in fact it largely rejects binaries for them, preferring to build them directly). Homebrew rejects GUI apps from being built from source. Because Homebrew downloads apps from the internet, it makes them with the quarantine attribute, which means more apps that it handles will be flagged by Gatekeeper.
I see, thanks! Is cc installed by default? I remember when my ex-wife had a Mac she had to sign up for Apple's developer program to get compilers installed.
You don't need to sign up for a developer program, or even download the full Xcode IDE. You do need to install the compiler tools with
I see, thanks! That clarifies things a lot.
You dint have to join the dev program but you have to installl it.
No idea what you get out of the box, or what /usr/bin/cc actually is and does, but it looks like the underlying compiler is the clang that came with Xcode, which I installed from the app store. I do have an Apple account, but I don't think it's signed up to Apple's developer program... at least, probably not? I'm not paying them for this, anyway.
Like you won’t be able to install clickhouse from homebrew for as long as clickhouse produce unsigned binaries.
It’s the only one affected that I currently use.
All it means is that applications downloaded/installed via Homebrew will no longer be able to bypass the Gatekeeper signing/notarization requirement on Intel platforms (already is the case on Arm).
If you didn't need to install a cask with this flag before you won't be impacted by the deprecation.
Casks won’t be able to bypass Gatekeeper, so now you can’t launch .apps from brew that aren’t notarized.
So, you might as well just use the App Store.
Brew Casks are quite different from the App Store, but there is a CLI for the App Store if you want that: https://github.com/mas-cli/mas
The loss of the --no-gatekeeper option isn't that big of a deal. It just removed the com.apple.quarantine xattr from the installed cask (which you can easily do yourself, or just allow the app from System Settings after Gatekeeper blocks it).
The more impactful change is the move to require all casks[0] (not just new ones) to pass Gatekeeper checks (so signed and notarized through the Apple Developer Program)[1][2]. There are a multitude of open-source applications which aren't signed and notarized through the Apple Developer Program (some due to the $99 per year cost, some due to needing to provide a legal identity and having that in the certificate, some who object to needing to do it at all). What this means is that you'll have to install these manually or use a 3rd-party tap (package repository) to install them.
Of course, Apple could solve this by providing a way for open-source projects to sign and notarize their apps without having to pay $99 per year and associate a legal identity. They've already got Xcode Cloud, they could allow use of that to build, sign, and notarize only from the publicly available source.
[0]: These are GUI applications (i.e. .app), where Homebrew downloads the official build of the app. CLI tools are done differently (the Homebrew project builds these from source), and nothing's changing there.
[1]: https://github.com/orgs/Homebrew/discussions/6334
[2]: https://github.com/orgs/Homebrew/discussions/6482
Can someone explain why disallowing Gatekeeper bypass via Homebrew is related to macOS disallowing unsigned ARM64 binaries to run? My understanding is that `—no-quarantine` just removes the `com.apple.quarantine` attribute from a downloaded application. If the application is unsigned then removing the attribute wouldn’t allow it to run anyways. There’s no way to disable the signature check because it’s a kernel level check. However, macOS will accept an adhoc signature. Because of this, to me it seems like Gatekeeper bypass and unsigned software are orthogonal topics. No matter if I remove the Gatekeeper signature or not, unsigned code still won’t run unless I add an adhoc signature. On the other hand, if I distribute software with an adhoc signature, macOS wouldn’t prevent someone else from running it as long as they remove the quarantine attribute. Am I missing something?
The only thing signaling Gatekeeper to do the deep checks and also to block execution is the presence of that file attribute. When GK was first introduced in Tiger that’s literally all it consisted of; a warning/reminder that “hey slack jawed user, you downloaded this executable from the internet, be sure you trust it!” and once they said OK, the attribute was cleared and you’re not gonna get bothered again.
The AMFI checks happen on every execution of any executable. Xprotect is also running execution based checks on first run and randomly later on to check for signatures of known malware. Gatekeeper is the umbrella term for all of this on the Mac, but its still kicked off, to the user at least, as that prompt “hey champ you downloaded this from the internet and the developer didn’t want to upload this binary to Apple for scans, move it to your trash”.
Long story short, if you remove the quarantine bit, you can run whatever the fuck you want so long as Xprotect doesn’t detect anything in its YARA rules files.
Not really, this is broadly accurate.
Two questions:
1. Does this mean it’s a little disingenuous for the Homebrew maintainers to claim that this change has anything to do with app signing, given that they reference the impossibility of unsigned applications in the issue?
2. Does this mean that if a developer self-signs their app but doesn’t notarize it that it will meet Homebrew’s criteria of “passing Gatekeeper checks”?
1. Yes. (Either that or they know something we don't about Apple's future plans.) 2. No, as Gatekeeper checks both for a valid signature from an Apple Developer Program certificate as well as notarization.
It seems the maintainers are very eager to lock issues and threads on GitHub that receive any pushback to this decision. Where is this coming from? I thought Homebrew was pro-user software, which requiring Apple's approval to run software on my computer is ostensibly not.
With how Homebrew manages issues: debates about this belong in Homebrew/discussions, not on the issue tracker. That's why they get locked.
if you read any old issues on the homebrew github you can see how these maintainers are always very aggressive and anti-discussion, especially the main guy.
> I thought Homebrew was pro-user
As a Homebrew user: Nope.
The user's name is Tim Cook and it's very rude to use his computer in ways he wouldn't like
Yeah, I’ve been noticing an alarming number of casks marked to be depreciated… at the same time gatekeeper has gotten so restrictive it won’t let me (easily) open a video files that I downloaded from the internet
Yeah, I noticed the same on my Macbook. I mainly use it for theater stuff (Qlab) and remoting into my main Windows desktop environment. I just stopped doing some of the workflows on Mac and do them on Windows because I didn't feel like trying to figure out why macOS wouldn't let GIMP open an image I downloaded from the internet. So dumb.
Most ridiculous one for me so far:
- downloaded json file from my own GitHub account
- double click to open in VSCode, Apple says no
- try the usual tricks (holding alt and right clicking, i guess), no
- drag and drop file into Code, no
- right click>get info, lo and behold: the entire file contents displayed in the Get Info preview pane for me to copy
I'm actually getting a Windows laptop to do some testing on and i might just abandon Mac for the most part after that. Eating up five minutes of my day to figure out how to edit a file i created myself is just too much sometimes
I ran into this exact same thing recently with CSVs downloaded from my own app. I tried a few different filetypes and was baffled how seemingly any filetype I downloaded triggered Gatekeeper regardless of the app I set to open it (including stock apps).
I eventually found on Reddit that setting the default via the Get Info dialog was the only path that worked, so now I can click a CSV and open it in VS Code without needing to send Apple my passport and fingerprints. I keep seeing mixed opinions whether it's a bug that Get Info associations work differently vs the right click context menu, or if it's a deliberately obtuse garden path like the Settings/Open Anyway routine and "working" as intended.
Either way I hate it but it would be slightly more forgivable as a bug (assuming it was then fixed).
Huh? JSON? Did you insert executable preamble bytes and chmod the file to execute or something? Where is this file? Can you post a link?
My work issued MacBook is incapable of running unsigned binaries enforced by the MDM kext, and I do all sorts of development all day long. Occasionally I have to resign a precompiled dylib if it was compiled on a coworkers machines, but that’s it. I have never seen anything like you’re describing.
Not making anything up. Downloaded via browser, double click, denied.
is there no way to disable this on mac silicon?
Im still on intel, and its ok here, but once I switch, will there be constant headaches and fumbling around because of this?
Alacritty is seemingly affected by this, which sucks for people who install it from homebrew because there's no way the developers are going to shell out to Apple for the signature.
https://github.com/alacritty/alacritty/issues/8749
Does anyone know if self-signed binaries will work?
Alacrity is one of my casks. I'm not tied to it. Alternatives? I guess I could just go back to terminal.
Here's my other casks:
You can either use the tap which is posted in another one of my replies, or install it from the releases and remove the quarantine flag yourself as describes in both the issue I linked and my blog post from 4 years ago. Or you can build it yourself with `make app`.
ghostty with tmux has served me well
See here for a workaround : https://news.ycombinator.com/item?id=45913209
if it's an open source project, why is it using a cask anyway? it should be a formula that builds from source directly
I don't know much about macOS these days, but I was under the impression that Casks were for applications, and normal formula were for things installed in your PATH as standalone binaries. The .app needs a few extra things bundled up.
EDIT:
I looked it up, the issue is that homebrew explicitly doesn't want .app formulas: https://docs.brew.sh/Acceptable-Formulae#stuff-that-builds-a...
IDK what they expect. Every open source application developer needs to pay $99/yr now?
I mean you can always get the DMG from the releases on GitHub, so I guess we can just point people there and abandon homebrew. https://github.com/alacritty/alacritty/releases
Mise can install things directly from GitHub
It seems like all they have to do is add a post install script that clears the quarantine attribute?
There's a third party tap now: https://github.com/m99coder/homebrew-tap
Time will tell if it's kept up to date.
I think of homebrew as a curation service; it lets me name a piece of software and install it without having to any special diligence on it. In that use case, I _want_ them to enforce code-signing requirements; that reduces the risk that some software-supply-chain compromise will spread to my computer.
I do want the ability to install unsigned software, either because I wrote/compiled it myself locally and can't be arsed with signing, or because I'm getting it from a non-public source that doesn't want to share a copy with Apple, or because it's from a developer I trust who can't be arsed. But I never want to get unsigned software _from a curation service_.
Protecting the user from things they don’t realize are apps or new apps on general is important.
But the amount of overreach in gatekeeper to try and make the failed Mac App Store profitable and milk $90 a year at the expense of apps users want to run is egregious.
I personally think $90 per year is reasonable and not 'milking' - I don't think it's large enough to suspect Apple making bank on this, but does represent a certain level of commitment from a dev and prevents users from spamming developer accounts.
The only scenario in which I think it's excessive is broke student devs, not sure if there's a scheme to waive the fee for them.
Not allowing regular folks to run unsigned apps is something I also agree with -though I would love if Apple allowed us to trust third-party root certs so that apps would be both signed and free of Apple's control.
I find it hard to believe that charging people is the only way to stop people people from making multiple/spam accounts. It seems like it's just the easiest and most profitable. And, if it is the only option, then why does an account that has been paying Apple $90 a year for a decade still need to keep paying them: it's seems unlikely to be a spam account at that point.
This is like the "why do i have to pay property taxes after i pay my house off?" for Apple™
You’re right I shouldn’t have to. I already paid tax on the money to buy it and paid extra tax for the right to buy it, why the triple dip.
>Not allowing regular folks to run unsigned apps is something I also agree with -though I would love if Apple allowed us to trust third-party root certs so that apps would be both signed and free of Apple's control.
Rolling up the ladder much? Most who can program nowadays in one form or another owe the learning experience to the fact we could write and run unsigned apps without nannery measures like Gatekeeper.
I flat out refuse henceforth the do anything that encourages mind share on fundamentally anti-user, gatekept platforms.
The reason you can go anywhere on the internet and trust at least that the website you're viewing is in the form the creator intended is that HTTPS exists - which requires that a trusted entity has issued a cert that proves the domain is indeed held by the person and what goes on in that domain hasn't been tampered with externally.
That is the default on the internet, and even enforced. I'm merely saying that for average users (or power users even, who understand the risks) the default should be that the same guarantees apply to desktop apps as well (especially considering those usually have far more access).
HTTPS shows that such a world where people live with this restriction is possible and practical, and far from the jackbooted tyranny you describe.
The contrast between the steadily shrinking freedoms in Apple-land and the open computing approach underlying all today's the Valve announcements is fascinating.
I switched from Linux to macOS with osx 10.2.8 because it was a much better unix desktop experience. Lately, more and more I've been feeling a lot like linux is a better desktop experience.
Yeah yeah, I'm sure there's a whole line of people who'd like to mock this entire decision, but I assure you that back then, a lot of us would rather use our desktop OS than fix our desktop OSes broken 802.11b, audio, graphics, etc.. And back then, osx shipped x11, and you could `ssh -Y` and `xnest` and all that fun stuff. Plus linux (and other unixes) never left my side for headless work.
Top this off with all the Android lockdown, and I feel like linux and FLOSS has maybe never been as important as it is now.
Yet Valve have still managed to maintain a dominant 'App Store' without having to rely on locked-down platforms.
It may be Apple policy to prevent users from doing what they want because "security" is the most important thing for a their bank/shopping terminals. But I thought the whole point of using homebrew was to empower the user to use Apple devices like a normal computer without the hassle of having to do it manually? The developer has made it clear this is not the use case and that it helped with it was unintentional and undesired. The actual use case for homebrew remains unclear given this new information.
As I understand it `--no-quarantine`, as it is currently implemented, is a noop on ARM Macs. So if Homebrew has two options:
1. Play cat and mouse with Apple to ensure `--no-quarantine` works
2. Deprecate and remove the feature.
Well, 2. is what the people are asking for but aren't getting. They want deprecation and a ENV flag to enable. It'd be enough. But even that isn't being allowed which is weird for a power-user program. I can't help but think, "Don't obey in advance."
2 is what is happening. The feature is being deprecated and will likely be removed in the next MacOS version.
>I can't help but think, "Don't obey in advance."
They aren't obeying in advance. They simply aren't doing the work to find another Gatekeeper bypass for ARM64.
They're deprecating it and removing it. What is required is deprecating it and leaving it in (with env flag to enable) till it actually breaks rather than obeying in advance.
No, it definitely has an effect on Apple silicon. Without this you will be blocked from running ad-hoc signed code.
For a quick background, Apple doesn't allow the typical quarantine bypass of Gatekeeper for ARM64 binaries. It must be digitally signed to run. And Intel based Macs are a dead end with macOS Tahoe being the last OS released for them. So, brew is disabling the --no-quarantine switch in their next major release or so.
From the post: "What alternatives to the feature have been considered?
None. Macs with Apple silicon are the platform that will be supported in the future, and Apple is making it harder to bypass Gatekeeper as is."
While it is true that macOS requires binaries to have a digital signature, that can just be an ad-hoc signature. Other than that, not much has changed. Gatekeeper (and the ability to bypass it for specific apps/binaries) works much the same for unsigned Intel binaries as for ad-hoc signed Apple Silicon binaries.
This has turned into a such a pain point for me I'm probably just going to ditch MacOS on my next hardware refresh and insist on a Linux-based workstation. I already use Linux for everything else, changing for $DAY_JOB is trivial.
Meanwhile, just automatically remove the quarantine attribute: https://news.ycombinator.com/item?id=45913209
If I’m gonna bother doing something like that I’m just gonna use Linux and just not have to deal with it at all.
Funny/sad to see this post just under the
"Install your own apps, or even another operating system. Who are we to tell you how to use your computer?"
Turns out you can be both consumer friendly AND have a wildly successful app store. Who knew?!
Hmm. I use arm64 macports instead of homebrew, and as far as I know, I download prebuilt binaries from macports without issue even on Tahoe -- are they signing them with an approved account? Or did they force me to build everything from scratch, like the old days, and I haven't noticed?
This doesn't affect most prebuilt binaries. It specifically affects what Homebrew calls "casks," which are redistributions of .app bundles (which come with additional restrictions via Gatekeeper, unlike a "simple" binary).
Also, fuck Apple's entire notarization process.
https://github.com/alacritty/alacritty/issues/8749#issuecomm...
If you want a more level headed overview of code signing differences, you can read this post I wrote back when this issue started coming to a head the first time back in 2021: https://nixpulvis.com/ramblings/2021-02-02-signing-and-notar...
Now, unsurprisingly, more and more distributers are falling in line, and it's all mostly theater.
Where is our modern Stallman, how have we let these massive platform OS providers assert this much control over the developer ecosystem.
They collect $99/yr for the right to give away free software! Madness. And they lie about the safety of the system. How about focus on keeping the OS secure and maintaining process isolation, and let users run what they want.
Homebrew also started preventing you from installing any packages system-wide with pip
This is true, but also misleading: Homebrew did what every major "distro-level" package manager did, which was conform to PEP 668[1].
(This, as it turns out, was a great idea. A single global shared environment that pip used by default was one of the single greatest sources of user frustration in Python.)
[1]: https://peps.python.org/pep-0668/
No, pip itself did that, and fortunately. It’s a setting you can disable if you want to be able to accidentally trash your environment.
I want to purposefully trash my environment
Pip will let you! You just have to ask it nicely.
Homebrew is famous for making life hard for users. It makes "design decisions" that often conflict with users' needs, all in order to live up to the personal preferences of the project leads.
Personally I use asdf to manage my software on Macs. It too has also changed its design recently to become user-hostile (the command-line tool no longer prints the options for the commands, and it's full of bugs since a recent major version change).
For anyone looking to make an alternative to Homebrew: check out asdf's plugin system! It is insanely easy for anyone to make an asdf plugin, install it, use it. It's just a directory of plaintext files/scripts somewhere on the web. I made a couple plugins for unpackaged apps within like 30 minutes of learning how plugins worked. Very "unix philosophy" (in a good way)
(aside: I'm not a "Mac person" (forced to use one by work), so I know this is an unpopular opinion, but Macs feel worse to use than either Windows or Linux. At least Windows has WSL2 if you like command-lines (or PowerShell if you're into that). OTOH Macs ship with insanely outdated incompatible tools, and the 3rd-party options are annoying as hell. Why do technical people keep using Macs?)
Apple loves to change which tools they ship, too, it at least have for the last few years as system updates were routinely breaking our build scripts at work, mostly when Apple would replace a GNU tool with a BSD tool without warning i think.
I agree though, Finder is a joke, the macOS system preferences has gotten incredibly cluttered and hard to use, the ever stricter code signing and download-opening restrictions are frustrating, and i can't even just install and run the docker CLI--docker on Mac requires Desktop and commercial use of Desktop requires a license.
All 3 systems have things about them that annoy me, but I'm with you that Mac is my least favorite. And it kinda sucks because the global text shortcuts (command-arrow, command-delete etc) are really handy and hard to replicate on other systems, and at least traditionally it's been a very pretty and well integrated desktop, the system itself just drives me up a wall.
> Apple loves to change which tools they ship, too, it at least have for the last few years as system updates were routinely breaking our build scripts at work, mostly when Apple would replace a GNU tool with a BSD tool without warning i think.
It's a licensing issue; Apple has never shipped GPLv3 software. This has been discussed dozens of times on HN.
Of course you can use Homebrew to install a GNU toolchain to your heart's content.
Just FYI: macOS has been a BSD-derived operating system from the beginning, using stuff from FreeBSD, OpenBSD and NetBSD on a Mach kernel. It’s a certified UNIX™ operating system.
And because GPLv3 is incompatible with how Apple operates, they ship versions of pre-GPLv3 software like Bash 3.2.
Apple now ships openrsync [1] as a replacement for rsync due to licensing issues.
[1]: https://appleinsider.com/inside/macos-sequoia/tips/what-you-...
Well there's now an MIT-licensed Rust rewrite of GNU coretools. Maybe in a few years they'll ship that, and we won't have to faff about with crappy 3rd party solutions. (I mean, seriously, when Windows ships with better dev tools than you? That's embarrassing.)
I'd have sworn they used to ship nano instead of pico; but i could be misremembering, regardless, the behavior of the tools changed and the only solution was install the gnu version from brew (and later, move the whole build to docker when Apple broke something else that used to work fine on both Mac and Linux)
> i can't even just install and run the docker CLI--docker on Mac requires Desktop and commercial use of Desktop requires a license.
That's not on Apple. Docker needs the Linux kernel (for Linux containers), so it's no different to needing something like Docker Desktop to use Docker on Windows. Yeah, Docker changed the license on Docker Desktop, but there's plenty of alternatives (Podman Desktop, Rancher Desktop, Colima, Apple's own container tool, or just running a Linux VM in Lima).
(I may be wrong here but) under the hood Docker on macOS runs a small Linux VM where all containers live, exactly because containers are basically Linux namespaces on steroids so not portable 1:1 to anywhere.
I'm not blaming Apple for it, but it makes me dislike their platform more regardless
Try mise
https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
Windows and Mac competing to see who can push all their users, and upping the ante every week this year it seems.
It's somewhat bizarre to me for this to impact "casks" but not "bottles". Bottles are all ad-hoc signed and presumably have the quarantine attribute removed manually since I do not see Gatekeeper warnings for bottles I install via Homebrew.
Downloaded files that are not executable or contains any executables in their archives don’t receive the quarantine bit. Non-quarantined executables don’t even require the ad-hoc signing as far as I know. It’s there to prevent lateral movement of executables: not to allow it to run on your computer, but to prevent it from running on someone else’s.
Anyone interested in forking homebrew? Seems like they need more competition when it comes to user friendly package managers (macports doesn't count).
It's a pity the original author got lost in the crypto rabbit hole
https://tea.xyz/
There's also Sps2 which is written in Rust but it's very early stage
https://github.com/alexykn/sps2
Breaking the momentum and institutional adoption of homebrew is non-trivial but the developer community needs to band together unless we want to be slaves to Apple's whims forever. The current homebrew maintain Mike McQuaid clearly had no interest in listening to users.
Mike McQuaid has been doing this a long time and there are more egregious examples in the past. I got off the Homebrew train when Little Snitch caught Homebrew phoning home without my consent and the response from him was, the developers have already decided to implement telemetry in an opt-out fashion and any pushback to that already made decision is "abusive" to the maintainers.
The Homebrew maintainers are not trustworthy. Don't use their software. If a fork was going to be feasible, it already would have happened.
I think mise has a real chance of being a homebrew replacement, if the author chooses do take up the mantle.
Unfortunately, requires root, no Intel mac, no reuse of the large brew manifest library... The first 3 opened issues capture the core deficiencies perfectly
Fyi, this might be a useful workaround, if you are aware of the “risks” :
“lightweight service for macOS that automatically clears quarantine flags on everything in the given folders”
https://github.com/Absolucy/autoremove-quarantine
Gatekeeper is just a travesty. I'm moving to Linux with the next laptop purchase.
Does this mean if I publish my own cask for pre built binaries, people will no longer be able to use it unless I do something with Homebrew's Gatekeeper?
If yes, this sounds a lot like the android side loading the Google just reversed
Does this affect the linux version of homebrew? I'm hoping this has no effect.
No, because there is no codesigning/notarization on Linux.
> https://github.com/jdx/mise
Just dropping this here for those who don't know about it. It solves most of my CLI dependencies.
"Locking this thread. Not interested in arguing the merits of this. It's already been communicated to third parties."
Well!
Note: I think one problem of homebrew is called ... Apple. That is, they depend on whatever Apple decides.
Granted, this is similar to Microsoft; and to some extent to Linux, though people can make more modifications on Linux normally.
I am a Linux users so this does not affect me, and I also wrote my own "package" manager (basically just some ruby scripts to compile things from source), but at the same time I also think that at the end of the day, the user should decide what he or she wants. This is also why my scripts support systemd - I don't use/need systemd myself, but my tools should be agnostic, so I don't project my own opinion onto them.
There is of course a limitation, which is available time - often I just lack time to support xyz. But I keep that spirit alive - software should serve the human, not the other way around. (I have no substantial opinion on the feature itself here, that is to me it seems ok to remove it; the larger question is who dictates something onto users and what workarounds exist. Do workarounds exist? From reading the issue tracker, it seems the homebrew maintainers say that there are no workarounds, and thus it should be removed. If that is true then they have a point, but people also downvoted that, so perhaps there are workarounds - in which case these should be supported. I really don't know myself - to me apple is more like a glorified Windows, so basically the same. All software should be liberated eventually.)
There will be delicious irony when MacOS is locked down to the point that running homebrew is no longer possible.
It seems this mostly affects Intel systems.
Only true because this only works on Intel code. You can't use the typical method to bypass Gatekeeper because Apple removed it for ARM64 code.
No, the mechanism is the same.
To clarify, the macOS kernel requires a signature on all Apple Silicon binaries, but this can just be an ad-hoc signature. Ad-hoc signed Apple Silicon applications are treated much the same as unsigned Intel ones.
TL;DR
Homebrew is removing --no-quarantine because:
Apple is killing Intel support.
Apple Silicon won’t run unsigned apps anyway.
Homebrew will soon require all apps to pass Gatekeeper.
They don’t want to help users bypass macOS security.
This is basically a security + future-compatibility cleanup.
> Apple Silicon won’t run unsigned apps anyway.
Technically true, but misleading. The macOS kernel won't execute an Apple Silicon binary that doesn't have a signature, but as Apple documents, an ad-hoc signature is enough to meet that requirement. That won't get you past Gatekeeper, but that's no different to how it is with unsigned Intel binaries.
I use Nix for my CLI needs but homebrew for GUI programs, anyone know of any good alternative? A lot of casks will be removed, like mktvoolnix-app (the GUI program, not the CLI tool). Also this Mike guy is insufferable.
[dead]
[dead]
[flagged]
I can run whatever I want on my Windows and Linux machines. I wouldn't put up with this, but I guess some people really feel they need their silly fruit computers.
You run something that Windows doesn't like (like an Activator), Windows straight up deletes the application.
Try permanently disabling Windows Defender on modern Windows 11 and get back to me.