4 ms·

I always thought that brew was the "Linuxy" one and Macports was FreeBSD Ports for the Mac.

sirn 6y ago
Jordan Hubbard was involved in the creation of both FreeBSD Ports and MacPorts (DarwinPort), so it makes sense that it shares the BSD ways of doing things. His decision to use Tcl for MacPorts also came from his experience dealing with Makefiles[1] [1]: https://netbsd.org/gallery/10years.html#hubbard https://netbsd.org/gallery/10years.html#hubbard
yardie 6y ago
Well I don't mean Linuxy in the architecture sense but Linuxy in the preparation and final stage installation sense. Like Homebrew does not need elevated privileges to work and actively discourages it. MacPorts, when something breaks, is a rabbit hole of elevated commands to bring it back to functional. Of course this is my opinion as I had Macports and Homebrew installed on my MBP 2012. I've swapped to a newer MBP and I only have HB installed. Since most packages are on HB I no longer need to have both installed.
- sirn 6y ago
  > Like Homebrew does not need elevated privileges to work and actively discourages it It does this by chowning /usr/local to a local user, which is worse for security than running sudo because now any malicious process can overwrite /usr/local/bin/bash without asking for privileges. macOS having /usr/local/bin in its $PATH by default also doesn't help. Homebrew made this security vs usability tradeoff because most Mac users are a single user, which makes sense in its context. The recent change of moving Homebrew to /opt/homebrew (at least for M1 Mac) is a better solution for this as it is no longer in the default $PATH. On the other hand, MacPorts approach of requiring sudo allows it to drop privileges to other unprivileged non-admin user (macports) during build in addition to building everything via sandbox-exec.
  - LiberatedLlama 6y ago
    Running untrusted software on these sort of systems is fundamentally broken, no matter what the package manager chooses chown or not chown. A malicious program could edit ~/.bashrc to modify the user's PATH, or wrap sudo with a keylogger then use that password to chown anything it likes. That's not even a theoretical but unlikely sort of attack; it's quite trivial. > alias sudo='echo not what I expected' > sudo foo not what I expected
    - sirn 6y ago
      That's fair, but it's only affecting single user, while writable /usr/local affects all users. However most Mac users are single user, so the tradeoff makes sense in this context.

sirn 6y ago

Jordan Hubbard was involved in the creation of both FreeBSD Ports and MacPorts (DarwinPort), so it makes sense that it shares the BSD ways of doing things. His decision to use Tcl for MacPorts also came from his experience dealing with Makefiles[1] [1]: https://netbsd.org/gallery/10years.html#hubbard https://netbsd.org/gallery/10years.html#hubbard

yardie 6y ago

Well I don't mean Linuxy in the architecture sense but Linuxy in the preparation and final stage installation sense. Like Homebrew does not need elevated privileges to work and actively discourages it. MacPorts, when something breaks, is a rabbit hole of elevated commands to bring it back to functional. Of course this is my opinion as I had Macports and Homebrew installed on my MBP 2012. I've swapped to a newer MBP and I only have HB installed. Since most packages are on HB I no longer need to have both installed.

sirn 6y ago
> Like Homebrew does not need elevated privileges to work and actively discourages it It does this by chowning /usr/local to a local user, which is worse for security than running sudo because now any malicious process can overwrite /usr/local/bin/bash without asking for privileges. macOS having /usr/local/bin in its $PATH by default also doesn't help. Homebrew made this security vs usability tradeoff because most Mac users are a single user, which makes sense in its context. The recent change of moving Homebrew to /opt/homebrew (at least for M1 Mac) is a better solution for this as it is no longer in the default $PATH. On the other hand, MacPorts approach of requiring sudo allows it to drop privileges to other unprivileged non-admin user (macports) during build in addition to building everything via sandbox-exec.
- LiberatedLlama 6y ago
  Running untrusted software on these sort of systems is fundamentally broken, no matter what the package manager chooses chown or not chown. A malicious program could edit ~/.bashrc to modify the user's PATH, or wrap sudo with a keylogger then use that password to chown anything it likes. That's not even a theoretical but unlikely sort of attack; it's quite trivial. > alias sudo='echo not what I expected' > sudo foo not what I expected
  - sirn 6y ago
    That's fair, but it's only affecting single user, while writable /usr/local affects all users. However most Mac users are single user, so the tradeoff makes sense in this context.