Defaults to. You can tell it to compile yourself, if that matters to you. I don’t see what the issue is here. Why is it a problem that it defaults to binary distribution?
> The biggest problem is that the defaulting to binary distribution also means that building from source is unsupported.
I don't think it means that at all. They're both clearly supported by homebrew — one just happens to be the default. You can always use -s or --build-from-source to build whatever package you are installing.
It's running the same compilation steps that the binaries are produced from. If you can get a binary through homebrew, you can compile it from source. It's just unsupported in the sense that the developers don't want to spend their time chasing down build issues on individual user's systems. You're on your own if you break your local build environment.
(Ignoring the packages that are just wrappers around closed source software and fetch binaries whether you compile from source or not. Those are the exception, not the rule.)
I mean, you can download source if you want to run it. It isn’t a complete nightmare yet. I think we’re still in a grey area. This will help some people still, though it’ll definitely hinder others (myself included).
Once you need to be in the apple developer program to build and run from source or something, that’ll be a legitimate nightmare. But we’re nowhere near that yet.
> Once you need to be in the apple developer program to build and run from source or something, that’ll be a legitimate nightmare. But we’re nowhere near that yet.
When Quarantine was released in Leopard, and Gatekeeper in Lion, and System Integrity Protection in El Capitan, and then "Allow from Anywhere" was removed as an option in Sierra... Each time, people were saying similar things. "Yea, it's bad, and it's getting consistently worse with every release, but surely we are nowhere near 'really bad' yet!"
To me these are clear security improvements; things are not getting worse. And there is absolutely no reason to think they'll be dropping support for endusers running their own compiled software.
The obvious end point would be the same as iOS, which is to say - you can run it to your heart's content, provided that you shell out for a dev certificate.
The fact that macOS is increasingly becoming iOS-like in both UX and approach to security is not obvious? It's pretty obvious to me from the past few macOS releases.
There are huge, important segments of the macOS user base that require the ability to compile and run their own applications, locally. macOS has pretty much taken over all of academic science & education, & personal workstations for government research. It is the default platform for developers of all kinds in Silicon Valley. As Steve Balmer once argued, it's developers that matter to the long-term health of a platform. Apple deftly captured that market by providing a beautiful and easy to use UNIX-like environment with high quality hardware and good design. If Apple locked down macOS the same way they lock down iOS, it would be the largest foot-gun in the history of computing.
Simultaneously, while the user interface of macOS has converged on iOS over the last half dozen releases and the ecosystems are more tightly integrated, not a single one of these changes has gotten in the way of developers running their own code. The situation now is no different than it was in 2006, for example. What has been made more difficult is running untrusted binaries downloaded from the internet. That's not the same thing.
One argument in favor of removing it (not saying it’s the reason or that they didn’t have other options) is that ctrl-click and open did not obviously do anything different. That is, whether you ctrl-click and open a signed app or an unsigned app, the command in the menu was just “open”, with no indication that you were overriding a security policy. Then the dialog it popped up wasn’t particularly distinct from the “first time run” dialog. There is an argument to be made that going to the security settings and specifically allowing an app is a more clear expression of intent. Kind of in the same way you probably want to open a file you download from the web, but good security practices means the browser doesn’t open it for you on download, you need to explicitly go do it.
That said there’s no reason they couldn’t have fixed either of those issues instead
> Once you need to be in the apple developer program to build and run from source or something, that’ll be a legitimate nightmare. But we’re nowhere near that yet.
This is the case for building and running things with restricted entitlements and system extensions.
Unless you disable system integrity protection entirely, which locks you out of your purchased App Store software, DRM content, etc.
What I'm referencing is that they removed `spctl --master-disable`. This was referenced in release notes that I read upon upgrading, and testing it on my own system confirms it is gone.
Care to explain the nightmare to someone who seriously doesn't get it?
I can run any open-source software I want. Other people can't run my precompiled binaries unless I opt into an attestation system that lets the OS respond to and pre-emptively block binaries from developers found to be issuing malware. Open source is unaffected.
I challenge you to find old software that still runs on modern Macs which was never code signed. Note that support for 32-bit applications has been retired, and x86 applications will eventually be sunsetted as well. This isn't Windows.
Indeed, the current state of affairs on the Mac is the consequence of Apple repeatedly making this kind of choice. That doesn't make it any less frustrating when things that worked before, stop working after.
