Your CI runner is a stranger with a credit card and root. Every brew install against a third-party tap is the same trust gesture as curl | sh, just wearing a nicer shirt. (We have all written that step in a script and clicked merge.) This week Homebrew said the quiet part out loud and asked you to consent to it first.

The 6.0.0 release shipped the week before DevOps.com's writeup with a tap-trust gate. Out of the box, only taps on a pre-approved list will install. Anything else gets a refusal until a human runs brew trust user/repo. Trust binds to the remote's fully-qualified URL, so the same tap mirrored to a different host is a fresh decision, not a transitive one.

What the gate actually refuses

Before 6.0.0, the package manager treated user/repo as a name and walked off to fetch the formula. After 6.0.0, an unrecognised remote URL is a refusal at resolve time. Project Leader Mike McQuaid framed it in the 6.0.0 introductory post:

The Homebrew team is aware of the supply-side security issues with other package managers. We've taken various steps to mitigate these risks for our users.

(He has a point. The last few years of supply-chain incidents were not theoretical.) Tap-trust is one of those steps. It does not inspect the contents of a tap, scan a formula, or pin a SHA. What it does is force a human, or a script, to make an explicit, auditable statement: this remote URL is one we accept.

Where your pipeline will feel it

DevOps.com flags the part that matters for this site's audience: CI/CD pipelines using Homebrew will need to add brew trust commands to their setup scripts. Quietly bump the Homebrew action on your runner image and the next build that touches a non-core tap will fail at the install step, well before any test runs. That is a feature, but only if you read the changelog.

The migration itself is a one-liner per tap. The cost is owning a list. Every tap your pipeline depends on now has to be enumerated somewhere, reviewed when it changes, and version-controlled with the rest of your supply-chain policy. The good news is this is a list you already had in your head and never wrote down. The bad news is the same.

The other half of 6.0.0

Two adjacent changes deserve a paragraph each. On Linux, Homebrew 6.0.0 integrates Bubblewrap to sandbox application builds, tests and post-install phases. Tap-trust says no to an unknown publisher; Bubblewrap constrains what the formula gets to do once it is past the gate. Both layers, or one without the other, is the question your threat model has to answer.

For auditors there is also a Boolean trusted field added to state management. Translation: the consent decision becomes a queryable fact, not a guess. If your compliance story includes a line about installing only approved third-party software, there is finally a field to point at.

The npm parallel, and why it matters

Homebrew is not alone here. According to the same article, GitHub re-engineered npm using a similar approach, blocking installation scripts that do not already have user approval, with the update expected to land in npm v12 next month. Two of the most casually-invoked package managers in CI are converging on the same default: untrusted by construction, trusted by an explicit act.

That convergence is the point. For years, "supply chain" hardening meant SBOMs and signatures aimed at the artifact. Tap-trust and npm's install-script gate aim at the invocation. They do not replace provenance. They cut off the easy path where a workflow file picks up something nobody on your team had ever heard of.

Verdict

A trust list is not a security architecture. It is a forcing function: it makes you write down what you were already implicitly agreeing to, and it breaks the build the day someone slips a new tap into a Brewfile without telling you. That is unglamorous work. It is also the work most pipelines have been skipping for a decade.

Pin your taps. Then worry about the dependencies inside them.