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.
> 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.
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.
Sigh, I'm so over everyone being over everything. I'm so over everyone tweeting. I'm so everyone over _______. I can't believe they still play that song. I can't believe they still visit that website. If you're the one that can't stand the things everyone else is doing, you're the outlier, not them. Yes, there's a lot of sheeple in the world, but you complaining doesn't do anything except make you look egotistical.
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.
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.
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.
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.
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).
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.
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.)
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.
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.
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!
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.
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.
> 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.
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.
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...
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.
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.
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
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?
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.
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.
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).
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.)
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."
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.
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_.
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.
"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.)
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."
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.
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.
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 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.
> 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]:
> 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.
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
Sigh, I'm so over everyone being over everything. I'm so over everyone tweeting. I'm so everyone over _______. I can't believe they still play that song. I can't believe they still visit that website. If you're the one that can't stand the things everyone else is doing, you're the outlier, not them. Yes, there's a lot of sheeple in the world, but you complaining doesn't do anything except make you look egotistical.
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.
Two popular apps mentioned in the earlier discussion in Homebrew repo are Librewolf and Freetube.
https://github.com/orgs/Homebrew/discussions/6334
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.
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 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?
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.
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!
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.
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.)
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.
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.
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.
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.
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.
Apple Silicon cannot boot Windows ARM and Apple is dropping boot camp support alongside x86 support in the near future.
> 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.
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.
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.
they pretended to have a discussion so they look good.
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...
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.> 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.
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.
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.
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
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?
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.
The user's name is Tim Cook and it's very rude to use his computer in ways he wouldn't like
> I thought Homebrew was pro-user
As a Homebrew user: Nope.
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?
if it's an open source project, why is it using a cask anyway? it should be a formula that builds from source directly
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?!
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).
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.
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."
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.
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_.
Windows and Mac competing to see who can push all their users, and upping the ante every week this year it seems.
> https://github.com/jdx/mise
Just dropping this here for those who don't know about it. It solves most of my CLI dependencies.
Does this affect the linux version of homebrew? I'm hoping this has no effect.
No, because there is no codesigning/notarization on Linux.
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.
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.
Try mise
https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
"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.)
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.
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.
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.
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.