Show HN: Homebrew 6.0.0(brew.sh) Today, I’m proud to announce Homebrew 6.0.0. The most significant changes since 5.1.0 are a new tap trust security mechanism, the new faster, smaller, default internal Homebrew JSON API, sandboxing on Linux, better defaults informed by our user survey, many brew bundle improvements, improved performance and initial support for macOS 27 (Golden Gate). Happy to discuss any questions here! |
Funnily Mise does not support dependencies, and I was quite surprised that it mostly doesn't matter, as either pnpm/uv handles that, or it's a static binary that just works. In the past, had the unfortunate experience of packaging a Python application for Homebrew (the ridiculous process involved importing around 50 dependencies as "resources", building every single one from source or manually checking if it's already on Homebrew, declaring build toolchains for 5 different programming languages as dependencies, waiting over an hour for CI to finish on every update, then an upstream update introduced a "build-time dependency loop" and the project suddenly became unpackable for Homebrew) so I totally get why Mise took the "easy way out" and just relies on language-specific package managers directly.
Only thing from my Brewfile that I couldn't replace was the Docker CLI (needed to interact with Colima). And I still use Homebrew for casks. I encourage others to experiment with their dev setups, there are some amazing new tools out there.
Projects then have their own dependencies, e.g. https://github.com/i-am-bee/agentstack/blob/main/mise.toml
Mise also has a task runner which automatically uses correct tools. Onboarding a new team member is super easy now, they just need Mise, "mise install" and they're up.
We are not many [1], but Homebrew has been a great way to quickly bootstrap an environment in immutable Linux distributions.
Note that certain operating systems such as Universal Blue's Bazzite (1.28%), Bluefin (0.49%) and Aurora (0.28%) default to bundling Homebrew [2].
The only people I want to trust to quickly ship new code to my machine are Apple and my browser (which handles more untrusted input than anything else).
For everything else (vscode and its extensions, npm, homebrew, and all the apps that self-update), I prefer to err on the side of waiting a few days.
Some exceptional 0days might warrant a cooldown bypass, but even in its current form users are vulnerable to 0days until they run brew upgrade.
I know supporting Intel is an ordeal and a choice, but I'm firmly on the camp that Homebrew should find a way to maintain Intel support as long as possible.
- `formula@version` packages
- `brew version-install` (which uses `brew extract` and `brew tap-new` under the hood)
- `version_file:` support in `brew bundle
- `brew pyenv-sync`
I noticed that homebrew updated _all_ my casks when running 'brew upgrade' (even those with "auto_updates: true" in their Cask JSON API).
Is this intended, new default behavior? This did not use to happen...
See also: https://docs.brew.sh/FAQ#why-arent-some-apps-included-during...
I read this as "This means if you close your eyes you don’t see things, which is a bummer."
When you instruct the system not to tell you things, the system not telling you those things is a bummer?
If I could get more of the tech I interact with to stop doing things I didn't ask it to, it would reduce a lot of stress and wasted time.
For others still using Homebrew: a lot of work has gone into upgrading only when we absolutely have to and showing these upgrades to the user before we do them, including in this release.
pypi, npm, and even github (through releases) are registries.
Also, where we package things from NPM/PyPi/RubyGems that have been subject to these attacks: we already apply cooldowns for you both when packaging and when creating PRs to update to new versions.
Relevant parts for those who have cool-downs at the top of mind:
> Across Homebrew’s history far more users have been protected by shipping zero-day fixes quickly than have been exposed to npm-style token-theft or crypto-mining attacks, so a global cooldown would be a net negative for most users’ security. The deeper reason Homebrew does not need a general cooldown is that, unlike language package managers, it already separates publishing from distribution: an upstream release does not reach users until it has passed human review, CI and checksum verification, which is the very review window that language-ecosystem cooldowns are trying to recreate.
[...]
> For ecosystems with a track record of fast-moving supply-side attacks, Homebrew applies a download cooldown: a freshly-published upstream version is not adopted immediately, giving the wider community time to detect and report a malicious release before Homebrew users are exposed. Cooldowns have been added for:
Bundler
RubyGems livecheck
npm and pip defaults
PyPI resource resolution
npm and PyPI in bumpYour doc says "Human review of each release." What does that actually entail?
uv had a release at 10:21am yesterday with 7,060 additions and 2,409 deletions. The new release was available in homebrew at 11:46am. What human review happened there?
I don't know of any other OS package manager that ships code this quickly to users. Arch Linux has not pushed the new release of uv yet, for example.
For those who don't know what broxit is talking about, they're referring to something like --minimum-release-age/minimumReleaseAge in many pieces of software and package managers to reduce vulnerability to supply chain attacks. Often times, such attacks are detected within a few days of compromise.
Here's Bun's, as an example: https://bun.com/docs/pm/cli/install#minimum-release-age
It annoyed me this week because I only had a few minutes to try elixir 1.20 after the announcement, and brew lagged behind. You can install erl and elixir by other means (I prefer to run my own toolchains) but it wasn’t worth doing in that moment.
Brew has or used to have a source option for some recipes and that basicallllly solves it too, if you squint.
> Cooldowns, livecheck and bumping
If the ask is "who reviewed the diff": yes, a human didn't do that. That's not actually happening for all packages in any meaningful large ecosystem. I'm still unconvinced a cooldown solves that until e.g. we have an open source security scanner that runs on all Homebrew packages and requires a cooldown. Even in that case, my suggestion would be that we just run it in our own CI and block package release.