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.
The answer to this is nuanced because of how it works, but the short answer is yes: you can build random things from source and run them, and you can download random binaries from the internet and run them. The only thing that Homebrew itself is changing is that it no longer provides an automatic way to lift the quarantine bit from a specific subset of binary packages (casks).
For Mac, yes and no. IIRC you don't need a developer's license to build and sign software for yourself. But you do need one to distribute pre-built software.
You can still run unsigned software, but you need to approve 2? prompts, and also allow exception for every executable by going to Privacy & Security tab in settings.
IIRC there is a CLI command for achieving the same.
You can’t run unsigned software on Apple silicon. Note that when you build your software if you use Apple’s tools it will inject an ad-hoc signature into the product.
You very much _can_ run unsigned software on Apple silicon. At work my department has a bit less than 50 engineers with Macs (M1 to M4) and nobody complained that they can't build and run our product (using GCC from Homebrew, not Clang from Apple). But it involves some jumping through hoops, yes.
As mentioned above you have to approve the binary two times (at least), being careful the first time because the dialog popup offers to remove the binary. Also since our product has some networking to do one has to mingle with firewall settings to allow the binary to do the networking.
To check I did this: removed the signature (LC_CODE_SIGNATURE section) using lief Python package (no affiliation, just looked suitable for the task), checked by otool that the section is indeed gone, started the binary - it worked. The spctl said that the binary is "rejected", but it says so about every non-Apple binary I checked on my machine so not informative. The codesign tool shows "is not signed at all" on the binary with stripped signature.
I'm not too well-versed in OSX system/dev tools, so if there is a more correct/precise method of checking the signatures I'd very much like to know.
Nope, 15.7.2. Maybe there are some settings, unknown to me, that are configured by MDM and that allow for such behaviour - our Macbooks are managed by the employer and are intended for development, so would be logical to set them up this way.
_A Mac with Apple silicon doesn’t permit native arm64 code to execute unless a valid signature is attached. This signature can be as simple as an ad hoc code signature (cf. codesign(1)) that doesn’t bear any actual identity from the secret half of an asymmetric key pair (it’s simply an unauthenticated measurement of the binary)._
_For binary compatibility, translated x86_64 code is permitted to execute through Rosetta with no signature information at all. No specific identity is conveyed to this code through the device-specific Secure Enclave signing procedure, and it executes with precisely the same limitations as native unsigned code executing on an Intel-based Mac._
The signature that gets added is vaguely a hash of the binary. You probably want to look at the UUID that gets injected into your binary instead 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.
When they closed the discussion, they explicitly welcomed people to talk about it outside their issue tracker:
> Our issue trackers (other projects may differ) are used to track the work for maintainers or soliciting community contributions. They do not exist for people to debate the merits of decisions already made. We have Homebrew/discussions (and, well, the rest of the internet) for that.
They just don't want discussion about the merits of a settled decision to interfere with their work tracking when they provide a perfectly good discussion forum[1] for that.
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.)
MacPorts and Homebrew behave identically here: precompiled binaries are not affected, only .app (and similar) bundles.
(People find this confusing, because Homebrew does a superset of what MacPorts does: it distributes both source/binary packages and it distributes "casks", which are essentially a CLI-friendly version of the App Store and come with macOS's additional restrictions on applications. This only affects casks.)
The hierarchy is actually a little more complicated than this. MacPorts can and does build open source GUI apps (in fact it largely rejects binaries for them, preferring to build them directly). Homebrew rejects GUI apps from being built from source. Because Homebrew downloads apps from the internet, it makes them with the quarantine attribute, which means more apps that it handles will be flagged by Gatekeeper.
I see, thanks! Is cc installed by default? I remember when my ex-wife had a Mac she had to sign up for Apple's developer program to get compilers installed.
No idea what you get out of the box, or what /usr/bin/cc actually is and does, but it looks like the underlying compiler is the clang that came with Xcode, which I installed from the app store. I do have an Apple account, but I don't think it's signed up to Apple's developer program... at least, probably not? I'm not paying them for this, anyway.
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.
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.