Homebrew 6.0.0 Puts Trust Checks In Front Of Third-Party Taps

Why it matters

Homebrew sits in the default setup path for many developers. By forcing explicit trust for third-party taps, 6.0.0 turns supply-chain risk from an invisible assumption into a user decision.

Mike McQuaid released Homebrew 6.0.0 on June 11, putting a new trust gate in front of third-party taps that can run arbitrary Ruby on a user's machine, according to the project's release post.

That is the real center of this release. Homebrew, the package manager that sits in the critical path of many Mac and Linux developer machines, is not positioning 6.0.0 around a new interface or a broader platform play. The project is changing what it will run by default, after years in which third-party taps gave developers a flexible way to distribute software and gave attackers an obvious place to look for leverage.

McQuaid's post says third-party taps can contain "arbitrary, unsandboxed Ruby". In Homebrew 6.0.0, taps, tap-qualified formulae and casks must be explicitly trusted before their code is evaluated or run. Official Homebrew taps remain trusted by default. The project has also published Tap-Trust documentation explaining the model.

Homebrew is not a conventional startup, and the provided sources do not establish a founder backstory. It is a governed open-source project with public documentation for users, contributors and maintainers, including pages covering support tiers, software supply-chain security, governance, maintainer guidelines, expenses, stipends and grants. That governance context matters here: Homebrew 6.0.0 is a maintainer-led decision to absorb friction in exchange for a narrower attack surface.

The trust change is a supply-chain call

The tap trust mechanism touches several parts of Homebrew's workflow. The release post says Homebrew now flags untrusted taps before their code runs, stops auto-tapping untrusted taps, uses tap trust when evaluating formulae and casks, and adds commands for managing trust through brew tap. brew trust also gets a --json=v1 flag, and brew tap-info now reports a trusted field.

For developers, the practical effect is that some previously smooth third-party install paths will ask for an explicit trust decision. For maintainers, it gives Homebrew a policy layer around external code without banning the tap ecosystem that made Homebrew useful beyond the official repositories.

That balance is the point. Homebrew's taps have always been one of its strengths: they let projects distribute formulae outside Homebrew's core process. But the same mechanism means Homebrew is not just downloading packages; it can be evaluating repository-provided Ruby. The 6.0.0 release makes that risk visible at the moment a user is about to cross it.

Homebrew also changes its update path

Security is not the only systems-level change. Homebrew 6.0.0 makes the internal JSON API the default, after offering it as an opt-in through HOMEBREW_USE_INTERNAL_API since Homebrew 5.0.0. The release post says the API combines Homebrew metadata into a single download, which should make brew updates faster and reduce network calls. The old environment variable is now deprecated.

The release also adds a Linux Bubblewrap sandbox, aligning Linux with macOS, where Homebrew says build, test and postinstall phases already run sandboxed. According to the release post, the Linux sandbox is on by default for developers.

Homebrew says it also improved performance, including less Ruby library loading at startup, parallelized bottle tab fetching during upgrades, and an approximately 30% faster brew leaves. That last figure is a project-supplied benchmark from the release post; Homebrew does not disclose the benchmark setup in the provided source.

Bundle is becoming a setup layer

The other strategic thread is brew bundle, which continues to push Homebrew from package manager toward developer-environment orchestrator.

Homebrew 6.0.0 makes parallel formula installation run jobs automatically by default, and adds npm and krew extensions, broader cleanup support, and Windows winget support. The release post also says cleanup support now extends across npm, cargo, go and uv extensions.

That does not make Homebrew a rival to those ecosystems. It makes Homebrew a coordination point for machines that increasingly need packages, language tooling, Kubernetes plugins and app installs to be reproducible from one file. brew bundle is where that operational convenience shows up.

The release also changes defaults after a Homebrew user survey. The most notable change, according to McQuaid's post, is that ask mode is now the default for developers, so brew install and brew upgrade show a dependency summary and confirmation prompt before making changes. The source does not disclose a respondent count in the material provided.

Apple Silicon is the long transition underneath it

Homebrew 6.0.0 includes initial support for macOS 27, code-named Golden Gate. The release also points to the next stage of Apple's Intel wind-down: according to Homebrew's support-tier documentation, macOS Intel x86_64 moves to Tier 3 in September 2026, with no CI support and no new bottles built for macOS Intel, and becomes unsupported in September 2027.

For Homebrew maintainers, that schedule is not just platform bookkeeping. It determines which machines get tested, which bottles get built, and how much compatibility code remains worth carrying. For developers still managing Intel Mac fleets, Homebrew is putting a date on the maintenance cliff.

Homebrew 6.0.0 is therefore less about a single headline feature than about maintainers tightening defaults across the system: trust external code explicitly, fetch metadata more efficiently, sandbox more Linux work, ask before dependency changes, and start moving the ecosystem beyond Intel Macs. Each change adds a small amount of policy to a tool developers often treat as plumbing. That is exactly why the release matters.