What Homebrew 5.0.0 means for your Mac fleet

The highlights

There’s a lot of changes in Homebrew 5.0.0, but there are a couple that are really important for administrators of Mac fleets. This major upgrade puts the spotlight on the security of Casks, Homebrew’s solution to deploy GUI apps. Casks are helpful for distributing and updating common app bundles like Slack or the Chrome browser, but present their own unique security and compliance challenges. These changes provide more security by default to Homebrew-using fleets and are good news for administrators.

Firstly, Casks without codesigning and notarization are now deprecated, and will be removed from the official tap, meaning they will no longer be installable through brew install, by September 2026. This means that Casks distributed via Homebrew must meet the same security requirements as Mac software distributed outside the App Store. Developers of apps who wish to distribute them via Homebrew Casks must now ensure their apps are signed and notarized.

Secondly, the --no-quarantine and --quarantine flags are being deprecated. The --no-quarantine flag was commonly used to circumvent macOS security requirements for applications, such as the familiar dialog warning stating that an app “cannot be opened because it is from an unidentified developer”. Whilst it is still possible for an end-user to bypass these requirements and run unsigned software, Homebrew no longer facilitates these actions, and aligns with Apple’s approach to application security.

Keep reading to learn more about each of these in detail, as well as updates to Homebrew’s supported devices and operating system versions, changes to acceptable content policy in official Homebrew repositories, and finally, a new environment variable to help control Cask installations.

Much ado about codesigning

The big ticket items with Homebrew 5.0.0 both relate to codesigning and notarization requirements on macOS.

In a nutshell, codesigning is performed by the developer of an application using their Apple Developer ID certificate, and provides two guarantees:

• The application has been signed by the identified individual
• The application has not been modified since it was signed

These are important guarantees in supply chain security that let you know that the application source code was developed by the expected party, and that no one else has tampered with it along the distribution chain.

Notarization is an additional process where the source code for an application is uploaded to Apple to check for known malware via an automated scan. Apps found to be safe are provided a ticket which informs macOS that the application has been notarized. In the event that an application is later found to contain malware, Apple can revoke tickets to block the launch of malicious applications or opening of malicious files.

Both codesigning and notarization have existed a long time, but Apple has been progressively tightening the constraints, making it so more applications must follow these processes, and that device-users have fewer easy workarounds. As of macOS 15 (Sequoia), the easiest way for users to bypass macOS’s security warning about unsigned applications through Control-clicking the application in Finder has been removed. The Eclectic Light Company has a great breakdown of the history of codesigning on Macs and the different forms and implications.

Codesigning in the Homebrew ecosystem

Homebrew’s audit process for Casks now checks that Casks have been codesigned and notarized, and Casks that fail this audit will be removed by September 2026, giving developers in the Homebrew ecosystem plenty of time to adopt codesigning. This change effectively aligns Homebrew with Apple’s stance on application security: device-users will no longer be able to receive applications without signing guarantees or Apple’s automated malware checks via the official Homebrew taps, which should give administrators some peace of mind. Device-users may also benefit from an improved user experience, as all applications they install via Casks should work without having to jump through any MacOS security hoops.

The removal of the --no-quarantine flag is a further indication of Homebrew’s commitment to Apple’s application security model. This flag overwrote macOS’s security checks for applications, enabling Device-users to run unsigned applications. As Apple enhances their codesigning requirements and removes easy workarounds from the OS, Homebrew also “does not wish to easily provide circumvention to macOS security features”. In the past, developers of unsigned Casks may have included the --no-quarantine flag in their install instructions, which could cause device-users to install software without understanding the security implications, if they’re not familiar with macOS codesigning or Homebrew’s flags. As with the deprecation of unsigned Casks as a whole, administrators should find this change rounds another potentially sharp edge off of Homebrew usage within their fleets.

Hello Tahoe, goodbye Intel

It’s been five years since the release of the first Apple Silicon Macs, and support for Intel Macs is coming to an end. The latest macOS 26 (Tahoe) is the last version of macOS to support Intel, and security updates for supported macOS versions will end in late 2028. Homebrew is following this timeline as well, with Intel Macs dropping to Tier 3 support in September 2026, and Homebrew ceasing to work at all in September 2027. Whilst it’s easy to assume Homebrew is merely walking in step with Apple, these timelines are influenced by how Homebrew works, and how it keeps the ecosystem safe and functioning. Homebrew relies on Continuous Integration (CI) to run its automated checks on packages, and as support for Intel Macs fades, the project will lose access to CI runners that can test packages for Intel Macs and older macOS versions. As with the codesigning changes above, following Apple’s schedule helps keep the Homebrew ecosystem secure. You can learn what is and isn’t supported by Homebrew in their documentation about Support Tiers.

Adult content

Homebrew has updated their policy on packages containing adult content, in essence deciding that it is allowed. However, URLs and documentation pages must be “safe for work”, meaning no one is exposed to adult content merely through Homebrew interfaces, before installing and using any packages. It’s important to mention that this isn’t a change in policy per se, but is instead an explicit clarification of Homebrew’s stance, and administrators shouldn’t expect anything to change. Homebrew also note that they reserve the right to apply ad hoc exceptions based on how packages behave and how they affect the wider Homebrew ecosystem, so if a piece of adult content on Homebrew gets out of hand, it can be removed.

More controls for Cask installations

Homebrew 5.0.0 adds a new environment variable, HOMEBREW_FORBIDDEN_CASK_ARTIFACTS, that allows blocking of Cask install methods. Lots of different types of software can be installed via Cask, for example, did you know fonts can be installed via a Cask? The new environment variable accepts a list of artifact types and will prevent Casks of that type being installed. So administrators who really don’t want device-users installing new screensavers or keyboard layouts via Casks can now lock that down. The available options can be viewed in the Homebrew environment documentation.

Workbrew Pro workspaces can already use this new environment variable across their fleets with Workbrew’s Brew Configurations, which allows setting of the hundreds of Homebrew environment variables by device group. You can learn more about Brew Configurations in How Workbrew works.