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.
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.
> 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.
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.
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
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.
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 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'
Would’ve preferred Librewolf because that’s what I run on my other desktop running Linux but what can you do…
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.
Seems like only a matter of time before someone at Apple realizes this and takes the necessary measures to protect you from yourself.
I assume brew could even automate this, but are choosing not to for whatever reason.
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.
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.
[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...
It should be good for at least 5 years from now, if not more.
i use arch btw
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.
If you choose to buy hardware from apple, you must consider that you're encouraging a behaviour that is bad for everyone, including yourself.
The bootloader was intentionally left open to other OSes. You should look into Asahi Linux.
Also they hardly ship any updates.
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.
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.
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
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...
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.
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."
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.
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?)
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.
On the other side is some consumer who uses brew to install youtube downloader and doesnt care about versions/upgrades, etc...
Huh, I guess I didn't use it in a "pro" context for 14 years then? Must have imagined that.
No different than Apple themselves!
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.
Maybe it’s totally understandable that being a maintainer for the biggest mac package manager conditions a knee-jerk asshole response in a person.
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.
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.
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.
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.
Perhaps someone with more information will chime in, who isn't a homebrew maintainer.
> 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.
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.)
(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.)
It’s the only one affected that I currently use.
If you didn't need to install a cask with this flag before you won't be impacted by the deprecation.
So, you might as well just use the App Store.
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”?
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.
As a Homebrew user: Nope.
- 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
Im still on intel, and its ok here, but once I switch, will there be constant headaches and fumbling around because of this?
https://github.com/alacritty/alacritty/issues/8749
Does anyone know if self-signed binaries will work?
Here's my other casks:
cask "aerospace"
cask "alacritty"
cask "betterdisplay"
cask "emacs"
cask "espanso"
cask "hammerspoon"
cask "jordanbaird-ice" # ice
cask "gimp"
cask "inkscape"
cask "maccy"
cask "mactex"
cask "macwhisper"
cask "qmk-toolbox"
cask "zoom"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
Time will tell if it's kept up to date.
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_.
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.
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.
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.
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.
1. Play cat and mouse with Apple to ensure `--no-quarantine` works
2. Deprecate and remove the feature.
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."
"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?!
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.
(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.)
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?)
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.
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.
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).
It's a pity the original author got lost in the crypto rabbit hole
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.
The Homebrew maintainers are not trustworthy. Don't use their software. If a fork was going to be feasible, it already would have happened.
“lightweight service for macOS that automatically clears quarantine flags on everything in the given folders”
If yes, this sounds a lot like the android side loading the Google just reversed
Just dropping this here for those who don't know about it. It solves most of my CLI dependencies.
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.)
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.
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.