The sandbox only applies to software devs that want to use it or those that wish to sell through the Mac App Store. I don't think Zoom is in the MAS at all (I don't see it in a quick search anyway), and a standalone installer is free to do whatever it wants and can convince users to go along with (up to and including, in principle, bypassing SIP though since that significantly raises the effort bar I've only ever seen niche stuff request it). And it's completely legitimate to want to run a server on your system too, there is no hole. Zoom simply acted as malware, taking actions without user permission.
SIP cannot be disabled by anything running in the current boot session. Once the root volume is mounted, the SIP flags are set in the mountpoint. The root volume obviously cannot be unmounted while it is booted from.
I don't fully understand the difference. But signed is different from notarized. Notarized means you uploaded the binary to Apple. Previously, you can sign without doing that.
I haven't looked enough to understand what is gained by notary. Does Apple want to search your binary for maliciousness or rulebreaking (potentially even at a later date) so that it might revoke the notarization/signature?
Some of this stuff seems a tad disingenuous. Like preventing debugging. The debugger APIs on Mac already pop up a password prompt, limiting the usability in malware (and actual use, like trying to debug over ssh). Meanwhile, a culture of producing separate binaries for debug and for end users (debug builds lacking optimization, allowing additional permissions) is in my experience a great way to fail to reproduce legit customer-facing bugs during development and have greater difficulty diagnosing them when they occur on a real live user machine.
As far as I understand, notarization is intended to catch malware before it can be distributed. The traditional signing mechanism can protect users against malicious software because Apple can pull certificates used to sign malware.
Watch the security talk. macOS is on the path to adopt iOS permissions model and long term roadmap is to apply the sandbox to everything, with the option to explicitly disable it on per-case basis.
A path similar to how Windows 10 is now converging the Win32 and UWP sanbox models, or how ChromeOS sandboxes GNU/Linux processes.
The MacBook is a general purpose computing platform. The iPhone and iPad are not. Locking down the Mac will make it unusable for many, many people. It will indeed be the death of the platform, as most devs abandon it entirely.
As a Mac user who develops high performance scientific applications portable between all UNIXen (Linux/Mac/BSD), I still can write my code pretty easily on the platform.
I personally don't use Homebrew, et al. but, I have a Linux VM which handles that stuff pretty well.
I didn't develop a Mac specific "application" though.
My experience has been the opposite. Of all the people I've worked with using Macs, all of them were developing cross-platform open source software. I've yet to meet a single developer making MacOS applications.
The sandbox only applies to software devs that want to use it or those that wish to sell through the Mac App Store. I don't think Zoom is in the MAS at all (I don't see it in a quick search anyway), and a standalone installer is free to do whatever it wants and can convince users to go along with (up to and including, in principle, bypassing SIP though since that significantly raises the effort bar I've only ever seen niche stuff request it). And it's completely legitimate to want to run a server on your system too, there is no hole. Zoom simply acted as malware, taking actions without user permission.