25 ms·

Homebrew no longer allows bypassing Gatekeeper for unsigned/unnotarized software

345 points by firexcy 10mo ago

bargainbin 10mo ago
Windows and Mac competing to see who can push all their users, and upping the ante every week this year it seems.
davidkellis 10mo ago
Does this affect the linux version of homebrew? I'm hoping this has no effect.
- angulardragon03 10mo ago
  No, because there is no codesigning/notarization on Linux.
kragen 10mo ago
I don't understand what this means, although I've read the whole thread. Does this mean people won't be able to use Homebrew to compile software from source (and run it)? Does it mean that they'll be able to use Homebrew to compile software from source, but not download prebuilt binaries (and run them)? Does it mean that they'll be able to download prebuilt binaries, but only run them if they're built by a developer that Apple has blessed? I do understand that the effect is only to make Intel Macs adopt the same behavior ARM64 Macs already had, but I don't understand what that behavior is. I see that someone named andrewmcwatters has posted a [dead] reply to my comment that doesn't answer my questions, just repeating the same jargon from the bug report that I don't know the meaning of.
- andrewmcwatters 10mo ago
  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.
  - zeckalpha 10mo ago
    Brew Casks are quite different from the App Store, but there is a CLI for the App Store if you want that: https://github.com/mas-cli/mas https://github.com/mas-cli/mas
- shevy-java 10mo ago
  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.
  - hoistbypetard 10mo ago
    When they closed the discussion, they explicitly welcomed people to talk about it outside their issue tracker: > Our issue trackers (other projects may differ) are used to track the work for maintainers or soliciting community contributions. They do not exist for people to debate the merits of decisions already made. We have Homebrew/discussions (and, well, the rest of the internet) for that. They just don't want discussion about the merits of a settled decision to interfere with their work tracking when they provide a perfectly good discussion forum[1] for that. [1](https://github.com/orgs/Homebrew/discussions https://github.com/orgs/Homebrew/discussions)
- woodruffw 10mo ago
  > 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.
  - kragen 10mo ago
    Can any random person build things from source, or do they need to be blessed by Apple?
    - dalenw 10mo ago
      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.
      - watermelon0 10mo ago
        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.
        saagarjha 10mo ago
        You can’t run unsigned software on Apple silicon. Note that when you build your software if you use Apple’s tools it will inject an ad-hoc signature into the product.
        kragen 10mo ago
        That seems like it would interfere with reproducible builds.
- jiehong 10mo ago
  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.
- probably_wrong 10mo ago
  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.
  - superkuh 10mo ago
    Or more explicitly, "for a user-friendly experience you should pay apple and ask them please to sign your binaries every year"
- tom_ 10mo ago
  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.)
  - kragen 10mo ago
    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.
    - justincormack 10mo ago
      You dint have to join the dev program but you have to installl it.
    - tom_ 10mo ago
      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.
    - pyth0 10mo ago
      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 xcode-select --install
      - kragen 10mo ago
- omcnoe 10mo ago
  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.
  - EasyMark 10mo ago
    I think that homebrew will be removing those that require it as well ( or I suppose you can build from source)
seanparsons 10mo ago
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.
- JohnTHaller 10mo ago
  The writing was on the wall from the first implementation. But we all kept getting downvoted when pointing out the road ahead.
  - 4ndrewl 10mo ago
    Shut up and buy the sock.
- JumpCrisscross 10mo ago
  > 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.
  - ewoodrich 10mo ago
    It really bothers me that Apple removed any convenient shortcut to bypass Gatekeeper like the old Control-click [1] hotkey. Apple's relentless ratcheting of the difficulty/annoyance of Gatekeeper has just about pushed me over the edge to completely disable it, despite the risk. The ridiculous song and dance of "File is dangerous, delete it?"->No->Settings->Security->Open Anyway->"File is dangerous, delete it?"->No is getting ridiculously old after literally doing it a hundred times at this point. And soon enough Apple will inevitably come up with some additional hurdle like, idk, closing Settings three times in a row while reading a fingerprint during an odd numbered minute. So in the name of "increased security" they've needlessly turned it into a binary thing where it's completely unprotected or accept my own computer that I paid for will deliberately waste my time constantly. It makes Windows 11 seem elegant in comparison where all I need to do is run Win11Debloat once on install and it gets out of my way. [1] https://developer.apple.com/news/?id=saqachfa https://developer.apple.com/news/?id=saqachfa
superkuh 10mo ago
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.
- nemothekid 10mo ago
  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.
  - superkuh 10mo ago
    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."
    - nemothekid 10mo ago
      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.
      - superkuh 10mo ago
        They're deprecating it and removing it. What is required is deprecating it and leaving it in (with env flag to enable) till it actually breaks rather than obeying in advance.
  - saagarjha 10mo ago
supportengineer 10mo ago
It seems this mostly affects Intel systems.
- JohnTHaller 10mo ago
  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.
  - saagarjha 10mo ago
    No, the mechanism is the same.
    - Aaron2222 10mo ago
      To clarify, the macOS kernel requires a signature on all Apple Silicon binaries, but this can just be an ad-hoc signature. Ad-hoc signed Apple Silicon applications are treated much the same as unsigned Intel ones.
foxandmouse 10mo ago
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
- tacker2000 10mo ago
  is there no way to disable this on mac silicon? Im still on intel, and its ok here, but once I switch, will there be constant headaches and fumbling around because of this?
- JohnTHaller 10mo ago
  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.
  - queenkjuul 10mo ago
    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
    - ewoodrich 10mo ago
      I ran into this exact same thing recently with CSVs downloaded from my own app. I tried a few different filetypes and was baffled how seemingly any filetype I downloaded triggered Gatekeeper regardless of the app I set to open it (including stock apps). I eventually found on Reddit that setting the default via the Get Info dialog was the only path that worked, so now I can click a CSV and open it in VS Code without needing to send Apple my passport and fingerprints. I keep seeing mixed opinions whether it's a bug that Get Info associations work differently vs the right click context menu, or if it's a deliberately obtuse garden path like the Settings/Open Anyway routine and "working" as intended. Either way I hate it but it would be slightly more forgivable as a bug (assuming it was then fixed).
andrewmcwatters 10mo ago
[dead]
JohnTHaller 10mo ago
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."
- Aaron2222 10mo ago
  While it is true that macOS requires binaries to have a digital signature, that can just be an ad-hoc signature. Other than that, not much has changed. Gatekeeper (and the ability to bypass it for specific apps/binaries) works much the same for unsigned Intel binaries as for ad-hoc signed Apple Silicon binaries.
tacker2000 10mo ago
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...
- vr46 10mo ago
  I know, is there any point in calling it Homebrew anymore when it's like an extension of the App Store?
- anamexis 10mo ago
  What is the pro vs consumer distinction here? What consumers use homebrew?
  - tacker2000 10mo ago
    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...
    - simonw 10mo ago
      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.
      - tacker2000 10mo ago
        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.
shevy-java 10mo ago
"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.)
theoldgreybeard 10mo ago
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.
- DavideNL 10mo ago
  Meanwhile, just automatically remove the quarantine attribute: https://news.ycombinator.com/item?id=45913209 https://news.ycombinator.com/item?id=45913209
  - theoldgreybeard 10mo ago
    If I’m gonna bother doing something like that I’m just gonna use Linux and just not have to deal with it at all.
mzajc 10mo ago
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.
- tacker2000 10mo ago
  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.
- none_to_remain 10mo ago
  The user's name is Tim Cook and it's very rude to use his computer in ways he wouldn't like
- 0xbadcafebee 10mo ago
  > I thought Homebrew was pro-user As a Homebrew user: Nope.
- mikemcquaid 10mo ago
  With how Homebrew manages issues: debates about this belong in Homebrew/discussions, not on the issue tracker. That's why they get locked.
devkit1 10mo ago
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. :-)
- saghm 10mo ago
  > 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 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 https://docs.brew.sh/FAQ#why-do-you-compile-everything
  - frizlab 10mo ago
    > 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.
buildfocus 10mo ago
The contrast between the steadily shrinking freedoms in Apple-land and the open computing approach underlying all today's the Valve announcements is fascinating.
- hoherd 10mo ago
  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.
- bluescrn 10mo ago
  Yet Valve have still managed to maintain a dominant 'App Store' without having to rely on locked-down platforms.
skygazer 10mo ago
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?
- woodruffw 10mo ago
  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).
0xbadcafebee 10mo ago
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?)
- Onavo 10mo ago
  Try mise https://mise.jdx.dev/dev-tools/comparison-to-asdf.html https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
- queenkjuul 10mo ago
  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.
jimrandomh 10mo ago
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_.
nixpulvis 10mo ago
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 https://github.com/alacritty/alacritty/issues/8749 Does anyone know if self-signed binaries will work?
- valicord 10mo ago
  if it's an open source project, why is it using a cask anyway? it should be a formula that builds from source directly
  - nixpulvis 10mo ago
    I don't know much about macOS these days, but I was under the impression that Casks were for applications, and normal formula were for things installed in your PATH as standalone binaries. The .app needs a few extra things bundled up. EDIT: I looked it up, the issue is that homebrew explicitly doesn't want .app formulas: https://docs.brew.sh/Acceptable-Formulae#stuff-that-builds-an-app 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 https://github.com/alacritty/alacritty/releases
    - paradox460 10mo ago
      Mise can install things directly from GitHub
- swiftcoder 10mo ago
  It seems like all they have to do is add a post install script that clears the quarantine attribute?
  - nixpulvis 10mo ago
Onavo 10mo ago
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/ https://tea.xyz/ There's also Sps2 which is written in Rust but it's very early stage https://github.com/alexykn/sps2 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.
- deleted 10mo ago
  [deleted]
- eviks 10mo ago
  Unfortunately, requires root, no Intel mac, no reuse of the large brew manifest library... The first 3 opened issues capture the core deficiencies perfectly
- wl 10mo ago
  Mike McQuaid has been doing this a long time and there are more egregious examples in the past. I got off the Homebrew train when Little Snitch caught Homebrew phoning home without my consent and the response from him was, the developers have already decided to implement telemetry in an opt-out fashion and any pushback to that already made decision is "abusive" to the maintainers. The Homebrew maintainers are not trustworthy. Don't use their software. If a fork was going to be feasible, it already would have happened.
  - Onavo 10mo ago
    I think mise has a real chance of being a homebrew replacement, if the author chooses do take up the mantle.
theturtle 10mo ago
[dead]
miketheman 10mo ago
[flagged]
deleted 10mo ago
[deleted]
Rockjodd 10mo ago
> https://github.com/jdx/mise https://github.com/jdx/mise Just dropping this here for those who don't know about it. It solves most of my CLI dependencies.
westondeboer 10mo ago
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.
- Aaron2222 10mo ago
  > Apple Silicon won’t run unsigned apps anyway. Technically true, but misleading. The macOS kernel won't execute an Apple Silicon binary that doesn't have a signature, but as Apple documents, an ad-hoc signature is enough to meet that requirement. That won't get you past Gatekeeper, but that's no different to how it is with unsigned Intel binaries.
Tyrubias 10mo ago
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?
- saagarjha 10mo ago
  Not really, this is broadly accurate.
  - Tyrubias 10mo ago
    Two questions: 1. Does this mean it’s a little disingenuous for the Homebrew maintainers to claim that this change has anything to do with app signing, given that they reference the impossibility of unsigned applications in the issue? 2. Does this mean that if a developer self-signs their app but doesn’t notarize it that it will meet Homebrew’s criteria of “passing Gatekeeper checks”?
    - Aaron2222 10mo ago
      1. Yes. (Either that or they know something we don't about Apple's future plans.) 2. No, as Gatekeeper checks both for a valid signature from an Apple Developer Program certificate as well as notarization.
- wpm 10mo ago
  The only thing signaling Gatekeeper to do the deep checks and also to block execution is the presence of that file attribute. When GK was first introduced in Tiger that’s literally all it consisted of; a warning/reminder that “hey slack jawed user, you downloaded this executable from the internet, be sure you trust it!” and once they said OK, the attribute was cleared and you’re not gonna get bothered again. The AMFI checks happen on every execution of any executable. Xprotect is also running execution based checks on first run and randomly later on to check for signatures of known malware. Gatekeeper is the umbrella term for all of this on the Mac, but its still kicked off, to the user at least, as that prompt “hey champ you downloaded this from the internet and the developer didn’t want to upload this binary to Apple for scans, move it to your trash”. Long story short, if you remove the quarantine bit, you can run whatever the fuck you want so long as Xprotect doesn’t detect anything in its YARA rules files.
fudged71 10mo ago
Homebrew also started preventing you from installing any packages system-wide with pip
- woodruffw 10mo ago
  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/ https://peps.python.org/pep-0668/
- kstrauser 10mo ago
  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.
  - saagarjha 10mo ago
    I want to purposefully trash my environment
    - kstrauser 10mo ago
      Pip will let you! You just have to ask it nicely.
nbobko 10mo ago
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.
- knowitnone3 10mo ago
  they pretended to have a discussion so they look good.
- Vegenoid 10mo ago
  Reading that discussion, I was very surprised at MikeMcQuaid’s reaction to xtqqczze’s concerns, which were calm, brief, and valid. In response, Mike was a dick. Maybe it’s totally understandable that being a maintainer for the biggest mac package manager conditions a knee-jerk asshole response in a person.
  - mikemcquaid 10mo ago
    There's a misunderstanding here what the issue tracker is for in Homebrew. In some projects, it's for free-for-all discussion. That's great if those projects want to use it that way. In this issue's case, you have someone in leadership (p-linnane) communicating that work needs to be done, a maintainer (carlocab) communicating what needs to be done to make this change. xtqqczze's attempt to get us to move backwards on an already made decision doesn't help anyone. We have a discussions forum (and, well, the rest of the internet) for discussion of the pros and cons of decisions made. There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not. As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests. Go read through some merged pull requests some time and you will see moderately to very positive responses from me. That's because that's the work that keeps the project alive. It has almost died several times in the past and I've kept it going. You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.
haunter 10mo ago
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?!
mvdtnz 10mo ago
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.
- 15155 10mo ago
  Try permanently disabling Windows Defender on modern Windows 11 and get back to me.
- platevoltage 10mo ago
  You run something that Windows doesn't like (like an Activator), Windows straight up deletes the application.
nixpulvis 10mo ago
Also, fuck Apple's entire notarization process. https://github.com/alacritty/alacritty/issues/8749#issuecomment-3524792546 https://github.com/alacritty/alacritty/issues/8749#issuecomm... If you want a more level headed overview of code signing differences, you can read this post I wrote back when this issue started coming to a head the first time back in 2021: https://nixpulvis.com/ramblings/2021-02-02-signing-and-notarizing https://nixpulvis.com/ramblings/2021-02-02-signing-and-notar... Now, unsurprisingly, more and more distributers are falling in line, and it's all mostly theater. Where is our modern Stallman, how have we let these massive platform OS providers assert this much control over the developer ecosystem. They collect $99/yr for the right to give away free software! Madness. And they lie about the safety of the system. How about focus on keeping the OS secure and maintaining process isolation, and let users run what they want.
skrrtww 10mo ago
It's somewhat bizarre to me for this to impact "casks" but not "bottles". Bottles are all ad-hoc signed and presumably have the quarantine attribute removed manually since I do not see Gatekeeper warnings for bottles I install via Homebrew.
- wpm 10mo ago
  Downloaded files that are not executable or contains any executables in their archives don’t receive the quarantine bit. Non-quarantined executables don’t even require the ad-hoc signing as far as I know. It’s there to prevent lateral movement of executables: not to allow it to run on your computer, but to prevent it from running on someone else’s.
Aaron2222 10mo ago
The loss of the --no-gatekeeper option isn't that big of a deal. It just removed the com.apple.quarantine xattr from the installed cask (which you can easily do yourself, or just allow the app from System Settings after Gatekeeper blocks it). The more impactful change is the move to require all casks[0] (not just new ones) to pass Gatekeeper checks (so signed and notarized through the Apple Developer Program)[1][2]. There are a multitude of open-source applications which aren't signed and notarized through the Apple Developer Program (some due to the $99 per year cost, some due to needing to provide a legal identity and having that in the certificate, some who object to needing to do it at all). What this means is that you'll have to install these manually or use a 3rd-party tap (package repository) to install them. Of course, Apple could solve this by providing a way for open-source projects to sign and notarize their apps without having to pay $99 per year and associate a legal identity. They've already got Xcode Cloud, they could allow use of that to build, sign, and notarize only from the publicly available source. [0]: These are GUI applications (i.e. .app), where Homebrew downloads the official build of the app. CLI tools are done differently (the Homebrew project builds these from source), and nothing's changing there. [1]: https://github.com/orgs/Homebrew/discussions/6334 https://github.com/orgs/Homebrew/discussions/6334 [2]: https://github.com/orgs/Homebrew/discussions/6482 https://github.com/orgs/Homebrew/discussions/6482
sunaookami 10mo ago
I use Nix for my CLI needs but homebrew for GUI programs, anyone know of any good alternative? A lot of casks will be removed, like mktvoolnix-app (the GUI program, not the CLI tool). Also this Mike guy is insufferable.
DavideNL 10mo ago
Fyi, this might be a useful workaround, if you are aware of the “risks” : “lightweight service for macOS that automatically clears quarantine flags on everything in the given folders” https://github.com/Absolucy/autoremove-quarantine https://github.com/Absolucy/autoremove-quarantine
whywhywhywhy 10mo ago
Protecting the user from things they don’t realize are apps or new apps on general is important. But the amount of overreach in gatekeeper to try and make the failed Mac App Store profitable and milk $90 a year at the expense of apps users want to run is egregious.
- torginus 10mo ago
  I personally think $90 per year is reasonable and not 'milking' - I don't think it's large enough to suspect Apple making bank on this, but does represent a certain level of commitment from a dev and prevents users from spamming developer accounts. The only scenario in which I think it's excessive is broke student devs, not sure if there's a scheme to waive the fee for them. Not allowing regular folks to run unsigned apps is something I also agree with -though I would love if Apple allowed us to trust third-party root certs so that apps would be both signed and free of Apple's control.
  - charlie-83 10mo ago
    I find it hard to believe that charging people is the only way to stop people people from making multiple/spam accounts. It seems like it's just the easiest and most profitable. And, if it is the only option, then why does an account that has been paying Apple $90 a year for a decade still need to keep paying them: it's seems unlikely to be a spam account at that point.
    - 91bananas 10mo ago
      This is like the "why do i have to pay property taxes after i pay my house off?" for Apple™
      - whywhywhywhy 10mo ago
        You’re right I shouldn’t have to. I already paid tax on the money to buy it and paid extra tax for the right to buy it, why the triple dip.
  - 10mo ago
AlexandrB 10mo ago
There will be delicious irony when MacOS is locked down to the point that running homebrew is no longer possible.
WhyOhWhyQ 10mo ago
Gatekeeper is just a travesty. I'm moving to Linux with the next laptop purchase.
verdverm 10mo ago
Does this mean if I publish my own cask for pre built binaries, people will no longer be able to use it unless I do something with Homebrew's Gatekeeper? If yes, this sounds a lot like the android side loading the Google just reversed

345 points by firexcy 10mo ago

bargainbin 10mo ago

Windows and Mac competing to see who can push all their users, and upping the ante every week this year it seems.

davidkellis 10mo ago

Does this affect the linux version of homebrew? I'm hoping this has no effect.

angulardragon03 10mo ago
No, because there is no codesigning/notarization on Linux.

kragen 10mo ago

I don't understand what this means, although I've read the whole thread. Does this mean people won't be able to use Homebrew to compile software from source (and run it)? Does it mean that they'll be able to use Homebrew to compile software from source, but not download prebuilt binaries (and run them)? Does it mean that they'll be able to download prebuilt binaries, but only run them if they're built by a developer that Apple has blessed? I do understand that the effect is only to make Intel Macs adopt the same behavior ARM64 Macs already had, but I don't understand what that behavior is. I see that someone named andrewmcwatters has posted a [dead] reply to my comment that doesn't answer my questions, just repeating the same jargon from the bug report that I don't know the meaning of.

andrewmcwatters 10mo ago
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.
- zeckalpha 10mo ago
  Brew Casks are quite different from the App Store, but there is a CLI for the App Store if you want that: https://github.com/mas-cli/mas https://github.com/mas-cli/mas
shevy-java 10mo ago
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.
- hoistbypetard 10mo ago
  When they closed the discussion, they explicitly welcomed people to talk about it outside their issue tracker: > Our issue trackers (other projects may differ) are used to track the work for maintainers or soliciting community contributions. They do not exist for people to debate the merits of decisions already made. We have Homebrew/discussions (and, well, the rest of the internet) for that. They just don't want discussion about the merits of a settled decision to interfere with their work tracking when they provide a perfectly good discussion forum[1] for that. [1](https://github.com/orgs/Homebrew/discussions https://github.com/orgs/Homebrew/discussions)
woodruffw 10mo ago
> 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.
- kragen 10mo ago
  Can any random person build things from source, or do they need to be blessed by Apple?
  - dalenw 10mo ago
    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.
    - watermelon0 10mo ago
      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.
      - saagarjha 10mo ago
        You can’t run unsigned software on Apple silicon. Note that when you build your software if you use Apple’s tools it will inject an ad-hoc signature into the product.
        kragen 10mo ago
        That seems like it would interfere with reproducible builds.
jiehong 10mo ago
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.
probably_wrong 10mo ago
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.
- superkuh 10mo ago
  Or more explicitly, "for a user-friendly experience you should pay apple and ask them please to sign your binaries every year"
tom_ 10mo ago
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.)
- kragen 10mo ago
  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.
  - justincormack 10mo ago
    You dint have to join the dev program but you have to installl it.
  - tom_ 10mo ago
    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.
  - pyth0 10mo ago
    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 xcode-select --install
    - kragen 10mo ago
omcnoe 10mo ago
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.
- EasyMark 10mo ago
  I think that homebrew will be removing those that require it as well ( or I suppose you can build from source)

seanparsons 10mo ago

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.

JohnTHaller 10mo ago
The writing was on the wall from the first implementation. But we all kept getting downvoted when pointing out the road ahead.
- 4ndrewl 10mo ago
  Shut up and buy the sock.
JumpCrisscross 10mo ago
> 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.
- ewoodrich 10mo ago
  It really bothers me that Apple removed any convenient shortcut to bypass Gatekeeper like the old Control-click [1] hotkey. Apple's relentless ratcheting of the difficulty/annoyance of Gatekeeper has just about pushed me over the edge to completely disable it, despite the risk. The ridiculous song and dance of "File is dangerous, delete it?"->No->Settings->Security->Open Anyway->"File is dangerous, delete it?"->No is getting ridiculously old after literally doing it a hundred times at this point. And soon enough Apple will inevitably come up with some additional hurdle like, idk, closing Settings three times in a row while reading a fingerprint during an odd numbered minute. So in the name of "increased security" they've needlessly turned it into a binary thing where it's completely unprotected or accept my own computer that I paid for will deliberately waste my time constantly. It makes Windows 11 seem elegant in comparison where all I need to do is run Win11Debloat once on install and it gets out of my way. [1] https://developer.apple.com/news/?id=saqachfa https://developer.apple.com/news/?id=saqachfa

superkuh 10mo ago

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.

nemothekid 10mo ago
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.
- superkuh 10mo ago
  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."
  - nemothekid 10mo ago
    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.
    - superkuh 10mo ago
      They're deprecating it and removing it. What is required is deprecating it and leaving it in (with env flag to enable) till it actually breaks rather than obeying in advance.
- saagarjha 10mo ago

supportengineer 10mo ago

It seems this mostly affects Intel systems.

JohnTHaller 10mo ago
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.
- saagarjha 10mo ago
  No, the mechanism is the same.
  - Aaron2222 10mo ago
    To clarify, the macOS kernel requires a signature on all Apple Silicon binaries, but this can just be an ad-hoc signature. Ad-hoc signed Apple Silicon applications are treated much the same as unsigned Intel ones.

foxandmouse 10mo ago

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

tacker2000 10mo ago
is there no way to disable this on mac silicon? Im still on intel, and its ok here, but once I switch, will there be constant headaches and fumbling around because of this?
JohnTHaller 10mo ago
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.
- queenkjuul 10mo ago
  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
  - ewoodrich 10mo ago
    I ran into this exact same thing recently with CSVs downloaded from my own app. I tried a few different filetypes and was baffled how seemingly any filetype I downloaded triggered Gatekeeper regardless of the app I set to open it (including stock apps). I eventually found on Reddit that setting the default via the Get Info dialog was the only path that worked, so now I can click a CSV and open it in VS Code without needing to send Apple my passport and fingerprints. I keep seeing mixed opinions whether it's a bug that Get Info associations work differently vs the right click context menu, or if it's a deliberately obtuse garden path like the Settings/Open Anyway routine and "working" as intended. Either way I hate it but it would be slightly more forgivable as a bug (assuming it was then fixed).

andrewmcwatters 10mo ago

[dead]

JohnTHaller 10mo ago

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."

Aaron2222 10mo ago
While it is true that macOS requires binaries to have a digital signature, that can just be an ad-hoc signature. Other than that, not much has changed. Gatekeeper (and the ability to bypass it for specific apps/binaries) works much the same for unsigned Intel binaries as for ad-hoc signed Apple Silicon binaries.

tacker2000 10mo ago

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...

vr46 10mo ago
I know, is there any point in calling it Homebrew anymore when it's like an extension of the App Store?
anamexis 10mo ago
What is the pro vs consumer distinction here? What consumers use homebrew?
- tacker2000 10mo ago
  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...
  - simonw 10mo ago
    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.
    - tacker2000 10mo ago
      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.

shevy-java 10mo ago

"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.)

theoldgreybeard 10mo ago

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.

DavideNL 10mo ago
Meanwhile, just automatically remove the quarantine attribute: https://news.ycombinator.com/item?id=45913209 https://news.ycombinator.com/item?id=45913209
- theoldgreybeard 10mo ago
  If I’m gonna bother doing something like that I’m just gonna use Linux and just not have to deal with it at all.

mzajc 10mo ago

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.

tacker2000 10mo ago
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.
none_to_remain 10mo ago
The user's name is Tim Cook and it's very rude to use his computer in ways he wouldn't like
0xbadcafebee 10mo ago
> I thought Homebrew was pro-user As a Homebrew user: Nope.
mikemcquaid 10mo ago
With how Homebrew manages issues: debates about this belong in Homebrew/discussions, not on the issue tracker. That's why they get locked.

devkit1 10mo ago

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. :-)

saghm 10mo ago
> 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 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 https://docs.brew.sh/FAQ#why-do-you-compile-everything
- frizlab 10mo ago
  > 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.

buildfocus 10mo ago

The contrast between the steadily shrinking freedoms in Apple-land and the open computing approach underlying all today's the Valve announcements is fascinating.

hoherd 10mo ago
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.
bluescrn 10mo ago
Yet Valve have still managed to maintain a dominant 'App Store' without having to rely on locked-down platforms.

skygazer 10mo ago

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?

woodruffw 10mo ago
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).

0xbadcafebee 10mo ago

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?)

Onavo 10mo ago
Try mise https://mise.jdx.dev/dev-tools/comparison-to-asdf.html https://mise.jdx.dev/dev-tools/comparison-to-asdf.html
queenkjuul 10mo ago
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.

jimrandomh 10mo ago

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_.

nixpulvis 10mo ago

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 https://github.com/alacritty/alacritty/issues/8749 Does anyone know if self-signed binaries will work?

valicord 10mo ago
if it's an open source project, why is it using a cask anyway? it should be a formula that builds from source directly
- nixpulvis 10mo ago
  I don't know much about macOS these days, but I was under the impression that Casks were for applications, and normal formula were for things installed in your PATH as standalone binaries. The .app needs a few extra things bundled up. EDIT: I looked it up, the issue is that homebrew explicitly doesn't want .app formulas: https://docs.brew.sh/Acceptable-Formulae#stuff-that-builds-an-app 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 https://github.com/alacritty/alacritty/releases
  - paradox460 10mo ago
    Mise can install things directly from GitHub
swiftcoder 10mo ago
It seems like all they have to do is add a post install script that clears the quarantine attribute?
- nixpulvis 10mo ago

Onavo 10mo ago

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/ https://tea.xyz/ There's also Sps2 which is written in Rust but it's very early stage https://github.com/alexykn/sps2 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.

deleted 10mo ago
[deleted]
eviks 10mo ago
Unfortunately, requires root, no Intel mac, no reuse of the large brew manifest library... The first 3 opened issues capture the core deficiencies perfectly
wl 10mo ago
Mike McQuaid has been doing this a long time and there are more egregious examples in the past. I got off the Homebrew train when Little Snitch caught Homebrew phoning home without my consent and the response from him was, the developers have already decided to implement telemetry in an opt-out fashion and any pushback to that already made decision is "abusive" to the maintainers. The Homebrew maintainers are not trustworthy. Don't use their software. If a fork was going to be feasible, it already would have happened.
- Onavo 10mo ago
  I think mise has a real chance of being a homebrew replacement, if the author chooses do take up the mantle.

theturtle 10mo ago

[dead]

miketheman 10mo ago

[flagged]

deleted 10mo ago

[deleted]

Rockjodd 10mo ago

> https://github.com/jdx/mise https://github.com/jdx/mise Just dropping this here for those who don't know about it. It solves most of my CLI dependencies.

westondeboer 10mo ago

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.

Aaron2222 10mo ago
> Apple Silicon won’t run unsigned apps anyway. Technically true, but misleading. The macOS kernel won't execute an Apple Silicon binary that doesn't have a signature, but as Apple documents, an ad-hoc signature is enough to meet that requirement. That won't get you past Gatekeeper, but that's no different to how it is with unsigned Intel binaries.

Tyrubias 10mo ago

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?

saagarjha 10mo ago
Not really, this is broadly accurate.
- Tyrubias 10mo ago
  Two questions: 1. Does this mean it’s a little disingenuous for the Homebrew maintainers to claim that this change has anything to do with app signing, given that they reference the impossibility of unsigned applications in the issue? 2. Does this mean that if a developer self-signs their app but doesn’t notarize it that it will meet Homebrew’s criteria of “passing Gatekeeper checks”?
  - Aaron2222 10mo ago
    1. Yes. (Either that or they know something we don't about Apple's future plans.) 2. No, as Gatekeeper checks both for a valid signature from an Apple Developer Program certificate as well as notarization.
wpm 10mo ago
The only thing signaling Gatekeeper to do the deep checks and also to block execution is the presence of that file attribute. When GK was first introduced in Tiger that’s literally all it consisted of; a warning/reminder that “hey slack jawed user, you downloaded this executable from the internet, be sure you trust it!” and once they said OK, the attribute was cleared and you’re not gonna get bothered again. The AMFI checks happen on every execution of any executable. Xprotect is also running execution based checks on first run and randomly later on to check for signatures of known malware. Gatekeeper is the umbrella term for all of this on the Mac, but its still kicked off, to the user at least, as that prompt “hey champ you downloaded this from the internet and the developer didn’t want to upload this binary to Apple for scans, move it to your trash”. Long story short, if you remove the quarantine bit, you can run whatever the fuck you want so long as Xprotect doesn’t detect anything in its YARA rules files.

fudged71 10mo ago

Homebrew also started preventing you from installing any packages system-wide with pip

woodruffw 10mo ago
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/ https://peps.python.org/pep-0668/
kstrauser 10mo ago
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.
- saagarjha 10mo ago
  I want to purposefully trash my environment
  - kstrauser 10mo ago
    Pip will let you! You just have to ask it nicely.

nbobko 10mo ago

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.

knowitnone3 10mo ago
they pretended to have a discussion so they look good.
Vegenoid 10mo ago
Reading that discussion, I was very surprised at MikeMcQuaid’s reaction to xtqqczze’s concerns, which were calm, brief, and valid. In response, Mike was a dick. Maybe it’s totally understandable that being a maintainer for the biggest mac package manager conditions a knee-jerk asshole response in a person.
- mikemcquaid 10mo ago
  There's a misunderstanding here what the issue tracker is for in Homebrew. In some projects, it's for free-for-all discussion. That's great if those projects want to use it that way. In this issue's case, you have someone in leadership (p-linnane) communicating that work needs to be done, a maintainer (carlocab) communicating what needs to be done to make this change. xtqqczze's attempt to get us to move backwards on an already made decision doesn't help anyone. We have a discussions forum (and, well, the rest of the internet) for discussion of the pros and cons of decisions made. There's no point maintaining the illusion that we're soliciting feedback or discussion on the issues tracker when we are not. As to me being a dick: I've been maintaining Homebrew for 16 years. It's used by millions of people. My full-time job has never been doing so and I've never been paid a market rate for my work on it (not that I expect or perhaps even deserve so). My primary concern with Homebrew is keeping the project actually running. This primarily requires the time, energy and work of maintainers doing so in their free time. It also requires contributors who submit pull requests. Go read through some merged pull requests some time and you will see moderately to very positive responses from me. That's because that's the work that keeps the project alive. It has almost died several times in the past and I've kept it going. You may think it hyperbolic but drive-by negativity by non-code-contributor users is the biggest existential risk to projects like Homebrew.

haunter 10mo ago

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?!

mvdtnz 10mo ago

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.

15155 10mo ago
Try permanently disabling Windows Defender on modern Windows 11 and get back to me.
platevoltage 10mo ago
You run something that Windows doesn't like (like an Activator), Windows straight up deletes the application.

nixpulvis 10mo ago

Also, fuck Apple's entire notarization process. https://github.com/alacritty/alacritty/issues/8749#issuecomment-3524792546 https://github.com/alacritty/alacritty/issues/8749#issuecomm... If you want a more level headed overview of code signing differences, you can read this post I wrote back when this issue started coming to a head the first time back in 2021: https://nixpulvis.com/ramblings/2021-02-02-signing-and-notarizing https://nixpulvis.com/ramblings/2021-02-02-signing-and-notar... Now, unsurprisingly, more and more distributers are falling in line, and it's all mostly theater. Where is our modern Stallman, how have we let these massive platform OS providers assert this much control over the developer ecosystem. They collect $99/yr for the right to give away free software! Madness. And they lie about the safety of the system. How about focus on keeping the OS secure and maintaining process isolation, and let users run what they want.

skrrtww 10mo ago

It's somewhat bizarre to me for this to impact "casks" but not "bottles". Bottles are all ad-hoc signed and presumably have the quarantine attribute removed manually since I do not see Gatekeeper warnings for bottles I install via Homebrew.

wpm 10mo ago
Downloaded files that are not executable or contains any executables in their archives don’t receive the quarantine bit. Non-quarantined executables don’t even require the ad-hoc signing as far as I know. It’s there to prevent lateral movement of executables: not to allow it to run on your computer, but to prevent it from running on someone else’s.

Aaron2222 10mo ago

The loss of the --no-gatekeeper option isn't that big of a deal. It just removed the com.apple.quarantine xattr from the installed cask (which you can easily do yourself, or just allow the app from System Settings after Gatekeeper blocks it). The more impactful change is the move to require all casks[0] (not just new ones) to pass Gatekeeper checks (so signed and notarized through the Apple Developer Program)[1][2]. There are a multitude of open-source applications which aren't signed and notarized through the Apple Developer Program (some due to the $99 per year cost, some due to needing to provide a legal identity and having that in the certificate, some who object to needing to do it at all). What this means is that you'll have to install these manually or use a 3rd-party tap (package repository) to install them. Of course, Apple could solve this by providing a way for open-source projects to sign and notarize their apps without having to pay $99 per year and associate a legal identity. They've already got Xcode Cloud, they could allow use of that to build, sign, and notarize only from the publicly available source. [0]: These are GUI applications (i.e. .app), where Homebrew downloads the official build of the app. CLI tools are done differently (the Homebrew project builds these from source), and nothing's changing there. [1]: https://github.com/orgs/Homebrew/discussions/6334 https://github.com/orgs/Homebrew/discussions/6334 [2]: https://github.com/orgs/Homebrew/discussions/6482 https://github.com/orgs/Homebrew/discussions/6482

sunaookami 10mo ago

I use Nix for my CLI needs but homebrew for GUI programs, anyone know of any good alternative? A lot of casks will be removed, like mktvoolnix-app (the GUI program, not the CLI tool). Also this Mike guy is insufferable.

DavideNL 10mo ago

Fyi, this might be a useful workaround, if you are aware of the “risks” : “lightweight service for macOS that automatically clears quarantine flags on everything in the given folders” https://github.com/Absolucy/autoremove-quarantine https://github.com/Absolucy/autoremove-quarantine

whywhywhywhy 10mo ago

Protecting the user from things they don’t realize are apps or new apps on general is important. But the amount of overreach in gatekeeper to try and make the failed Mac App Store profitable and milk $90 a year at the expense of apps users want to run is egregious.

torginus 10mo ago
I personally think $90 per year is reasonable and not 'milking' - I don't think it's large enough to suspect Apple making bank on this, but does represent a certain level of commitment from a dev and prevents users from spamming developer accounts. The only scenario in which I think it's excessive is broke student devs, not sure if there's a scheme to waive the fee for them. Not allowing regular folks to run unsigned apps is something I also agree with -though I would love if Apple allowed us to trust third-party root certs so that apps would be both signed and free of Apple's control.
- charlie-83 10mo ago
  I find it hard to believe that charging people is the only way to stop people people from making multiple/spam accounts. It seems like it's just the easiest and most profitable. And, if it is the only option, then why does an account that has been paying Apple $90 a year for a decade still need to keep paying them: it's seems unlikely to be a spam account at that point.
  - 91bananas 10mo ago
    This is like the "why do i have to pay property taxes after i pay my house off?" for Apple™
    - whywhywhywhy 10mo ago
      You’re right I shouldn’t have to. I already paid tax on the money to buy it and paid extra tax for the right to buy it, why the triple dip.
- 10mo ago

AlexandrB 10mo ago

There will be delicious irony when MacOS is locked down to the point that running homebrew is no longer possible.

WhyOhWhyQ 10mo ago

Gatekeeper is just a travesty. I'm moving to Linux with the next laptop purchase.

verdverm 10mo ago

Does this mean if I publish my own cask for pre built binaries, people will no longer be able to use it unless I do something with Homebrew's Gatekeeper? If yes, this sounds a lot like the android side loading the Google just reversed