* installs into /usr/local/bin, which is now a protected path with SIP. Why do you think Apple itself protected themselves from Homebrew? So what do Homebrew users do now? Disable SIP. Sigh
* installs with users permissions, not a seperate user. /usr/local/bin is now open for every pwner. The very first path, not just ~/bin.
Never trust a newbie package manager which takes over your whole system and installs into the very first path. Even macports can override the pre-installed coreutils without messing with /usr/local/bin.
Besides the security nightmares:
* is a unicorn, esp. for darwin only. macports uses the de-facto standard ports framework instead, just with tcl, not the shell.
apt or rpm are also not the standard. ports was much earlier and is used on much more platforms than those unicorns. You won't get any brew recipes from other and better managed packages. Those with a bit more experience.
/usr/local/bin is not under SIP, /usr/local is. Homebrew now changes the permissions and ownership of the directories inside of this to get around this (which is functionally the same thing, but I figured that I'd point this out to you before someone else did since your points are otherwise valid).
It's called a personal computer for a reason. Laptop sharing is not a really a thing for professionals (or at least not that common). So, complete non issue for the vast majority of the target audience (i.e. developers and techies). Actually, not requiring root permissions is a feature and not a bug as it reduces the scope of what these tools can do at the OS level, which is a good thing for software you blindly install after downloading.
Not requiring root to install software to system directories is a security bug, not a feature. In a practical sense Homebrew elevates you to root and in the process messes up the permissions of a /usr/local, which, being on $PATH, opens users up to vulnerabilities.
Nonsense. You are using users in plural. Macs are not typically used as multi user machines. Certainly not by developers. And when they are, so what? Technically, the permissions are only changed for the user that installs homebrew, which requires root access to change the permission, and not for the other users. If that's a problem for you, configure it to install stuff elsewhere.
Also, /usr/local is completely empty on a fresh OSX installation and the whole point of homebrew is to have the stuff you install with it on the path. That's the whole point; you put stuff there that isn't part of the OS because you need it. There's nothing to mess up other than the stuff that you put there. If you don't want stuff there, don't put it there. The only vulnerability is the single user of the laptop being an idiot. At least they can be idiots without defaulting to root privileges, which probably is an improvement.
Because I am talking about people who use Macs in general?
> Macs are not typically used as multi user machines. Certainly not by developers.
There are developers who share Macs: not everyone can afford to have a computer to themself. But that's still beside the point: regardless of the number of humans using the computer, Macs still have multiple permission levels, and there is always a "root" with more permissions than you.
> configure it to install stuff elsewhere
Yeah, this tends to break if you actually try this. Homebrew explicitly tells you that this is not well supported.
> Also, /usr/local is completely empty on a fresh OSX installation and the whole point of homebrew is to have the stuff you install with it on the path.
Yes, but there are better, and more secure ways to do this. What you should be doing is require sudo to install to a directory that is global and automatically on $PATH, or install locally to ~/bin (for example) and then put that on your $PATH. The way Homebrew does it, where it changes the permissions of /usr/local's folders, is bad because it opens the door to attacks when system software running as root picks up binaries from $PATH (which you have now changed ownership and permissions of to be writable by your user) making any code execution bug instantly become a privilege escalation attack. This isn't the first time I've had this discussion, so I have more detailed explanation which links to an actual example of this being exploited in practice: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
> The only vulnerability is the single user of the laptop being an idiot.
Aside from the fact that the security hole exists regardless of me doing something stupid, I'd like my software to work as well as possible in the face of me being an idiot ;)
Basically it means if someone has user access on a Mac with Homebrew (with default settings), they also have root. So a remote hole in, say, Safari, means your entire system is compromised.
They don't quite have root per se, but they have a functional elevation of privileges if some some other software has a bug in it with regards to pulling binaries from $PATH, which is quite common.
