How Workbrew handles Homebrew Tap trust

Starting with Homebrew 6, Homebrew no longer loads formulae, casks, or commands from a third-party Tap unless that Tap is trusted. (Individual formulae and casks can also be permitted one at a time, by trusting them directly or referring to them by their fully-qualified owner/tap/name, but trusting the whole Tap is what keeps everyday use working.) A Device user who has tapped a third-party Tap directly may see a warning like this:

Warning: The following taps are not trusted:

  acme/tap

Homebrew is currently ignoring formulae, casks and commands from these taps
because tap trust is required.

This page explains what Tap trust is, why Homebrew added it, and how Workbrew handles it for you so that, in most cases, no one has to run brew trust by hand.

What Tap trust is#

A Tap is a source of Homebrew packages. The two official Taps, homebrew/core (formulae) and homebrew/cask (casks), follow strict review guidelines and are always trusted. Anything else is a third-party Tap.

Tap trust is a security control: before Homebrew runs code from a third-party Tap, that Tap must be explicitly marked as trusted on the machine. Trust is recorded per Device, so trusting a Tap on one Device does not trust it on another. The point is to make sure that running code from outside the official Taps is a deliberate, authorized decision rather than something that happens silently.

Trust is separate from whether a Tap is allowed. Allowing a Tap (with an Allowed Taps policy) controls whether installs from it are permitted at all. Trust controls whether Homebrew will load it once it is present. They are different gates, and the Allowed Taps policy is convenient because it satisfies both at once.

Why running code from a Tap is a deliberate decision#

A formula or cask is not just a download link. It is a Ruby file that runs on the machine during installation, with whatever access the install has. The official Taps are reviewed with that in mind. A third-party Tap is maintained by whoever owns it, on whatever terms they choose, and can change at any time.

Tap trust exists so that this risk is acknowledged once, by someone who is in a position to make that call, rather than being accepted implicitly every time a Device user taps something new. In a fleet, that someone is the administrator, not each individual Device user, which is exactly where Workbrew fits in.

How Workbrew trusts Taps for you#

Workbrew treats a Tap as authorized to be trusted on a Device when the Tap reaches that Device through Workbrew. The Workbrew Agent then trusts it automatically, so Device users do not see the warning and do not need to run brew trust themselves. This works even when your Device users are Standard users without administrator rights, because the Agent applies the trust, not the person at the keyboard.

A Tap is trusted automatically when it comes from any of these:

• A private Tap you provision in Workbrew. Private Taps connected through your GitHub or GitLab integration are trusted across your whole fleet. See Sync and authenticate private Taps with Workbrew.
• An Allowed Taps policy. Any third-party Tap you add to an Allowed Taps policy is trusted on the Devices the policy targets, in addition to being allowed to install. This is the most direct way to centrally manage a set of third-party Taps.
• A Default Packages Brewfile. A Tap declared with a tap "owner/repo" line in your Default Packages is trusted on the Devices that Brewfile targets when it is applied.
• A brew tap Brew Command. A Tap you add by running a brew tap Brew Command is trusted on the Devices that command targets.

New Devices are covered automatically. Because trust follows from your Workbrew configuration rather than from a one-time action on each machine, a Device that joins later picks up the trusted Taps when it checks in, with nothing extra to run.

You do not need to disable Tap trust to make this work. Homebrew offers an environment variable to turn the check off, but it is deprecated and scheduled for removal, so relying on it is not recommended. Letting Workbrew trust the Taps you actually use is the durable approach.

What a Device user sees#

When a Tap is trusted through Workbrew, the Device user sees nothing unusual: installs from that Tap just work. The "not trusted" warning only appears for Taps that arrived on the machine outside Workbrew, for example a Tap a Device user added by hand that has not been brought under management. The fix is not to trust it on that one machine, but to bring the Tap under Workbrew using one of the routes above, so it is trusted everywhere it is needed.

Related docs#

• Allow installation of packages from third party Taps — add an Allowed Taps policy, which also trusts those Taps
• Include third-party Tap formulae in Default Packages — declare Taps and their packages so they are trusted on apply
• Sync and authenticate private Taps with Workbrew — provision private Taps that are trusted fleet-wide
• Private Taps — structure, sync behavior, and constraints for private Taps
• How Workbrew uses elevated privileges — how the Agent applies changes without Device user intervention