3 ms·

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 m

by rpgbr 4y ago

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.

latexr 4y ago
> 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.
- melvyn2 4y ago
  It does that by making a global location (/usr/local) user-owned, which I'd say is much worse.
  - misnome 4y ago
    Several years ago, when the read-only-system OS changes happened, they switched to /opt/homebrew.
    - snotrockets 4y ago
      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.
      - misnome 4y ago
        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?
      - xign 4y ago
        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 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).
        eviks 4y ago
        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
e12e 4y ago
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 https://build.macports.org/buildslaves

by rpgbr 4y ago

latexr 4y ago

> 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.

melvyn2 4y ago
It does that by making a global location (/usr/local) user-owned, which I'd say is much worse.
- misnome 4y ago
  Several years ago, when the read-only-system OS changes happened, they switched to /opt/homebrew.
  - snotrockets 4y ago
    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.
    - misnome 4y ago
      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?
    - xign 4y ago
      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 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).
      - eviks 4y ago
        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

e12e 4y ago

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 https://build.macports.org/buildslaves