Hacker News Reader

Comment by broxit | Hacker News Reader

Thanks for the update. Is there any chance we can get some kind of cooldown mechanism in Homebrew?

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.

View on HN

https://docs.brew.sh/Supply-Chain-Security details how we’re handling cooldowns and why we have a very different risk profile to e.g. NPM.

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.

That doc is very useful and confidence inspiring in terms of being mainly about people and process, rather than about one single technical solution.

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 bump

Just a FYI: Bundler now supports cooldown [1].

[1]: "Cool down before you install: give new gems a few days to be vetted" - https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-b...

Glad to see that Homebrew is taking security seriously. Still, I want to minimize the number of parties who can quickly get new code onto my machine.

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

Our automation or a human submitted a PR, it was built and tested in our sandboxed ephemeral CI environments, a human Homebrew maintainer reviewed the CI results and PR diff and approved it for merge which happened automatically if so.

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.

> Even in that case, my suggestion would be that we just run it in our own CI and block package release.

I agree.

> open source security scanner that runs on all Homebrew packages and requires a cooldown.

I think that is where all this is going in the longterm.

Until then, any upstream shenanigans are more likely to surface in hours 0-48 after a new release than hours 0-4.

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

Most handle this by having release channels. You would `brew set-channel stable/edge`.

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.

It's in this release, see this section:

> Cooldowns, livecheck and bumping

That's only for upstream packages, i.e. what the CI pulls in when building bottles. Homebrew itself is a rolling package manager, essentially only supporting the "latest" version for each package, which doesn't work well with the usual "only install packages older than X" concept.

It's all rolling release, but Homebrew maintainers have to bump the version, not the software author (unless they put in a PR to Homebrew core or publish their own Tap). What does Arch do here?

That’s not quite true. A recipe can specify a URL to check for a new version, and the homebrew automation will periodically check it. If there’s a new version, it automates the version bump.

I used that for a package my company publishes, and neither we nor any other human AFAIK ever manually update it in homebrew, yet the newest version is always installable there.

100% need this.

Reply on news.ycombinator.com