|
|
|
|
|
by easton
1948 days ago
|
|
Last I checked homebrew doesn't ask for root every time because it changes the permissions on /opt/homebrew (or /usr/local/bin if you are on Intel) to allow you to install software as non-root. This is still extremely insecure, as you can now install/remove/upgrade software on the system without root's permission, which is annoying if more than one user uses the device. Not to mention other applications that you run can now also write to these directories and blow stuff up without your permission, whereas if the permissions were set as default you'd get a password prompt at least. I still use brew (because it has more apps than macports), but why in the world they made this decision rather than using, say ~/Applications (the macOS recommended practice for software that only one user needs) or ~/homebrew is beyond me (granted, apt doesn't do this either, but I'm 99% sure that you can do it with yum and it is how scoop works on windows). |
|
Can you name a single attack that requiring root for Homebrew can protect against?
> but why in the world they made this decision rather than using, say ~/Applications (the macOS recommended practice for software that only one user needs) or ~/homebrew is beyond me
Because it's not possible to distribute binary packages without using a predetermined prefix path. You can easily find devs bullied into explaining the same thing if you look into forums or issue trackers of any binary system package manager.
> granted, apt doesn't do this either, but I'm 99% sure that you can do it with yum
No you can't. Yum, like any other binary package manager, doesn't let users choose their own installation path. There are exceptions though, and RPM packages can be marked as relocatable by the packagers, but that's a rare case.
> and it is how scoop works on windows
Windows is an outlier here, because Windows programs are mostly relocatable by necessity. Scoop packages can't rely on shared paths unlike Unix packages. This is why you end up with so many copies of bash.exe on Windows.