Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).
Literally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was! I looked online to see if something changed and saw this post.
Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew.
Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.
Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?
Then again I use versioned AppDirs on Linux since +20 years anyway, so I am
not really into any arbitrary disctinction random linux distributions try
to push down onto the (downstream) userbase. Besides, if you compile from source, why
would you want to rely on the distribution package manager to begin with?
None of them allow for versioned AppDirs by default as far as I know; NixOS
uses a hashed name, so that is the only exception I can think of (and GoboLinux
of course), but as far as I know if you are on e. g. a debian system, you can
not use it for a versioned AppDir layout.
would you please share what amount of the new dev (work done on brew) is AI/LLM-assisted. this major version bump was very quick to arrive compared to when v6 got released?
Yup! We’ve been using it for a really long time at this point.
Were using Bubblewrap on Linux and moved to Landlock this release.
P.S. HUGE fan of your blog and writing Simon, keep up the great work. It’s the #1 resource I recommend to anyone in the industry wanting to learn more about LLMs (and pelicans).
I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug
> have a system python binary and virtual envs linked to it
I'm not sure if you're saying avoid using system python?
In my experience so far, you never want to develop complex software locked to system versions of runtimes. Too often you need a bleeding edge feature, or conversely need to postpone updating due to needing an old version for some reason.
I split my usage. Homebrew for OS things mise for the various tooling.
The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.
I don’t get these questions asking if it’s codex or Claude – I see them often. Does it matter? There are other options out there also, it feels strange to ask this. Like asking “is your car a Toyota or a BMW?“
If you say "AI tools", some vibe-coders try to equivocate between tools that generate the whole program for you and, like, an editor that uses an scoring algorithm to decide which method to show at the top of an autocomplete list. But if you say "vibe coding", some vibe-coders try to claim that what they're doing technically isn't vibe coding because they applied some non-zero amount of testing or review during the process.
If you ask "did you build this using Codex or Claude", it removes most of the wiggle room. And it's worded pretty neutrally, so it will often get vibe-coders who aren't technically using either of those tools to say something like, "Actually, I've built a custom harness for DeepSeek..." instead of an outright denial.
Long term it matters very much if your car is Toyota or BMW or Kia or John Deere though.
I think some users are also conscious about the longevity of their tooling related to LLM usage, too. Whether it has an effect or not, we've yet to find out.
> The Intel support decision reflects the limits of a volunteer-run project: Apple have dropped Intel x86_64 support from macOS 27 Golden Gate and GitHub Actions will retire Intel macOS runners in autumn 2027. If Apple and Microsoft’s GitHub, two of the world’s largest technology companies, cannot continue supporting macOS Intel x86_64, sadly neither can Homebrew. MacPorts still supports macOS Intel x86_64 and is likely to provide better results on this platform.
So much of GNU et al is already in Homebrew that I wonder how close you are to being able to support Intel Macs using the Linux/amd64 branch (or backend or whatever you call it) of Homebrew or something close to it, possibly after installing a few base libraries and utilities from MacPorts.
ETA: I've got Homebrew 7 building packages from source on an Intel Mac running Monterey; nothing yet required from MacPorts and a pretty minimal patch to the installer. I'd probably want to add legacy-support from MacPorts and update the macOS build environment to add it as an extra library on Intel Macs if I were to continue.
That being said, I'm sure y'all talked about continuing to support Intel Macs as source-based and ultimately decided against it, so it's unlikely that this will be interesting to the team. But let me know if I'm wrong and I'll open a couple PRs for further discussion.
Uncompensated volunteers dropping support for a 7 year old device that is shortly going to be unsupported by the manufacturer isn't a rug pull.
Entitlement can be wild, volunteers are volunteers. Consumers of volunteer output are free to support their use cases themselves on their own time. Find an ARM Mac used (like an M1) and upgrade.
Any modern Linux distro works great on Intel Macs. Been daily driving with Debian 13 initially and now NixOS on my MBP2015, have not used the MacOS Sequoia partition for months!
I'm probably the millionth person to parrot this to you but my goodness you are a hero if you can tolerate the Intel Mac experience in 2026.
I thought my Intel Mac from that era was incredibly weird. Little firmware-ish things were so glitchy and sluggish. At some point the wake from sleep/lid open just took forever in ways that didn't happen on older Intel Mac models (or maybe I was going crazy). I just had this strange feeling that Apple was knowingly half-hearting their Intel drivers and products as a whole as they were putting more energy into developing Apple Silicon.
Dude, you owe it to yourself to just grab a used M2 MacBook Air or something along those lines. Treat yourself. You'll be kicking yourself for not doing so sooner. (Don't get a MacBook Neo, too many compromises including poor battery life, a used Air is much better, and if you use more than one external monitor use caution on what model/CPU you choose).
Sure, a laptop should last longer than 7 years, but this is one of those "Apple yeets out a new architecture" exceptions like the PowerPC to Intel transition. Better to accept it and move on. 7 years is still a solid run. You've only got ~2 more years left until you start losing security updates anyway.
The other machine I highly recommend is Linux/Framework 13 Pro with the Intel Core Ultra Series 3, although that's a whole different price class, and obviously not everyone can make that move in terms of software compatibility.
And what if you are a developer and need to replace a well specced Mac and don’t have serious budget, especially considering recent memory and storage price increases?
Rather than a coffee table status symbol or a fashion accessory for pretending to write a novel in the coffee shop?
I recommend MacPorts, the migration is easy, you copy the package names you installed with brew, uninstall homebrew (there's an unisntall script on brew.sh FAQ section, it will also uninstall all homebrew packages (but not the casks)) then install macports and reinstall the packages with sudo port. Although the selection is smaller on macports and newer packages might not have a prebuilt pkg for your OS so you still might end up building manually (My poor i5 4core had to attempt building nodejs26 because there wasn't a pkg for Ventura)
How long do you expect them to support Intel processors though? It’s been like 6 years since the last MacBook release had any Intel processor, and Apple doesn’t make OS updates anymore, so it doesn’t surprise me that Homebrew stopped too.
Years, honestly. After all, Intel Macs just received a major macOS release from Apple only 12 months ago. MacPorts manages to support all the way back to Leopard!
Same here, but I understand their position. Meanwhile I rely on packages publishing builds for Intel Mac in GitHub (surprisingly a lot) or building from source code. I just asked AI to build me install system.
I've been using homebrew for so long, I can't tell you how much it has helped me to spend more hours developing and less managing packages and updates, etc. Thank you so much, congratulations on the update!
Always a joy to see security and performance as a big highlight on a release. Brew is notably slow compared to the other package managers I use, but never in an unbearable way.
I've always used it on my Mac work machines, but always used my native package managers on Linux. What are the reasons to run homebrew on Linux? Better newer package support when you're on something slower moving like a Debian distro?
I've standardized my config scripts on using language managers for those tools (go, cargo, uv), which isn't perfect, so maybe brew is worth a chance.
I prefer to use Mise for everything nowadays. homebrew bootstrap specifically. A lot easier to manage all of my packages in one single file, homebrew, Node packages, etc.
I migrated our monorepo to use mise with bootstrap and mise-tasks. I was able to delete a whole heap of setup scripts and our brewfile. First time setup is extremely simple now and re-running for updates is blazing fast.
See the release notes: we now have experimental support for using any prefix shorter than the Linux default. We are aiming to eventually fully support (Tier 1) any prefix under 64 bytes long.
The dedicated user isn't really required; it just expects that /home/linuxbrew/.linuxbrew exists. That can just be a symlink to your home directory. But yes, creating that symlink requires root on most systems. Brew itself doesn't require root or that pathname; you can put packages anywhere, but then many will have to be built from scratch since the pre-built packages don't work. And you need bubblewrap installed (which requires root) to use the sandbox, but again that is optional.
All that said, when you are running without a sandbox installing to a nonstandard location, not everything works consistently. I run this mode all the time. But it has been getting better.
As a MacPorts users (generally light-weight, just a few things here and there):
Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?
I switched from Homebrew to MacPorts a few years ago because of Homebrew's aggressive dropping of macOS versions they consider "too old." Even in the top-comment announcement here[1] they are making sure to include that they are removing support, as if they're proud of it!
MacPorts generally doesn't care what version of macOS you run, so here I am. I'll probably never go back to Homebrew. MP is great!
Yes, the pride in aggressively dropping support for Macs that just received a major OS release from Apple only 12 months ago (and they were selling just three years ago) is a little off-putting.
I switched from MP to Homebrew over a decade ago. At the time, Homebrew was less finicky and better at resolving dependency conflicts. It was a lot easier to get a system running MacPorts into a an irretrievably borked state. Not long after, Homebrew install instructions became ubiquitous, whereas with MacPorts it seemed like you always had to figure it out for yourself — if the package was even available, which it more often wasn’t.
Haven’t used MacPorts since. Has it gotten any better at those things?
I switched from brew to macports, and I have not experienced the first problem at all. In fact, I had more problems with brew, where some package needed to be updated that I did not want, and I caused a cascade of issues.
The second has also never happened to me. macports installs the packages into a separate prefix, and you just add that to the path, so I wonder how it could bork irretrievably.
Regarding instructions: for most packages, I found that just replacing `brew` with `sudo port` is enough, as most ports are available. And quite a few install instructions mention homebrew together with macports. I have not run into missing packages, but sometimes the ones that existed were a little out of date.
I reluctantly switched from MacPorts to Homebrew around 2014. At that time Homebrew had that yuck factor by recommending it be installed into /usr/local rather than /opt. But still, I switched because there were more formulae in HB than ports in MP. And it turns out that the Homebrew install location is customizable anyways.
I switched from macports to homebrew a decade ago. I needed the lastest version of a program, and I found homebrew updated formulas faster than macports did
I use basically every general-purpose package manager available on macOS simultaneously in a kind of tiered hierarchy of preference.
Homebrew's best differentiated strength imo is the whole Cask subsystem, which basically automates GUI app installs via "first-party" artifacts like .dmg and .pkg files. That's what I still sometimes use it for even though I have other package managers available, including MacPorts, that I prefer for most other things.
The ordering goes something like the following: Nix > pkgsrc > MacPorts > Homebrew > mas (CLI frontend for the App Store).
Each kinda has its niche. Nix is just generally preferable for me, and it covers all of my needs 99% of the time. It also happens to be pretty fast in terms of actual installation even if evaluating the Nix code can be slow for complex projects.
For proper development toolchains, it's all Nix all the time. Those are per-project rather than global, and what can't be managed by Nix isn't managed at all. Nix is this an overriding constraint there, which has never really been a problem for me.
Pkgsrc is good for development tools and terminal apps, but Nix is generally even better for those, so for me it's just an escape hatch in case something is broken or missing in Nixpkgs and I'm too lazy to fix it, or I genuinely want some library installed with its headers findable globally (rare, because that's mostly bad practice imo). Also good if I want a backup copy of an exotic shell or something in case I want to rm -rf /nix and not be forced back into Bash or zsh, which is nice when I'm working on my macOS bootstrap scripts. On macOS, everything you install via Pkgsrc will be a binary install, so it's relatively fast and its performance is relatively predictable.
MacPorts is broadly useful so it's useful for the same things as Pkgsrc, but it's also better at providing GUI Mac apps, built from source. For a while I got Emacs here when Emacs in Nixpkgs had a problem building with native compilation support, for example. Also good for my macOS bootstrap scripts since they're written in literate style in Org mode; it can be nice to have a working Emacs to dump them to disk with even without Nix if I'm iterating on them. MacPorts often ends up building stuff from source on my system, which can be slow, but I don't care because I have very little installed via MacPorts.
Homebrew historically didn't feel "safe" for me for development dependencies for various reasons. Before sandboxing support, running and installing and managing things as your own user felt especially unsafe from a security perspective. Now it's a lot better, but it still feels wrong to have global-ish prefixes owned by a particular user. The aggressive in-place upgrades also feel quite brittle for development dependencies, but to some extent that's true of anything that's not project-local. I also don't like that installing GUI apps with Homebrew can end up putting binaries related to their dependencies and not needed at runtime into my PATH— that feels way messier than what I get with Nix. It can also historically be very slow for what it does, but if you're using it in the recommended way, you don't often have to build from source so you can still expect a faster experience than with MacPorts even though both nominally support binary packages.
All that said, Homebrew shines when it comes to extremely broad support for arbitrary Mac apps, often including proprietary ones, and support for the arbitrary range of installation procedures that macOS app developers expect you to use. It's also very good in terms of freshness for macOS packages. Nix is competitive in that respect, but none of the others remotely are. The stuff I don't like about where Homebrew puts things and the filesystem permissions are also fixable if you use a custom prefix. That's officially unsupported and means you can't use "bottles" (i.e., you'll need to build packages that aren't "casks" from source), but it works fine and has been totally stable for many years. If you understand some basic Unix norms and how to compile software from source, you should feel comfortable doing it.
I also like to keep Homebrew's bin/ paths off my PATH, and selectively symlink or wrap binaries installed via Homebrew back to ~/.local/bin by hand. That way I can install whatever I want via Homebrew without worrying about it getting unexpectedly involved in my development processes or command-line environment.
Because Homebrew has historically been so slow for me, I've tried to install as little with it as possible, which means installing even some Mac GUI apps via Nix. That's kind of a pain because if you want Spotlight to pick them up, you need little trampoline wrapper apps because it won't register symlinks into the Nix store. And when Nixpkgs' selection is lacking, you can extend it with brew-nix, which uses Homebrew's JSON API to automatically generate Nix packages. They work, but some apps just can't do everything they're designed to from the Nix store due to macOS limitations/security policies, so you have to kind of figure out which you can install via Nix yourself. It's extra machinery, and so if Homebrew is faster enough now I may look forward to dropping it and just using Homebrew as my first choice for all GUI apps.
The App Store sucks, needless to say, not least of all because it requires an active login to a large tech company. I only use it for VPN apps or security software where Apple forces me to.
I don't recommend my setup to people for whom package managers aren't a first-class interest, but it is perfectly stable and it's unlikely to get you into trouble.
I think most people would be served well by combininations of two package managers, of one of two forms: Nix + an escape hatch or Homebrew + a development toolchain manager.
For people who like macOS' app installation procedures: Nix + pkgsrc
For people who like Nix but want a disciplined escape hatch: Nix + MacPorts
For people who like Nix and want absolute coverage: Nix + Homebrew
For people who don't really care about how their package manager works but are developers: Homebrew + mise or Homebrew + Nix
For non-developers who just want an automated/centralized way to install software aside from the App Store: Homebrew (and probably especially the GUI)
I think the main thing for me is just that no one should have free-floating, ambient development dependencies. You shouldn't have some software project that depends on what version of Python is on your PATH or what packages from PyPI are globally installed via pip or whatever. You shouldn't be manually building unoconv or pandoc or something against some LibreOffice headers that live in /usr/local or /opt/local or anywhere like that. Ideally, shouldn't be doing `make install` anywhere— if you need to compile something for your own use, compile it by writing a package (or having an LLM write it, you lazy bum). If you observe that kind of basic package management hygiene, "switching" is largely trivial and doesn't involve any manual cleanup or fixing.
And if you spend a few minutes thinking about a preference order that you like and configure your PATH accordingly, all of these package managers can coexist so that you can "switch" gradually, at your leisure.
Excellent update, very speedy on upgrades now. Amazing what a little (safe) concurrency will do.
Homebrew.app, however, has a show-stopper for me. "Failed to decode Homebrew JSON output" on the installed/upgrades panel. I'm guessing the Discover panel would normally indicate which Formulae/Casks are already installed, but because it couldn't parse the JSON output, that feature (if it exists) doesn't work.
I'll file an issue—I know HN isn't your bug tracker :)
Edit: there's an issue there already, and I sorted out the root cause: iTerm2's shell integration. If you're using zsh as your shell, the solution is here [^0] in the second comment.
I’ve really been enjoying nix as my package manager on macos. It’s on a separate volume so feels even more isolated from clobbering my macos and has, in my uninformed opinion, better sandboxing and reproducible builds
I was surprised to see my Homebrew consider my macOS a Tier 2 for using the very latest macOS version and Xcode version… But I think it's because I don't have Xcode 27.0, which is presumably releasing tomorrow?
Congrats on the release @mikemcquaid. I like how the trusted taps feature could be opted into early. It made it easier to migrate my setup before it became compulsory. Hope big changes like that can keep the same flow. Keep up the great work!
If you're going to update that frequently, you may want to consider something that allows for cooldown like this [1]. I've gotten more nervous about supply-chain attacks over the last few months.
I hate to have to be this harsh as it is clear you did a lot of work, but I have warned members of the brew team about serious gaps here multiple times over the years and seemingly nothing has been done. Brew is not anywhere close to a level of supply chain security to be allowed anywhere near production access or production code review.
Language package managers are a joke and not worth comparing to but at least we can quarantine those. No security conscious person would run NPM outside of a VM or a container with code they did not review. But brew is a system package manager so the risk is not comparable. It might be the thing that installs the VM or container tools in the first place, so users have little way to protect themselves.
Your setup is based on the honor system and it is important people know that so they do not use it on any system they need to be able to trust.
If I were to create a fake identity and contribute my way to becoming a brew maintainer, I would have the power to create yet another pseudonym to submit malicious code that I "review" and merge.
Or since builds are mostly not reproducible a compromise of a single CI/CD pipeline could inject a trusting trust attack into a dependency of a dependency of the compiler, and then I own every downstream system that uses brew forever even after version updates.
Or maybe I compromised the github credentials of a single engineer and did a merge as them at the right moment when they were doing a bunch of others to get it lost in the noise. Without signing impersonation is easy.
I would not actually do any of these things, but someone else could have already, a year ago.
You will never solve any of these holes without full source bootstrapping, deterministic builds, mandating every maintainer sign every commit, and review with a well known and pinned keys individually controlled on smartcards, and then also sign every binary artifact with multiple keys after independent reproducible builds.
This is the bare minimum for a system package manager. Comparing ourselves to others does not cut it anymore, because patient humans and AI bots will absolutely take advantage of honor system security models.
Implying brew is secure enough for production use is going to get people hurt.
A responsible system package manager must trust no single human, no single credential, and no single machine.
They are all significant risks, and we pay significant money to JFrog for their X-ray product to scan and alert on bad dependencies, and significant internal tooling to track which package was used on which developer enclaves.
Those are also all just as bad but you can at least run those fully in containers or vms and never let them touch your host system.
Brew however is a system level package manager so it is expected to install your top level tools with substantial privilege, so for using it on a production capable system you would want maintainer signed commits, maintainer signed reviews, and 2+ maintainer signed reproducible builds, all with well known long lived keys controlled by smartcards of each maintainer on high trust systems.
I am not just talking out of my ass here. We do all of the above in stagex because it is the bare minimum.
"That front page" isn't the front page, it's the release notes for version 7.0.0.
The actual front page has "The Package Manager for Everywhere" as its subtitle (and that exact description as part of its <title>), and that is basically all you need to know. It's a staple for Unix-y power users on macOS (but supports Linux too, including WSL), and version 1.0 will be ten years old next week. You're not very far off from complaining that Postgres release notes don't explain that Postgres is a database.
Yes. Thank you. The link text gives the impression that is the front page and I didn't notice. I'm sure a lot of people don't notice which is the issue I'm trying to point out.
That doesn't make sense. Why do I need Homebrew to install the command line tools of macOS on macOS? Doesn't macOS already have them installed? Same for Linux, etc.
does it self-uninstall cleanly (i.e. without leaving a footprint behind) yet? if not I don’t care about this or the next ‘upgrade’, and I can’t believe Homebrew project leaders push upgrades without addressing this basic flaw.
Yes. If/when it doesn’t: it’s a bug and we’ll fix it. We can’t fix things people don’t report. Also: this is open source: you also could choose to fix it. Unsurprisingly the Homebrew maintainers do not spend a lot of their time uninstalling Homebrew.
An LLM helped with the initial tedium of rewording 1000s of PRs from maintainer centric language into user centric language. It was reviewed and edited (by a human) probably >20 times. Go look at the PR if you don’t believe me.
I used to do these all by hand and they took me multiple hours. I still probably spent over an hour, including a bunch of time on a family holiday today. Comments like this make me wonder why I bother sometimes.
homebrew is a critical, important piece of software, and I appreciate the effort.
I certainly don’t appreciate the non-effort from reflexive LLM-haters. We get it. You don’t like LLMs. Try to have an opinion and a personality that doesn’t revolve around nitpicking AI writing.
FWIW, I also got a bit of an LLM vibe skimming the changelog. In particular, the section about Linux sandboxing jumped out at me:
> Status in 7.0.0: kernels without Landlock continue working without Linux sandboxing in the less secure pre-6.0.0 configuration; brew doctor reports missing protection as an advisory.
> No replacement opt-out; unavailable Landlock remains advisory.
With that being said, I can kind of see why "eliminate all traces of AI writing styles" wouldn't be a goal of the review/editing process. I've been out of the Apple ecosystem for a while, but I imagine Homebrew has enthusiastically adopted LLMs for a lot of tasks. If the public communications reflect that, then people who don't like LLMs can bounce immediately, rather than getting invested in the project and feeling betrayed later.
Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).
Literally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was! I looked online to see if something changed and saw this post.
Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew.
Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.
Glad to hear it. A lot of time and energy has gone into performance work so glad that’s noticeable! Thanks for the kid words too <3
It is Rust now?
3 replies →
Thank you for Linux Homebrew! It works so damn well.
For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.
Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?
9 replies →
I don't understand the distinction you use here.
Then again I use versioned AppDirs on Linux since +20 years anyway, so I am not really into any arbitrary disctinction random linux distributions try to push down onto the (downstream) userbase. Besides, if you compile from source, why would you want to rely on the distribution package manager to begin with?
None of them allow for versioned AppDirs by default as far as I know; NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course), but as far as I know if you are on e. g. a debian system, you can not use it for a versioned AppDir layout.
3 replies →
Same, for me it made it possible for me to work on Linux with teammates on Mac with very little messing around of the setup scripts.
On Linux I use mise to install CLI tools
I don't know what I would do without brew on my Macs. Thank you and everyone who contributes!
Silly question - but how do you apply the cooldown to brew itself ?
I would think this is one of the most critical dependency that you would not want to get right away at let it rest for a couple of days
You can’t, by design. We instead apply if for you on upstream packages from NPM, PyPi, etc.
Our model is very different to those where cooldowns exist and make sense. As-is if would just delay security updates too.
Congrats and thank you to you and your team for maintaining critical infrastructure we all take for granted.
I think at one point you said you’re working on a rust rewrite? Is that still in the cards?
I tried it. It ended up being slower on most non-synthetic benchmarks (like repeatedly installing the same thing with warm caches).
The lessons learned were instead used to make the Ruby frontend much faster.
4 replies →
https://news.ycombinator.com/item?id=42535217
They experimented with it but ultimately decided to focus on perf with their existing ruby codebase.
https://github.com/Homebrew/brew/issues/7755#issuecomment-51...
would you please share what amount of the new dev (work done on brew) is AI/LLM-assisted. this major version bump was very quick to arrive compared to when v6 got released?
Can’t speak for others but a lot of my work. I review it all locally first. The flow feels a lot like reviewing human PRs locally.
https://github.com/MikeMcQuaid/AgentIDE
I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
2 replies →
Definitely notice the speed increase. Thank you for Homebrew. It's one thing that makes macOS bearable.
Was issue with upgrade running out of disk space fixed?
[dead]
TIL Homebrew has its own sandbox mechanism - looks like it's built around their own sandbox-exec wrapper, at least on macOS: https://github.com/Homebrew/brew/blob/d79ef822ab8136e393ed5f...
Yup! We’ve been using it for a really long time at this point.
Were using Bubblewrap on Linux and moved to Landlock this release.
P.S. HUGE fan of your blog and writing Simon, keep up the great work. It’s the #1 resource I recommend to anyone in the industry wanting to learn more about LLMs (and pelicans).
I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug
Why would you even use python without uv anymore, and have a system python binary and virtual envs linked to it?
> Why would you even use python without uv anymore
Probably wouldn't:
https://mise.jdx.dev/mise-cookbook/python.html#mise-uv
> have a system python binary and virtual envs linked to it
I'm not sure if you're saying avoid using system python?
In my experience so far, you never want to develop complex software locked to system versions of runtimes. Too often you need a bleeding edge feature, or conversely need to postpone updating due to needing an old version for some reason.
3 replies →
Python might be just one of the languages required by the dev stack not the only language. Mise is the right tool for the job.
10 replies →
I split my usage. Homebrew for OS things mise for the various tooling.
The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.
You can use mise for install homebrew items btw so if you get a new computer you just drop the config.toml inside the mise and install.
This is all you have to add to the config file:
[bootstrap.packages]
"brew:git" = "latest"
"brew-cask:ghostty" = "latest"
3 replies →
I also started using Mise for global CLI tools instead of brew and it’s working really well
Eg: mise use -g gcloud instead of brew install xxx
It can even do that for npm packages! Like mise use -g npm:xxx
re: npm, if you upgrade your global node version, you will lose that installation, right?
2 replies →
Mise is really sloppily vibe coded these days
What broke and affected you?
my split: brew for casks, mise for tools
mise also can manage brew
Okay
The GUI is pretty sharp, but I don’t like it uses emoji instead of SF symbols.
Is it Claude or Codex built?
I didn’t build it. The emoji were my idea. I (and Homebrew) have used them heavily before LLMs did. Maybe LLMs loving them is my fault. Sorry if so.
Have we pinned down the emdashes source yet? ;-P
2 replies →
I don’t get these questions asking if it’s codex or Claude – I see them often. Does it matter? There are other options out there also, it feels strange to ask this. Like asking “is your car a Toyota or a BMW?“
If you say "AI tools", some vibe-coders try to equivocate between tools that generate the whole program for you and, like, an editor that uses an scoring algorithm to decide which method to show at the top of an autocomplete list. But if you say "vibe coding", some vibe-coders try to claim that what they're doing technically isn't vibe coding because they applied some non-zero amount of testing or review during the process.
If you ask "did you build this using Codex or Claude", it removes most of the wiggle room. And it's worded pretty neutrally, so it will often get vibe-coders who aren't technically using either of those tools to say something like, "Actually, I've built a custom harness for DeepSeek..." instead of an outright denial.
Long term it matters very much if your car is Toyota or BMW or Kia or John Deere though.
I think some users are also conscious about the longevity of their tooling related to LLM usage, too. Whether it has an effect or not, we've yet to find out.
2 replies →
Farewell, Homebrew. It's been a good run.
- 2019 Intel iMac user.
Sorry we couldn’t support this for longer :(
From the release notes:
> The Intel support decision reflects the limits of a volunteer-run project: Apple have dropped Intel x86_64 support from macOS 27 Golden Gate and GitHub Actions will retire Intel macOS runners in autumn 2027. If Apple and Microsoft’s GitHub, two of the world’s largest technology companies, cannot continue supporting macOS Intel x86_64, sadly neither can Homebrew. MacPorts still supports macOS Intel x86_64 and is likely to provide better results on this platform.
My personal opinion, but I'd rather see wider macOS support than Linux support, if it's a sheer matter of where time is allocated.
Linux already has world class package managers.
2 replies →
How come that MacPorts supports macOS versions all the way back to 10.5 Leopard in the latest version?
5 replies →
So much of GNU et al is already in Homebrew that I wonder how close you are to being able to support Intel Macs using the Linux/amd64 branch (or backend or whatever you call it) of Homebrew or something close to it, possibly after installing a few base libraries and utilities from MacPorts.
ETA: I've got Homebrew 7 building packages from source on an Intel Mac running Monterey; nothing yet required from MacPorts and a pretty minimal patch to the installer. I'd probably want to add legacy-support from MacPorts and update the macOS build environment to add it as an extra library on Intel Macs if I were to continue.
That being said, I'm sure y'all talked about continuing to support Intel Macs as source-based and ultimately decided against it, so it's unlikely that this will be interesting to the team. But let me know if I'm wrong and I'll open a couple PRs for further discussion.
> GitHub Actions will retire Intel macOS runners in autumn 2027
But why drop before that?
Thank you for all of your hard work, I’ve been very happily using Homebrew on OS X / macOS since 2010.
No need to be sorry, the situation is understandable.
very disappointed about this
1 reply →
We've all gone through it :-( Happy users of the (really good) software until our hardware gets "too old" and the inevitable rug pull.
You have no idea what rug pull means, do you?
Uncompensated volunteers dropping support for a 7 year old device that is shortly going to be unsupported by the manufacturer isn't a rug pull.
Entitlement can be wild, volunteers are volunteers. Consumers of volunteer output are free to support their use cases themselves on their own time. Find an ARM Mac used (like an M1) and upgrade.
9 replies →
That hardly happens on desktop/laptop Linux. Seems like a proprietary OS problem tbh.
2 replies →
Any modern Linux distro works great on Intel Macs. Been daily driving with Debian 13 initially and now NixOS on my MBP2015, have not used the MacOS Sequoia partition for months!
Same boat: 2018 Intel Mac mini, stuck on macOS 10.15.
When I eventually upgrade my hardware, I’ll happily use Homebrew again. In the meantime, MacPorts!
> Farewell, Homebrew. It's been a good run. - 2019 Intel iMac user.
welcome. - 2015 intel macbook user
MacPorts is still there for us.
Check out MacPorts. They have installers going all the way back to Leopard.
I'm probably the millionth person to parrot this to you but my goodness you are a hero if you can tolerate the Intel Mac experience in 2026.
I thought my Intel Mac from that era was incredibly weird. Little firmware-ish things were so glitchy and sluggish. At some point the wake from sleep/lid open just took forever in ways that didn't happen on older Intel Mac models (or maybe I was going crazy). I just had this strange feeling that Apple was knowingly half-hearting their Intel drivers and products as a whole as they were putting more energy into developing Apple Silicon.
Dude, you owe it to yourself to just grab a used M2 MacBook Air or something along those lines. Treat yourself. You'll be kicking yourself for not doing so sooner. (Don't get a MacBook Neo, too many compromises including poor battery life, a used Air is much better, and if you use more than one external monitor use caution on what model/CPU you choose).
Sure, a laptop should last longer than 7 years, but this is one of those "Apple yeets out a new architecture" exceptions like the PowerPC to Intel transition. Better to accept it and move on. 7 years is still a solid run. You've only got ~2 more years left until you start losing security updates anyway.
The other machine I highly recommend is Linux/Framework 13 Pro with the Intel Core Ultra Series 3, although that's a whole different price class, and obviously not everyone can make that move in terms of software compatibility.
> used M2 MacBook Air
And what if you are a developer and need to replace a well specced Mac and don’t have serious budget, especially considering recent memory and storage price increases?
Rather than a coffee table status symbol or a fashion accessory for pretending to write a novel in the coffee shop?
If the old Intel Mac still works, what should one do? Dump it into a landfill?
2 replies →
Awesome, I just checked and had already upgraded at some point. I run the alias command below every now and then which keeps everything up to date.
Interesting. I use `--greedy` for casks but not regular formulae.
Adding the `-y`-s is probably cowboy shit. I do have a `brew autoremove` at the end though
[flagged]
And that's the end of Homebrew for me as a user. I like the app, but my old Intel MacBook apparently can't handle it anymore.
I'm back to the old installation methods !
I recommend MacPorts, the migration is easy, you copy the package names you installed with brew, uninstall homebrew (there's an unisntall script on brew.sh FAQ section, it will also uninstall all homebrew packages (but not the casks)) then install macports and reinstall the packages with sudo port. Although the selection is smaller on macports and newer packages might not have a prebuilt pkg for your OS so you still might end up building manually (My poor i5 4core had to attempt building nodejs26 because there wasn't a pkg for Ventura)
Actually, Homebrew 7 is supported on your Mac, you just have to install Linux to use it. :)
If you want to continue using the same MacBook that will be only path forward when Apple decides to EOL it (if it hasn't already happened).
I'm a long time Homebrew on Linux user, it works really well. I always prefer it over the distro supplied package manager for user facing CLI apps.
Apple was selling Intel Mac Pros in 2023, it's absurd these things are coming up on EOL already.
2 replies →
MacPorts has been there this whole time.
I've used MacPorts on macOS versions that don't support the latest OS, which per homebrew policy seems to be versions upto N-2.
Apart from the issue of having to compile the downloaded software leading to spinning fans, I'm not too concerned.
How long do you expect them to support Intel processors though? It’s been like 6 years since the last MacBook release had any Intel processor, and Apple doesn’t make OS updates anymore, so it doesn’t surprise me that Homebrew stopped too.
Are you implying that a 6 year old hardware is as good as a paperweight? Outside of the Apple fairyland this is just bonkers.
I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.
15 replies →
I have one of the last Intel Macs and works perfectly fine (on Sonoma). How long should I expect working tech being supported?
I am already looking at Linux, but still need to get out of the Apple ecosystem. I am not going to spend +2500 Euros every 5 years on a laptop
3 replies →
And given the performance jump from Intel to Apple Silicon, the perceived difference is 10+ years even.
2 replies →
Years, honestly. After all, Intel Macs just received a major macOS release from Apple only 12 months ago. MacPorts manages to support all the way back to Leopard!
Same here, but I understand their position. Meanwhile I rely on packages publishing builds for Intel Mac in GitHub (surprisingly a lot) or building from source code. I just asked AI to build me install system.
I’m installing Linux on my 2019 16” today.
FYI Macos will also stop with major updates for Intel macs. You can just keep using brew 6 on macos 26.
Have you tried Mac Ports?
You do realize Intel support is gone, right? You won't be installing anything on your Intel Mac very soon...
[flagged]
I've been using homebrew for so long, I can't tell you how much it has helped me to spend more hours developing and less managing packages and updates, etc. Thank you so much, congratulations on the update!
Always a joy to see security and performance as a big highlight on a release. Brew is notably slow compared to the other package managers I use, but never in an unbearable way.
I've always used it on my Mac work machines, but always used my native package managers on Linux. What are the reasons to run homebrew on Linux? Better newer package support when you're on something slower moving like a Debian distro?
I've standardized my config scripts on using language managers for those tools (go, cargo, uv), which isn't perfect, so maybe brew is worth a chance.
People have been integrating/recommending brew on immutable distributions.
> Better newer package support when you're on something slower moving like a Debian distro?
exactly
I prefer to use Mise for everything nowadays. homebrew bootstrap specifically. A lot easier to manage all of my packages in one single file, homebrew, Node packages, etc.
https://mise.jdx.dev/bootstrap/packages/brew.html
I migrated our monorepo to use mise with bootstrap and mise-tasks. I was able to delete a whole heap of setup scripts and our brewfile. First time setup is extremely simple now and re-running for updates is blazing fast.
mise has been an absolute delight.
Does installation still require root and a dedicated user account on Linux?
That really put me off.
See the release notes: we now have experimental support for using any prefix shorter than the Linux default. We are aiming to eventually fully support (Tier 1) any prefix under 64 bytes long.
Wait what? Why prefix length limits? Linux paths can be 4096 bytes long, I can't imagine y'all are hitting that?
6 replies →
The dedicated user isn't really required; it just expects that /home/linuxbrew/.linuxbrew exists. That can just be a symlink to your home directory. But yes, creating that symlink requires root on most systems. Brew itself doesn't require root or that pathname; you can put packages anywhere, but then many will have to be built from scratch since the pre-built packages don't work. And you need bubblewrap installed (which requires root) to use the sandbox, but again that is optional.
All that said, when you are running without a sandbox installing to a nonstandard location, not everything works consistently. I run this mode all the time. But it has been getting better.
Bubblewrap is history starting with 7.0.0 according to the release notes
I always download the install script and change the directory to my user home directory, ~/.brew
Does that break anything? Surprised it’s not the default.
The dedicated user account is optional.
It uses root once to chown its prefix directory /home/linuxbrew/.linuxbrew
Unfortunately this project has a case of dread with every update to me. To see what is being force changed, worse support or even removed features.
Looks like this release breaks Intel Macs. Very very sad. Not even 5+ year old hardware is apparently supportable to some devs
As a MacPorts users (generally light-weight, just a few things here and there):
Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?
I switched from Homebrew to MacPorts a few years ago because of Homebrew's aggressive dropping of macOS versions they consider "too old." Even in the top-comment announcement here[1] they are making sure to include that they are removing support, as if they're proud of it!
MacPorts generally doesn't care what version of macOS you run, so here I am. I'll probably never go back to Homebrew. MP is great!
1: https://news.ycombinator.com/item?id=49681546
Yes, the pride in aggressively dropping support for Macs that just received a major OS release from Apple only 12 months ago (and they were selling just three years ago) is a little off-putting.
I switched from MP to Homebrew over a decade ago. At the time, Homebrew was less finicky and better at resolving dependency conflicts. It was a lot easier to get a system running MacPorts into a an irretrievably borked state. Not long after, Homebrew install instructions became ubiquitous, whereas with MacPorts it seemed like you always had to figure it out for yourself — if the package was even available, which it more often wasn’t.
Haven’t used MacPorts since. Has it gotten any better at those things?
I switched from brew to macports, and I have not experienced the first problem at all. In fact, I had more problems with brew, where some package needed to be updated that I did not want, and I caused a cascade of issues.
The second has also never happened to me. macports installs the packages into a separate prefix, and you just add that to the path, so I wonder how it could bork irretrievably.
Regarding instructions: for most packages, I found that just replacing `brew` with `sudo port` is enough, as most ports are available. And quite a few install instructions mention homebrew together with macports. I have not run into missing packages, but sometimes the ones that existed were a little out of date.
I reluctantly switched from MacPorts to Homebrew around 2014. At that time Homebrew had that yuck factor by recommending it be installed into /usr/local rather than /opt. But still, I switched because there were more formulae in HB than ports in MP. And it turns out that the Homebrew install location is customizable anyways.
I switched from macports to homebrew a decade ago. I needed the lastest version of a program, and I found homebrew updated formulas faster than macports did
I use basically every general-purpose package manager available on macOS simultaneously in a kind of tiered hierarchy of preference.
Homebrew's best differentiated strength imo is the whole Cask subsystem, which basically automates GUI app installs via "first-party" artifacts like .dmg and .pkg files. That's what I still sometimes use it for even though I have other package managers available, including MacPorts, that I prefer for most other things.
The ordering goes something like the following: Nix > pkgsrc > MacPorts > Homebrew > mas (CLI frontend for the App Store).
Each kinda has its niche. Nix is just generally preferable for me, and it covers all of my needs 99% of the time. It also happens to be pretty fast in terms of actual installation even if evaluating the Nix code can be slow for complex projects.
For proper development toolchains, it's all Nix all the time. Those are per-project rather than global, and what can't be managed by Nix isn't managed at all. Nix is this an overriding constraint there, which has never really been a problem for me.
Pkgsrc is good for development tools and terminal apps, but Nix is generally even better for those, so for me it's just an escape hatch in case something is broken or missing in Nixpkgs and I'm too lazy to fix it, or I genuinely want some library installed with its headers findable globally (rare, because that's mostly bad practice imo). Also good if I want a backup copy of an exotic shell or something in case I want to rm -rf /nix and not be forced back into Bash or zsh, which is nice when I'm working on my macOS bootstrap scripts. On macOS, everything you install via Pkgsrc will be a binary install, so it's relatively fast and its performance is relatively predictable.
MacPorts is broadly useful so it's useful for the same things as Pkgsrc, but it's also better at providing GUI Mac apps, built from source. For a while I got Emacs here when Emacs in Nixpkgs had a problem building with native compilation support, for example. Also good for my macOS bootstrap scripts since they're written in literate style in Org mode; it can be nice to have a working Emacs to dump them to disk with even without Nix if I'm iterating on them. MacPorts often ends up building stuff from source on my system, which can be slow, but I don't care because I have very little installed via MacPorts.
Homebrew historically didn't feel "safe" for me for development dependencies for various reasons. Before sandboxing support, running and installing and managing things as your own user felt especially unsafe from a security perspective. Now it's a lot better, but it still feels wrong to have global-ish prefixes owned by a particular user. The aggressive in-place upgrades also feel quite brittle for development dependencies, but to some extent that's true of anything that's not project-local. I also don't like that installing GUI apps with Homebrew can end up putting binaries related to their dependencies and not needed at runtime into my PATH— that feels way messier than what I get with Nix. It can also historically be very slow for what it does, but if you're using it in the recommended way, you don't often have to build from source so you can still expect a faster experience than with MacPorts even though both nominally support binary packages.
All that said, Homebrew shines when it comes to extremely broad support for arbitrary Mac apps, often including proprietary ones, and support for the arbitrary range of installation procedures that macOS app developers expect you to use. It's also very good in terms of freshness for macOS packages. Nix is competitive in that respect, but none of the others remotely are. The stuff I don't like about where Homebrew puts things and the filesystem permissions are also fixable if you use a custom prefix. That's officially unsupported and means you can't use "bottles" (i.e., you'll need to build packages that aren't "casks" from source), but it works fine and has been totally stable for many years. If you understand some basic Unix norms and how to compile software from source, you should feel comfortable doing it.
I also like to keep Homebrew's bin/ paths off my PATH, and selectively symlink or wrap binaries installed via Homebrew back to ~/.local/bin by hand. That way I can install whatever I want via Homebrew without worrying about it getting unexpectedly involved in my development processes or command-line environment.
Because Homebrew has historically been so slow for me, I've tried to install as little with it as possible, which means installing even some Mac GUI apps via Nix. That's kind of a pain because if you want Spotlight to pick them up, you need little trampoline wrapper apps because it won't register symlinks into the Nix store. And when Nixpkgs' selection is lacking, you can extend it with brew-nix, which uses Homebrew's JSON API to automatically generate Nix packages. They work, but some apps just can't do everything they're designed to from the Nix store due to macOS limitations/security policies, so you have to kind of figure out which you can install via Nix yourself. It's extra machinery, and so if Homebrew is faster enough now I may look forward to dropping it and just using Homebrew as my first choice for all GUI apps.
The App Store sucks, needless to say, not least of all because it requires an active login to a large tech company. I only use it for VPN apps or security software where Apple forces me to.
I don't recommend my setup to people for whom package managers aren't a first-class interest, but it is perfectly stable and it's unlikely to get you into trouble.
I think most people would be served well by combininations of two package managers, of one of two forms: Nix + an escape hatch or Homebrew + a development toolchain manager.
For people who like macOS' app installation procedures: Nix + pkgsrc
For people who like Nix but want a disciplined escape hatch: Nix + MacPorts
For people who like Nix and want absolute coverage: Nix + Homebrew
For people who don't really care about how their package manager works but are developers: Homebrew + mise or Homebrew + Nix
For non-developers who just want an automated/centralized way to install software aside from the App Store: Homebrew (and probably especially the GUI)
I think the main thing for me is just that no one should have free-floating, ambient development dependencies. You shouldn't have some software project that depends on what version of Python is on your PATH or what packages from PyPI are globally installed via pip or whatever. You shouldn't be manually building unoconv or pandoc or something against some LibreOffice headers that live in /usr/local or /opt/local or anywhere like that. Ideally, shouldn't be doing `make install` anywhere— if you need to compile something for your own use, compile it by writing a package (or having an LLM write it, you lazy bum). If you observe that kind of basic package management hygiene, "switching" is largely trivial and doesn't involve any manual cleanup or fixing.
And if you spend a few minutes thinking about a preference order that you like and configure your PATH accordingly, all of these package managers can coexist so that you can "switch" gradually, at your leisure.
the gui homebrew manager is a nice addition!
it can be installed with:
brew install homebrew-app
Excellent update, very speedy on upgrades now. Amazing what a little (safe) concurrency will do.
Homebrew.app, however, has a show-stopper for me. "Failed to decode Homebrew JSON output" on the installed/upgrades panel. I'm guessing the Discover panel would normally indicate which Formulae/Casks are already installed, but because it couldn't parse the JSON output, that feature (if it exists) doesn't work.
I'll file an issue—I know HN isn't your bug tracker :)
Edit: there's an issue there already, and I sorted out the root cause: iTerm2's shell integration. If you're using zsh as your shell, the solution is here [^0] in the second comment.
[0]: https://github.com/Homebrew/BrewUI/issues/167/
I’ve really been enjoying nix as my package manager on macos. It’s on a separate volume so feels even more isolated from clobbering my macos and has, in my uninformed opinion, better sandboxing and reproducible builds
I was surprised to see my Homebrew consider my macOS a Tier 2 for using the very latest macOS version and Xcode version… But I think it's because I don't have Xcode 27.0, which is presumably releasing tomorrow?
This is a bug, sorry. Working on it.
Fixed and in 7.0.1.
You can download Xcode 27 RC now from https://developer.apple.com/download/applications/.
What is the impact of being tier 2?
I’ll update Xcode, but I will definitely not install macOS 27.0
Not usually a “+1” or “Me too!” kinda guy but homebrew is incredible and makes dev on Mac quite seamless. Huge thanks to the team.
I am quite disappointed by their decision to remove wine[1] from brew. The utility of it is obvious, and it's very popular software.
[1] https://formulae.brew.sh/cask/wine-stable
I don’t think utility or popularity had anything to do with the decision. It’s just that they no longer support casks with unsigned binaries.
You could create a third-party tap to install wine via homebrew.
Congrats on the release @mikemcquaid. I like how the trusted taps feature could be opted into early. It made it easier to migrate my setup before it became compulsory. Hope big changes like that can keep the same flow. Keep up the great work!
Thanks for the hard work, but the Tahoe limitation for the GUI app is absolutely ridiculous.
Yeah, I'm holding onto Sequoia until after Golden Gate is GA. I've heard nothing good about Tahoe.
same. "macOS Tahoe 26+" requirement is a bummer.
Fantastic, thx for the effort!
Does it still need root on Linux? That makes it an instant no go.
For initial installation to the default prefix someone needs to create the home directory and that person is probably root.
We hope to allow all prefixes under 64 bytes in future.
I guess the Hackintosh era is (finally) facing its death...
Tried the app. Just gives me the error message "Failed to decode Homebrew JSON output".
A new era of native macOS apps is upon us.
GUIs abound. Rejoice!
Time to `brew update && brew upgrade` later today. Always a little nervous, but Homebrew usually makes it painless.
I have this bound to an alias: bu
Run it every couple of days, easy peasy.
If you're going to update that frequently, you may want to consider something that allows for cooldown like this [1]. I've gotten more nervous about supply-chain attacks over the last few months.
1. https://github.com/whoschek/homebrew-cooldown
2 replies →
Thank you so much for doing this, for years you make me feel like home, or the year 2010. Please don't ever stop!
still needs fucking 'sudo'
[flagged]
[flagged]
[dead]
[flagged]
https://docs.brew.sh/Homebrew-Security-and-Supply-Chain
We take supply chain security very seriously, moreso than many package managers.
I hate to have to be this harsh as it is clear you did a lot of work, but I have warned members of the brew team about serious gaps here multiple times over the years and seemingly nothing has been done. Brew is not anywhere close to a level of supply chain security to be allowed anywhere near production access or production code review.
Language package managers are a joke and not worth comparing to but at least we can quarantine those. No security conscious person would run NPM outside of a VM or a container with code they did not review. But brew is a system package manager so the risk is not comparable. It might be the thing that installs the VM or container tools in the first place, so users have little way to protect themselves.
Your setup is based on the honor system and it is important people know that so they do not use it on any system they need to be able to trust.
If I were to create a fake identity and contribute my way to becoming a brew maintainer, I would have the power to create yet another pseudonym to submit malicious code that I "review" and merge.
Or since builds are mostly not reproducible a compromise of a single CI/CD pipeline could inject a trusting trust attack into a dependency of a dependency of the compiler, and then I own every downstream system that uses brew forever even after version updates.
Or maybe I compromised the github credentials of a single engineer and did a merge as them at the right moment when they were doing a bunch of others to get it lost in the noise. Without signing impersonation is easy.
I would not actually do any of these things, but someone else could have already, a year ago.
You will never solve any of these holes without full source bootstrapping, deterministic builds, mandating every maintainer sign every commit, and review with a well known and pinned keys individually controlled on smartcards, and then also sign every binary artifact with multiple keys after independent reproducible builds.
This is the bare minimum for a system package manager. Comparing ourselves to others does not cut it anymore, because patient humans and AI bots will absolutely take advantage of honor system security models.
Implying brew is secure enough for production use is going to get people hurt.
A responsible system package manager must trust no single human, no single credential, and no single machine.
2 replies →
How is that any different from PyPI, npm, cargo, etc?
They are all significant risks, and we pay significant money to JFrog for their X-ray product to scan and alert on bad dependencies, and significant internal tooling to track which package was used on which developer enclaves.
Those are also all just as bad but you can at least run those fully in containers or vms and never let them touch your host system.
Brew however is a system level package manager so it is expected to install your top level tools with substantial privilege, so for using it on a production capable system you would want maintainer signed commits, maintainer signed reviews, and 2+ maintainer signed reproducible builds, all with well known long lived keys controlled by smartcards of each maintainer on high trust systems.
I am not just talking out of my ass here. We do all of the above in stagex because it is the bare minimum.
https://github.com/whoschek/homebrew-cooldown
[flagged]
"That front page" isn't the front page, it's the release notes for version 7.0.0.
The actual front page has "The Package Manager for Everywhere" as its subtitle (and that exact description as part of its <title>), and that is basically all you need to know. It's a staple for Unix-y power users on macOS (but supports Linux too, including WSL), and version 1.0 will be ten years old next week. You're not very far off from complaining that Postgres release notes don't explain that Postgres is a database.
Yes. Thank you. The link text gives the impression that is the front page and I didn't notice. I'm sure a lot of people don't notice which is the issue I'm trying to point out.
If you actually clicked through to their homepage, I imagine you would find the “what does homebrew do” section quite enlightening.
I did. If you actually read what I wrote you would see that I read it.
It's a package manager.
The second header on the main page:
What Does Homebrew Do?
Homebrew installs the command-line tools and applications you need across macOS, Linux and WSL.
That doesn't make sense. Why do I need Homebrew to install the command line tools of macOS on macOS? Doesn't macOS already have them installed? Same for Linux, etc.
4 replies →
It’s a package manager for Mac.
So Mac doesn't have a package manager?
2 replies →
It’s just another software package manager for installing dev tools
does it self-uninstall cleanly (i.e. without leaving a footprint behind) yet? if not I don’t care about this or the next ‘upgrade’, and I can’t believe Homebrew project leaders push upgrades without addressing this basic flaw.
Yes. If/when it doesn’t: it’s a bug and we’ll fix it. We can’t fix things people don’t report. Also: this is open source: you also could choose to fix it. Unsurprisingly the Homebrew maintainers do not spend a lot of their time uninstalling Homebrew.
[dead]
These release notes appear generated by LLM, with the usual extreme verbosity. Wish a human had done a better job editing these.
An LLM helped with the initial tedium of rewording 1000s of PRs from maintainer centric language into user centric language. It was reviewed and edited (by a human) probably >20 times. Go look at the PR if you don’t believe me.
I used to do these all by hand and they took me multiple hours. I still probably spent over an hour, including a bunch of time on a family holiday today. Comments like this make me wonder why I bother sometimes.
Don’t let the reflexive grumps get you down.
homebrew is a critical, important piece of software, and I appreciate the effort.
I certainly don’t appreciate the non-effort from reflexive LLM-haters. We get it. You don’t like LLMs. Try to have an opinion and a personality that doesn’t revolve around nitpicking AI writing.
FWIW, I also got a bit of an LLM vibe skimming the changelog. In particular, the section about Linux sandboxing jumped out at me:
> Status in 7.0.0: kernels without Landlock continue working without Linux sandboxing in the less secure pre-6.0.0 configuration; brew doctor reports missing protection as an advisory.
> No replacement opt-out; unavailable Landlock remains advisory.
With that being said, I can kind of see why "eliminate all traces of AI writing styles" wouldn't be a goal of the review/editing process. I've been out of the Apple ecosystem for a while, but I imagine Homebrew has enthusiastically adopted LLMs for a lot of tasks. If the public communications reflect that, then people who don't like LLMs can bounce immediately, rather than getting invested in the project and feeling betrayed later.
Does it surprise you that people are getting more skeptical when the software that installs system packages is getting more and more generated by AI?
1 reply →
Perhaps you should volunteer your services so that the project for which you paid $0 can have release notes more to your liking.