I don't understand what this means, although I've read the whole thread. Does this mean people won't be able to use Homebrew to compile software from source (and run it)? Does it mean that they'll be able to use Homebrew to compile software from source, but not download prebuilt binaries (and run them)? Does it mean that they'll be able to download prebuilt binaries, but only run them if they're built by a developer that Apple has blessed?

I do understand that the effect is only to make Intel Macs adopt the same behavior ARM64 Macs already had, but I don't understand what that behavior is.

I see that someone named andrewmcwatters has posted a [dead] reply to my comment that doesn't answer my questions, just repeating the same jargon from the bug report that I don't know the meaning of.

> Does this mean people won't be able to use Homebrew to compile software from source (and run it)? Does it mean that they'll be able to use Homebrew to compile software from source, but not download prebuilt binaries (and run them)?

No, and no. This only affects Casks, which are prebuilt .app bundles that Homebrew has no part in building (either locally or remotely). Formulae (source builds) and bottles (builds of formulae within Homebrew) are not directly affected by any of this.

This is my understanding after a moderate dive into the issue.

Binaries in macOS have a signature and a set of flags. One of those flags is the "quarantine" flag that, when set, refuses to run your binary until some extra security checks have been performed (checking against a malware database, asking the user for consent, etc). Once this check is done, the flag is unset.

Usually this flag has to be set by the app you use to download the binary - in most cases it would be the web browser, but here it would be Homebrew. They used to provide a --no-quarantine flag to prevent this bit from being set, but given some changes both in macOS and in the Homebrew project it's been decided to stop offering that option. You can still unset the flag by hand, no root required, but that's on you as a user.

I believe this is a strong nudge in the direction of "for a user-friendly experience you should sign your binaries", but not a full ban.

I don't know either (right now). They closed the discussion, so they don't want people to talk about it.

Perhaps someone with more information will chime in, who isn't a homebrew maintainer.

There'll be some way to make it work, possibly indeed that the Homebrew people get approved by Apple, because MacPorts works ok, and it seems to be downloading precompiled binaries (and if it isn't, then my Mac is actually faster than I've ever seen it run). And if MacPorts can do it, presumably Homebrew can do it too.

Building stuff yourself remains an option, even if you're unapproved. The toolchain pops the codesign step in at some point, I guess, and if you built it locally then you can run it locally. I just did cc -o on some bit of code on an Apple Silicon Mac, and the resulting binary did run.

(You can also run binaries that unapproved people built on other systems, but it's a minor pain, as you have to explicitly opt in to allowing each runnable file to run.)

Like you won’t be able to install clickhouse from homebrew for as long as clickhouse produce unsigned binaries.

It’s the only one affected that I currently use.

All it means is that applications downloaded/installed via Homebrew will no longer be able to bypass the Gatekeeper signing/notarization requirement on Intel platforms (already is the case on Arm).

If you didn't need to install a cask with this flag before you won't be impacted by the deprecation.

Casks won’t be able to bypass Gatekeeper, so now you can’t launch .apps from brew that aren’t notarized.

So, you might as well just use the App Store.