Posted by firexcy 11/12/2025
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.
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.
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
No. Both lib.licenses.unfree and lib.licenses.unfreeRedistributable are accepted into Nixpkgs, but the former marker indicates that the developer has declared it illegal to distribute builds so the official binary cache (sorry, “substituter”) does not.
What Homebrew likely does is fetch the upstream binaries from the upstream download server. Nixpkgs does have a policy against that when buildable source code is available, but that’s mostly because the way Nix achieves isolation (both from the host system and between packages) is by placing almost all shared libraries and data files in hash-decorated places that are emphatically different from what an upstream binary expects. On Linux, it’s possible, if very distasteful, to cram that peg into this hole using mount namespaces and bind mounts (see buildFHSEnv et al.); not sure about Darwin, but the general response to asking Nixpkgs maintainers to keep this sort of fragile mess working is, indeed, pretty much exactly “ain’t nobody got time for that”.
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.
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.
1pass probably does this to ensure that people can't accidentally install the app the "wrong way" and break some features.
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.
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.
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.
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.
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'
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 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.
Would’ve preferred Librewolf because that’s what I run on my other desktop running Linux but what can you do…
xattr -dr com.apple.quarantine /Applications/LibreWolf.app
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.
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.
> 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.
Tim Cook is laughing all the way to the bank on that one
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...
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.
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.
We need an antitrust breakup of Apple. And Google.
These companies are rotten.
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.
It should be good for at least 5 years from now, if not more.
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.
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.
OP said it should last for " at least 5 years from now, if not more." which I doubt. Maybe for light webbrowsing.
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.
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.
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.
And it’s not like I don’t use a gazillion third party apps and commands.
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.
If you choose to buy hardware from apple, you must consider that you're encouraging a behaviour that is bad for everyone, including yourself.
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.
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).
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.
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.
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.
You can find a somewhat similar situation on Linux, with other non-Apple ARM 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.
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.
The bootloader was intentionally left open to other OSes. You should look into Asahi Linux.
Also they hardly ship any updates.
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.
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 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.
xattr -cr <file or dir>
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.
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.
> 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
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.
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.
Nix, perhaps?
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.
(Part /s, part not)
On the other side is some consumer who uses brew to install youtube downloader and doesnt care about versions/upgrades, etc...
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.
Although I should say that I haven’t tried to go back many major versions, I wonder if they provide 7.x for example.
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.
"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.
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.
> 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.
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.
your explanation did nothing to speak to being a dick, did not attempt to apologize, only tried to justify the poor behavior.
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.
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.)
Now you're deflecting. I passed no judgement i made an observation of your statement and you took it personally.
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.
IIRC there is a CLI command for achieving the same.
AS requires code sign with adhoc, minimum.
are you running < 15.1?
_For binary compatibility, translated x86_64 code is permitted to execute through Rosetta with no signature information at all. No specific identity is conveyed to this code through the device-specific Secure Enclave signing procedure, and it executes with precisely the same limitations as native unsigned code executing on an Intel-based Mac._
Maybe it's Rosetta bins? - src from Apple:
https://support.apple.com/en-gb/guide/security/secebb113be1/...
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.)
xcode-select --installIt’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
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).
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.
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.