Homebrew 6.0 puts third-party tap trust on the install path
The macOS package manager's headline feature reframes a long standing supply chain question: who actually controls the source you are pulling from, and when do you find out?
The macOS package manager's headline feature reframes a long standing supply chain question: who actually controls the source you are pulling from, and when do you find out?
For most of Homebrew's history, adding a third-party tap and running the Ruby code inside it was a single step. With 6.0.0, released on June 11, 2026, the project has split that step in two. The new feature, called tap trust, is the most consequential change in this release, and it reframes a question that has been latent in package management for years. Who actually controls the source you are pulling from, and when do you find out?
Taps are Homebrew's term for Git repositories that publish formulae and casks outside Homebrew's own core set. Some are large and well known, like community-maintained font or driver collections. Others are small projects maintained by a single developer. Until now, adding a tap meant Homebrew would quietly run its Ruby code on the user's machine. Tap trust makes that step visible. Per the release announcement, "non-official taps and tap-qualified formulae and casks need to be explicitly trusted before they are used." The transition escape hatch is the environment variable HOMEBREW_NO_REQUIRE_TAP_TRUST=1, which preserves the old behavior. The project plans to remove it.
The trust model is documented on the Tap-Trust page at docs.brew.sh. The mechanism has two halves. A user runs brew tap --trust <tap> to declare which maintainers they trust, and that declaration is signed and stored alongside the tap. Homebrew checks the signature before evaluating the tap's Ruby. Official Homebrew taps are trusted by default, which is what keeps brew install wget from prompting on every macOS developer machine. The point of the feature is not to make every tap safe. It is to make the question of who is on the other end of a brew tap answerable, and to do it at install time rather than after a compromise.
This is a supply-chain story, but a modest one. Tap trust does not verify that a tap's formulae are safe, that their bottles (prebuilt binaries) come from a trusted build environment, or that the upstream project itself is well run. It also does not solve the dependency on GitHub hosting. A tap whose GitHub account is compromised could still push code that the trust signature was already applied to. The release notes are candid about this. The feature is a visibility and consent layer, not a guarantee. Its effectiveness will depend on how many maintainers document their own signing keys, and how many users make trust a real decision rather than a habitual yes.
The release ships other changes worth knowing about. Linux Homebrew now sandboxes build, test, and postinstall phases by default using Bubblewrap, which the release notes describe as aligning Linux's sandbox model with the macOS one. brew leaves runs about 30 percent faster, bottle downloads on brew upgrade happen in parallel, and brew bundle installs formulae in parallel by default. Three published security advisories are listed in the Homebrew 6.0.0 release as fixed in this release: a POST download strategy HTTPS-to-HTTP redirect bypass (GHSA-7699-qf8c-q47m), root code execution through git hooks in macOS .pkg postinstall (GHSA-6689-q779-c33m), and a /var/tmp plist ownership-hijack in the macOS installer (GHSA-59v8-x8q4-px5c). The full list of merged pull requests since 5.1.15 lives on the Homebrew 6.0.0 release page on GitHub.
Two forward-looking items are worth flagging. The release adds initial support for macOS 27, which Homebrew refers to by the codename "Golden Gate." Per the project's Support Tiers, macOS Intel x86_64 will move to Tier 3 in September 2026, meaning no CI and no new bottles, and will be unsupported entirely in September 2027. The codename and the September 2026 and September 2027 dates are Homebrew's stated plan, not a confirmed Apple release schedule. Developers maintaining CI for Intel macOS runners now have a roughly fifteen-month runway to migrate to Apple silicon. LWN's brief release notice carries the same dates and points to longer coverage from November 2025 for anyone who wants the historical context.
For maintainers of third-party taps, the practical question is mechanical. Publish a signing key. Document which key signs your releases. Add a trusted: entry to your Brewfile so users running brew bundle can opt in declaratively. The release notes note that Brewfiles now honor the trusted: option, and a new --describe flag on brew bundle add records a human description alongside the dependency. Both lower the cost of doing this correctly. For users, the practical question is less mechanical. Tap trust works only if the people you trust are the people you think they are, and only if the answer to that question is something a casual installer can find without spelunking through Git commit histories. The release is a step in that direction. Whether the rest of the ecosystem follows depends on how aggressively the maintainers of the larger non-official taps document and sign their work in the months ahead.