Agreed we should deprecate in next major or minor release.

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.

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.

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.

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.

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.

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.

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.

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.

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.

💯

GitHub has confirmed the removal of this flag will not impact Actions runners, so we are clear to move forward in the next minor release.

I am running into an issue with some casks that are being targetted for removal such as wine@devel where one needs to use --no-quarantine to make it work but any sort of upgrade breaks them. I am also aware that some casks require --no-quarantine but are not yet targetted for depreciation. Removing --no-quarantine is going to break quite a lot of stuff.

I am running into an issue with some casks that are being targetted for removal such as wine@devel where one needs to use --no-quarantine to make it work but any sort of upgrade breaks them.

There are other ways to bypass Gatekeeper if you must. It's on you to figure those out.

I am also aware that some casks require --no-quarantine but are not yet targetted for depreciation.

Such as?

Are you joking? Why would anyone need homebrew at all after this? You know, there is AppStore for installing "safe" software on Macs.

Are you joking? Why would anyone need homebrew at all after this? You know, there is AppStore for installing "safe" software on Macs.

It seems that you don't understand what this flag does, or what it will affect. As I stated above, you can still bypass Gatekeeper if you want, we just won't me the ones making it easy anymore.

Are you joking? Why would anyone need homebrew at all after this? You know, there is AppStore for installing "safe" software on Macs.

It seems that you don't understand what this flag does, or what it will affect. As I stated above, you can still bypass Gatekeeper if you want, we just won't me the ones making it easy anymore.

It does setxattr(). I can do it myself. I can compile the whole distro myself patching it for the platform I need, including messing around with some drivers. By messing around I mean taking gdb and logic analyzer and digging into why this exact chip does weird things. Not all of them, but I'm quite aware of how this piece of silicon under my keyboard works.

The point of having alternative package manager is letting me NOT DO it myself, while installing things I need, which might or might not be properly signed from Apple's viewpoint. I have it because I trust and value YOUR decisions on curating repository more than Apple's useless Gatekeeper.

I'm also quite aware of distant implications of this and similar decisions. This won't protect your users from anything, it will decrease their security, because stuff they will install anyways won't be updated automatically (or at least there will be no easy way to do it).

I also can imagine why you're going this way.
So no, I'm quite aware of how this works. You don't. Or do not want to.

I have it because I trust and value YOUR decisions

Good. Then you'll trust and value this decision.

Your GitHub profile is blank. This tells me you have never worked on any open source software on GitHub. I have worked on Homebrew for 16 years. I know more about running a package manager than you ever will. Us supporting a security-degrading feature like this does reduce overall ecosystem security. Yes, you can do it yourself manually. That it becomes harder means fewer people are will do so. Homebrew has enough users that if even 1% change behaviour based on this it has a huge impact.

Re-read our code of conduct, adjust (or just stop) your communication in future or you will be blocked from Homebrew.

Note that an unwanted side effect might be, that people will revert to an obvious simple solution/app/script, that will automatically remove the quarantine attribute for ALL new Apps placed in /Applications. (Or even worse, disable Gatekeeper entirely.)

That would create an even unsafer situation, as then not just Homebrew are de-quarantined, but all Apps placed in /Applications would be affected...

@notDavid I don't see any evidence for that speculation.

Locking this thread. Not interested in arguing the merits of this. It's already been communicated to third parties.