Live data from Hacker News

Show HN: Homebrew 6.0.0

brew.sh

31–40 of 380 posts

Re: Show HN: Homebrew 6.0.0

#32
post #18

I have switched my full OS-level dev env to https://mise.jdx.dev/ from Homebrew+pipx+npm, initially as an experiment but found out that it actually works amazingly well. Many things get installed directly from GitHub releases or a corresponding package manager (uv, pnpm, go get ...), zero glue code to "repackage", zero version lag. You can install any arbitrary version of a package, even multiple ones at once, and dy…

Don't forget that mise depends on package registries, to install itself as well as its tools.

Mise installs itself as a static binary actually (but it's of course packaged in many registries), and while there are some third party registries it delegates to for some packages (aqua, asfd), most stuff I have installed is either built-in, or from PyPI, npm or GitHub, i.e. directly published by the upstream maintainers. More info: https://mise.jdx.dev/dev-tools/backends/

Re: Show HN: Homebrew 6.0.0

#33

Earlier quoted context omitted.

You need to set HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKS to 1, as alluded to by a hint when it (first?) occurs. This means if you have hints off (via HOMEBREW_NO_ENV_HINTS) then I suspect you can start getting this behavior without warning which is a bummer. See also: https://docs.brew.sh/FAQ#why-arent-some-apps-included-during...

This means if you have hints off (via HOMEBREW_NO_ENV_HINTS) then I suspect you can start getting this behavior without warning 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.

Ah, I suppose I did word that poorly—I more mean that a significant breaking change (Casks that previously were documented as being excluded from auto-updating suddenly being auto-updated) which can occur silently is a rough end-user experience, even if the user explicitly opted into hiding hints.

Re: Show HN: Homebrew 6.0.0

#34
Thanks for producing such an amazing piece of software. Most of my Mac installations are based on Homebrew, but I have to rely on version management tools like Pyenv or nvm for Python and Node. Wish there was some standard 'Homebrew' way to install multiple versions of node, php and Python

Re: Show HN: Homebrew 6.0.0

#35
post #18

Earlier quoted context omitted.

Don't forget that mise depends on package registries, to install itself as well as its tools.

Mise installs itself as a static binary actually (but it's of course packaged in many registries), and while there are some third party registries it delegates to for some packages (aqua, asfd), most stuff I have installed is either built-in, or from PyPI, npm or GitHub, i.e. directly published by the upstream maintainers. More info: https://mise.jdx.dev/dev-tools/backends/

You'll see that mise recommends installing itself exclusively through package registries: https://mise.jdx.dev/installing-mise.html

pypi, npm, and even github (through releases) are registries.

curl | sh is an anti-pattern. It passes no security check.

Re: Show HN: Homebrew 6.0.0

#39
post #7

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 0…

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

Re: Show HN: Homebrew 6.0.0

#40
post #7

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 0…

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.

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.

Post reply on HN