Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not a very technical person, but I think MacPorts adheres better to macOS standards and security practices. (At least it asks my admin password before any major interaction.) Been using for a few years, coming from Homebrew, and it's running smoothly.


> At least it asks my admin password before any major interaction.

Homebrew specifically stops you from doing stuff as root. It asks for your password once at install time so it never has to do it again.


It does that by making a global location (/usr/local) user-owned, which I'd say is much worse.


Several years ago, when the read-only-system OS changes happened, they switched to /opt/homebrew.


By default, Homebrew requires world-writeable location in the PATH (doesn't matter if it's /opt/homebrew or /usr/local). In my opinion, this isn't a sensible choice.

Homebrew, as the name implies, was built for hobbists with little regards for security. Not a problem for many, but it does make it incompatible with a corporate environment.


It does matter though? /opt/homebrew is specifically used by Homebrew, whereas /usr/local is kind of a more shared location that old Homebrew hijacked.

Either way, I think bad default folders is better than bad default security practices. Most package manager forces you to use sudo to run them as root, and I think that's much much worse in terms of security practices and encourages the wrong behaviors and potentially allowing build/install scripts to wreck havoc on your system. (Note that /opt/homebrew is not world writable as you suggested. It's only writable by the user)

Instead, Homebrew prefers to run in a user account, default to yours. If you have a multi-user computer, you can install Homebrew to a local user folder to have isolation and not using a global location like /opt/homebrew, or you can make a special Homebrew user account (rather than using root), which is what the docs suggest (https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad).

I don't think the current solution is perfect, but I do think the motivation to prevent usage of sudo is correct in terms of security. In fact, I would argue that the other package managers that use sudo are taking the easy way out (albeit insecure).


MacPorts drops elevation on package installation, so no, sudo is a better way than globally messing with the permissions and writing a confused FAQ about it


If it's for a corporate environment then it is being centrally configured anyway, so can just be installed from a different user?

The goal posts definitely seem to be moving over the course of this thread?


I just whish macports had buikdslaves for m1/m2 architecture. It's just too much to have to rebuild clang and gcc (as build deps) on every other upgrade...

I've even considered donating a Mac mini or something - but not to the point that I've yet emailed the macports list to ask how I could do that...

Ed: see

https://build.macports.org/buildslaves




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: