Removing support for `--no-quarantine`

[p-linnane]

Verification

• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

--no-quarantine is used to forcibly bypass Gatekeeper, which is a built-in macOS security mechanism. This is used to run unsigned/unnotarized applications.

macOS Tahoe is the final release to support Intel systems, and last year Apple updated macOS runtime protection to make it harder to override Gatekeeper. Macs with Apple silicon also don't "permit native arm64 code to execute unless a valid signature is attached". Finally, we are ending support for all casks that fail Gatekeeper checks on September 1st, 2026.

With the above in mind, it's time to deprecate the --no-quarantine flag from brew. It intentionally bypasses macOS security mechanisms, which we already actively discourage. Deprecating now will give a decent lead time for users using it to come up with another solution or adjust their workflows.

What is the motivation for the feature?

Intel support is coming to an end from both Apple and Homebrew. This flag is primarily used to override a macOS security mechanism, which we do not want to encourage. Since we are requiring casks fulfill Gatekeeper checks next year, there is no reason to keep this flag.

How will the feature be relevant to at least 90% of Homebrew users?

We will provide a safer experience for our users, and stop making it easier to bypass OS-level security.

What alternatives to the feature have been considered?

None. Macs with Apple silicon are the platform that will be supported in the future, and Apple is making it harder to bypass Gatekeeper as is.

[MikeMcQuaid]

Agreed we should deprecate in next major or minor release.

[carlocab]

This is still set in GitHub Actions: https://github.com/actions/runner-images/blob/21bf85db205313d8e8e584276714f82f8de1740b/images/macos/assets/bashrc#L30

We may want to coordinate with them about this deprecation/removal.

[MikeMcQuaid]

This is still set in GitHub Actions: actions/runner-images@21bf85d/images/macos/assets/bashrc#L30

We should probably just set it unconditionally ourselves in GitHub Actions, even after this, if it keeps things working or fix the underlying problems here.

[xtqqczze]

I think we should keep --no-quarantine to support third-party taps. Otherwise, if the option is removed entirely, tap maintainers may resort to running xattr -d com.apple.quarantine /Applications/App.app in a post-install script, which would be worse for overall ecosystem security.

I think the best approach would be to deprecate support for --no-quarantine from the environment variable HOMEBREW_CASK_OPTS. This way, we discourage unsafe usage while still allowing controlled opt-in via the CLI.

[p-linnane]

I think we should keep --no-quarantine to support third-party taps. Otherwise, if the option is removed entirely, tap maintainers may resort to running xattr -d com.apple.quarantine /Applications/App.app in a post-install script, which would be worse for overall ecosystem security.

Keeping a flag that we no longer officially support, in order to allow third-party taps to bypass OS-level security, doesn't feel like a good idea.

[MikeMcQuaid]

I think we should keep --no-quarantine to support third-party taps. Otherwise, if the option is removed entirely, tap maintainers may resort to running xattr -d com.apple.quarantine /Applications/App.app in a post-install script, which would be worse for overall ecosystem security.

This is essentially doing the same thing in both cases, it's just that --no-quarantine looks like Homebrew officially supports (even recommends) it.

[xtqqczze]

Keeping a flag that we no longer officially support, in order to allow third-party taps to bypass OS-level security, doesn't feel like a good idea.

I’m not sure what the intended security model is here. The proposal would have Homebrew be more restrictive than macOS itself. No sudo privileges are required to run:

xattr -d com.apple.quarantine /Applications/App.app

Removing --no-quarantine doesn’t actually prevent this, it just moves the action into scripts, which may be less transparent and harder to audit.

[MikeMcQuaid]

I’m not sure what the intended security model is here.

We don't want to provide built-in support for bypassing quarantine. --no-quarantine is easier and better documented than manually running xattr -d com.apple.quarantine.

Removing --no-quarantine doesn’t actually prevent this

Leaving it in doesn't prevent it either?

which may be less transparent and harder to audit

Or may be more transparent and easier to audit!

---

Respectfully @xtqqczze: you've made your opinion clear. We don't really need any more contributions to this issue. If others want to chime in, particularly maintainers and regular contributors, their input is valued.

[gromgit]

I see it as a matter of perceived accountability. Whoever provides a user-friendly way to disable security mechanisms (--no-quarantine or xattr in postinstall blocks) will be yelled at by said users when:

• Apple changes/locks in the quarantine mechanism, thus breaking the current code, or
• a supply-chain attack occurs with an unsigned upstream

This will be true even if it's the user who added --no-quarantine to HOMEBREW_CASK_OPTS (I've already seen more than a few in posted brew config outputs). Rationality doesn't apply here; the user's angry that their system's b0rked by Homebrew-installed software, and is looking for someone to blame, even though they were the ones to silence Gatekeeper.

Third-party tap owners who add xattr to their cask files will correctly be blamed, of course, since they made that choice on behalf of all their users. On that note, I wouldn't mind an "xattr quarantine" audit that's a warning for third-party taps but fatal in core, just to remind tap owners about the implications of their actions.

In the end, the whole point of Gatekeeper is to protect end users as much as reasonable, and continuing to make it easy to bypass isn't a good thing in my view.

[MikeMcQuaid]

Third-party tap owners who add xattr to their cask files will correctly be blamed, of course, since they made that choice on behalf of all their users. On that note, I wouldn't mind an "xattr quarantine" audit that's a warning for third-party taps but fatal in core, just to remind tap owners about the implications of their actions.

Agreed. This is a good idea.

In the end, the whole point of Gatekeeper is to protect end users as much as reasonable, and continuing to make it easy to bypass isn't a good thing in my view.

💯