Posted by firexcy 6 hours ago
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.
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.
Would’ve preferred Librewolf because that’s what I run on my other desktop running Linux but what can you do…
This is like buying a machine and not having the ability to do whatever you want with it.
Oh who are we kidding, that's what is happening anyways.
Seems like only a matter of time before someone at Apple realizes this and takes the necessary measures to protect you from yourself.
I assume brew could even automate this, but are choosing not to for whatever reason.
[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.
i use arch btw
It should be good for at least 5 years from now, if not more.
In 2017 I built my first desktop PC from the ground up and got it running Windows/Linux. I just removed Windows after the 11 upgrade required TPM, and I bought a brand new Framework laptop which I love.
This is to say that Apple used to represent a sort of freedom to escape what used to be Microsoft's walled garden. Now it's just another dead-end closed ecosystem that I'm happy to leave behind.
If you choose to buy hardware from apple, you must consider that you're encouraging a behaviour that is bad for everyone, including yourself.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
- 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).
https://github.com/alacritty/alacritty/issues/8749
Does anyone know if self-signed binaries will work?
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
As a Homebrew user: Nope.
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”?