8 ms·

I'm somewhat surprised that this guide recommends Homebrew. I agree that using a package manager is a good way to keep software updated from a central, trusted

by snazz 6y ago

I'm somewhat surprised that this guide recommends Homebrew. I agree that using a package manager is a good way to keep software updated from a central, trusted repository--always a good thing--but Homebrew makes a number of trade-offs for convenience instead of security. MacPorts has most of the same common packages and doesn't mess up filesystem permissions like Homebrew does. If I remember correctly, the all-inside-the-home-directory technique used in this guide is unsupported by the Homebrew developers as well. See https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-package-managers/ https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack... for a more nuanced take on this.

jabirali 6y ago
> MacPorts has most of the same common packages and doesn't mess up filesystem permissions like Homebrew does. This is more a convenience than security question. I understand that Homebrew can install not only open source command-line tools, but also third-party binaries (via `cask`) and Mac App Store apps (via `mas`), and that all three types of software can be installed, updated, or removed via the same `brew` command or synced `Brewfile`. Does MacPorts offer something similar? In that case, how is its coverage compared to the systems above? (Context: I’m a long-time Linux user in the process of migrating to macOS.)
- snazz 6y ago
  As I understand it, MacPorts is a fair bit more limited in that regard. For my purposes, I haven't found a need for the ability to install third-party binaries and Mac App Store apps through my package manager, since every third-party binary I have installed includes its own updater and the Mac App Store updates apps as well. I can see how setting up everything in one place could be useful, but I haven't run into a situation where it has been useful in my macOS usage quite yet. Homebrew and MacPorts are philosophically pretty different from each other and neither can be directly compared to Linux package managers. I think you'll find the solution of MacPorts for OSS command-line tools + Mac App Store for Xcode and other random stuff + third-party installers for things like Sublime Text and Microsoft Office works pretty well in practice, although it's not quite as clean as using one package manager for everything.
  - jabirali 6y ago
    Thank you for sharing your experience on this :). > I can see how setting up everything in one place could be useful, but I haven't run into a situation where it has been useful in my macOS usage quite yet. What appeals to me personally is having a list of apps (the “Brewfile”), that I can sync between my work and personal computer via my dotfiles, and let the system mirror what apps are installed on both devices (“brew bundle” installs or uninstalls apps based on that app list). And that if I need to replace my machine, I can just sync my dotfiles to new machine and let Homebrew autorestore apps, including third-party apps and things from App Store. I’ve tried some “declarative package managers“ before and enjoyed that, so when articles like this [1] said Homebrew can apparently do the same across open-source software, Mac App Store apps, and third-party apps, via a single synced Brewfile, that seemed interesting. The same Brewfile also appears to be usable on Linux for open-source apps (via Linuxbrew). But I don’t yet have any experience with it, so I have no idea how well it works or whether it’s worth it. If we disregard third-party apps, do you know if MacPorts has an equivalent to Brewfile? [1]: https://openfolder.sh/macos-migrations-with-brewfile https://openfolder.sh/macos-migrations-with-brewfile
    - saagarjha 6y ago
      Somewhat, it does have a way of recreating your current setup (generally intended to be used across OS upgrades, but doesn't have to be limited to that usecase): https://trac.macports.org/wiki/Migration https://trac.macports.org/wiki/Migration
  - derefr 6y ago
    Cask doesn't just handle packaged GUI apps, but also binary distributions of command-line apps that are hard to compile from source; or are proprietary/closed-source; or are actually sandboxed point-release distributions of {software written in a scripting language + its vendored deps + its runtime}. None of these will have any sort of updater built into them, but they'll all be updated through `brew cask upgrade`. (Any random Golang binary you might download off of Github? Before I even Google it, I type `brew search $whatever` into my terminal. Way easier to keep updated than even the `go get`-installed version, and also doesn't require that you have go installed.) As well, even for GUI software that has Sparkle-like update support built in, if you don't use it very often, it won't get updated until the next time you launch it, and even then will only get updated if you're online at the time you launch it. This leaves you vulnerable in the specific case that the software is offline but opening an untrusted document (e.g. one you originally downloaded from the network.) The vulnerability in the app will likely be exploited immediately upon launch of the app, before the app gets to update itself. Doing a periodic `brew cask upgrade` also takes care of these (at the annoying expense of constantly upgrading apps that put out a new release every few days. Looking at you, Etcher.) Also, besides upgrading, brew is useful just for grabbing all this third-party software without having to run hither and thither to find it. Sometimes the only web route to downloading a piece of software involves one of those skeezy download-hosting sites that redirects you through several ad walls, or requires that you make an account to download. With brew, you skip all that — just e.g. `brew cask install megasync` or `brew cask install plex-media-server`. Also, brew suppresses any interactive GUI elements of the install/update process, if it possibly can. `brew cask install java`, besides skipping navigating through ten pages of links to links to TOS agreements to links on Oracle's website, also does not summon forth the Java installer GUI, but rather does everything in the command-line. (As far as I can tell, it doesn't install the Java updater, either; brew takes over responsibility for upgrading Java, so there's no need for an independent update checker.) And there's also `brew cask zap`, which is an uninstaller that actually cleans up after the program, removing not only the application itself, but also all the stuff the app either installed, or later created at runtime, under /Library. This takes advantage of Apple .pkg BOM manifests if it can; but also has a manually-specified section in brew formulae, to allow it to zap away the cruft of apps that don't bother to keep track of themselves (e.g. Zoom, zerotier, usboverdrive, switchresx, etc.) There's also `brew services` — brew packages (and I think brew casks, too) can install launchd unit-file templates; and you can then enable/disable these (i.e. [un]link them in ~/Library/LaunchDaemons), and manage the lifecycle of (start/stop/status) these (i.e. call into launchctl), through `brew services`. (My own `brew services` currently contains: docker-machine, ifs, postgresql, reds, ssh-askpass, unbound. I use it quite a lot! Much less arcane than launchctl itself.) ----- Oh, and disregarding all that, and addressing the assumption underlying your arguments (that homebrew "messes with the filesystem"): you can keep a brew installation that doesn't mess with the filesystem at all (see https://docs.brew.sh/Installation#untar-anywhere https://docs.brew.sh/Installation#untar-anywhere). It's just that doing so will confuse exactly the type of pre-compiled CLI (or POSIX-y GUI) tools that `brew cask` is meant to help you install. These would be the ones where important paths (e.g. $PREFIX/etc, $PREFIX/share) are burned into the compiled binary, and so by necessity one fixed prefix has to be selected to burn in at compile time. Usually the fixed prefix chosen is `/usr/local`. People install Homebrew to /usr/local (or rather, allow Homebrew to link casks into /usr/local) because it's better than the alternative — where that alternative isn't "all that stuff gets installed in a clean way instead" but rather "all that stuff makes a mess of /usr/local on its own, but now there's nothing watching it do it, so your /usr/local is now a permanent, opaque mess rather than a set of managed overlays." (Ever install LaTeX on macOS from its upstream download? Or how about calibre? PostGIS? R? They all make exactly these kinds of messes in /usr/local. At least, by letting brew install them, you can now upgrade or remove them; and it'll notice if one package's files are trampling over another's.)
- saagarjha 6y ago
  mas is independent of Homebrew and available on MacPorts: https://github.com/macports/macports-ports/blob/master/sysutils/mas/Portfile https://github.com/macports/macports-ports/blob/master/sysut.... There's discussion on the mailing list on whether MacPorts should have a sort of "caskroom" type thing–currently it tries to avoid this except in cases where it's impractical to build from source (e.g. Java).
- draebek 6y ago
  FWIW I use Homebrew Casks to install binary stuff, which MacPorts doesn't offer, and MacPorts to install everything else. (Oops, other than stuff that is only available on the Mac App Store, for which I use mas, which will probably fatally break some day.)
- stjohnswarts 6y ago
  I can't say I've needed to use anything outside the appstore and macports, I'm very satisfied with them. For macports you have to install the CLI tools for Xcode.
- Nginx487 6y ago
  MacPorts is an implementation of BSD family ports package managers. I don't know much about modern ports, but when I was an active FreeBSD user, it did not install binaries, compiling the package with all dependencies instead - that is why it offers only open-source packages by definition. Darwin itself a BSD family, so I guess MacPorts were the first package manager implementation. However, proprietary applications is a common thing on Mac, unlike Linux/BSD systems, that is why Homebrew offers much wider choice of packages.
  - saagarjha 6y ago
    MacPorts offers prebuilt binaries for many packages these days, although you can generally install them from source if you so wish (and it will do so if you are on a release for which the package is not built).
theobeers 6y ago
Thank you for this comment, and thanks to saagarjha for the blog post. I’ve had the feeling over the past year or so, that Homebrew is getting in the way of other steps that I’d like to take to secure my system. (And I’ve been confused by the policy of “absolutely no root until something goes wrong; then we tell you to use sudo to run terrifyingly broad commands.”)
sneak 6y ago
Additionally, Homebrew is spyware and the authors refuse to remove this functionality.
- katbyte 6y ago
  Have anymore detail on that statement?
- colinb 6y ago
  Really? Please tell me more.
  - sneak 6y ago
    Homebrew silently reports your IP address (and thus coarse location), a unique identifier (that allows your location to be tracked over time), as well as any packages you install, to Google (and by extension the US military intelligence community), each time you use it. I switched to Nix.
    - novok 6y ago
      HOMEBREW_NO_ANALYTICS=1 / brew analytics off doesn't prevent that?
      - snazz 6y ago
        Analytics connections are also trivial to block on a DNS level. Homebrew isn’t malware; it’s not going to circumvent a simple DNS block for analytics.
      - SSLy 6y ago
        that should be the default and google analytics should be opt-in at best
      - sneak 6y ago
        It does, but software that is spyware unless you twiddle the hidden knob to make it not spy is still spyware.
monadic2 6y ago
When are we going to see the unix filesystem reflect a threat model other than protecting users from each other? The filesystem permissions you're referring to being messed up work off threat model assumptions that pre-date unix. I mean maybe if Apple provided a decent way to sandbox processes or restrict them outside the traditional unix user-owned-process model, but all their efforts here seem designed to pimp their app store. /usr/local is just one place where this friction arises. SIP does not point to improvements here in the near future.
- saagarjha 6y ago
  Interestingly, both MacPorts and Homebrew use the facilities Apple has already provided to sandbox processes.
  - monadic2 6y ago
    Hmm, I am not sure we are using the term the same way. The processes built still run with my user id with full access to everything that entails. In any case, the App Store sandboxing is pretty useless at enabling end-users to control what the process does. I mean little snitch should be built in to the OS by now and given user experience considerations outside the control or snitch—say, shipping apps with explicit whitelisted routes to the internet you can view before launching one. /usr/local is a remnant of a time that makes no sense anymore for most developers in a time of dedicated workstations and I can hardly blame homebrew for pushing back against any of the cruft that's built up over the years but is now difficult to justify.
    - saagarjha 6y ago
      Sandboxing is usually applied during build time and not at runtime, which was probably different than what you were thinking.
  - spease 6y ago
    Does nix?

by snazz 6y ago

jabirali 6y ago

> MacPorts has most of the same common packages and doesn't mess up filesystem permissions like Homebrew does. This is more a convenience than security question. I understand that Homebrew can install not only open source command-line tools, but also third-party binaries (via `cask`) and Mac App Store apps (via `mas`), and that all three types of software can be installed, updated, or removed via the same `brew` command or synced `Brewfile`. Does MacPorts offer something similar? In that case, how is its coverage compared to the systems above? (Context: I’m a long-time Linux user in the process of migrating to macOS.)

snazz 6y ago
As I understand it, MacPorts is a fair bit more limited in that regard. For my purposes, I haven't found a need for the ability to install third-party binaries and Mac App Store apps through my package manager, since every third-party binary I have installed includes its own updater and the Mac App Store updates apps as well. I can see how setting up everything in one place could be useful, but I haven't run into a situation where it has been useful in my macOS usage quite yet. Homebrew and MacPorts are philosophically pretty different from each other and neither can be directly compared to Linux package managers. I think you'll find the solution of MacPorts for OSS command-line tools + Mac App Store for Xcode and other random stuff + third-party installers for things like Sublime Text and Microsoft Office works pretty well in practice, although it's not quite as clean as using one package manager for everything.
- jabirali 6y ago
  Thank you for sharing your experience on this :). > I can see how setting up everything in one place could be useful, but I haven't run into a situation where it has been useful in my macOS usage quite yet. What appeals to me personally is having a list of apps (the “Brewfile”), that I can sync between my work and personal computer via my dotfiles, and let the system mirror what apps are installed on both devices (“brew bundle” installs or uninstalls apps based on that app list). And that if I need to replace my machine, I can just sync my dotfiles to new machine and let Homebrew autorestore apps, including third-party apps and things from App Store. I’ve tried some “declarative package managers“ before and enjoyed that, so when articles like this [1] said Homebrew can apparently do the same across open-source software, Mac App Store apps, and third-party apps, via a single synced Brewfile, that seemed interesting. The same Brewfile also appears to be usable on Linux for open-source apps (via Linuxbrew). But I don’t yet have any experience with it, so I have no idea how well it works or whether it’s worth it. If we disregard third-party apps, do you know if MacPorts has an equivalent to Brewfile? [1]: https://openfolder.sh/macos-migrations-with-brewfile https://openfolder.sh/macos-migrations-with-brewfile
  - saagarjha 6y ago
    Somewhat, it does have a way of recreating your current setup (generally intended to be used across OS upgrades, but doesn't have to be limited to that usecase): https://trac.macports.org/wiki/Migration https://trac.macports.org/wiki/Migration
- derefr 6y ago
  Cask doesn't just handle packaged GUI apps, but also binary distributions of command-line apps that are hard to compile from source; or are proprietary/closed-source; or are actually sandboxed point-release distributions of {software written in a scripting language + its vendored deps + its runtime}. None of these will have any sort of updater built into them, but they'll all be updated through `brew cask upgrade`. (Any random Golang binary you might download off of Github? Before I even Google it, I type `brew search $whatever` into my terminal. Way easier to keep updated than even the `go get`-installed version, and also doesn't require that you have go installed.) As well, even for GUI software that has Sparkle-like update support built in, if you don't use it very often, it won't get updated until the next time you launch it, and even then will only get updated if you're online at the time you launch it. This leaves you vulnerable in the specific case that the software is offline but opening an untrusted document (e.g. one you originally downloaded from the network.) The vulnerability in the app will likely be exploited immediately upon launch of the app, before the app gets to update itself. Doing a periodic `brew cask upgrade` also takes care of these (at the annoying expense of constantly upgrading apps that put out a new release every few days. Looking at you, Etcher.) Also, besides upgrading, brew is useful just for grabbing all this third-party software without having to run hither and thither to find it. Sometimes the only web route to downloading a piece of software involves one of those skeezy download-hosting sites that redirects you through several ad walls, or requires that you make an account to download. With brew, you skip all that — just e.g. `brew cask install megasync` or `brew cask install plex-media-server`. Also, brew suppresses any interactive GUI elements of the install/update process, if it possibly can. `brew cask install java`, besides skipping navigating through ten pages of links to links to TOS agreements to links on Oracle's website, also does not summon forth the Java installer GUI, but rather does everything in the command-line. (As far as I can tell, it doesn't install the Java updater, either; brew takes over responsibility for upgrading Java, so there's no need for an independent update checker.) And there's also `brew cask zap`, which is an uninstaller that actually cleans up after the program, removing not only the application itself, but also all the stuff the app either installed, or later created at runtime, under /Library. This takes advantage of Apple .pkg BOM manifests if it can; but also has a manually-specified section in brew formulae, to allow it to zap away the cruft of apps that don't bother to keep track of themselves (e.g. Zoom, zerotier, usboverdrive, switchresx, etc.) There's also `brew services` — brew packages (and I think brew casks, too) can install launchd unit-file templates; and you can then enable/disable these (i.e. [un]link them in ~/Library/LaunchDaemons), and manage the lifecycle of (start/stop/status) these (i.e. call into launchctl), through `brew services`. (My own `brew services` currently contains: docker-machine, ifs, postgresql, reds, ssh-askpass, unbound. I use it quite a lot! Much less arcane than launchctl itself.) ----- Oh, and disregarding all that, and addressing the assumption underlying your arguments (that homebrew "messes with the filesystem"): you can keep a brew installation that doesn't mess with the filesystem at all (see https://docs.brew.sh/Installation#untar-anywhere https://docs.brew.sh/Installation#untar-anywhere). It's just that doing so will confuse exactly the type of pre-compiled CLI (or POSIX-y GUI) tools that `brew cask` is meant to help you install. These would be the ones where important paths (e.g. $PREFIX/etc, $PREFIX/share) are burned into the compiled binary, and so by necessity one fixed prefix has to be selected to burn in at compile time. Usually the fixed prefix chosen is `/usr/local`. People install Homebrew to /usr/local (or rather, allow Homebrew to link casks into /usr/local) because it's better than the alternative — where that alternative isn't "all that stuff gets installed in a clean way instead" but rather "all that stuff makes a mess of /usr/local on its own, but now there's nothing watching it do it, so your /usr/local is now a permanent, opaque mess rather than a set of managed overlays." (Ever install LaTeX on macOS from its upstream download? Or how about calibre? PostGIS? R? They all make exactly these kinds of messes in /usr/local. At least, by letting brew install them, you can now upgrade or remove them; and it'll notice if one package's files are trampling over another's.)
saagarjha 6y ago
mas is independent of Homebrew and available on MacPorts: https://github.com/macports/macports-ports/blob/master/sysutils/mas/Portfile https://github.com/macports/macports-ports/blob/master/sysut.... There's discussion on the mailing list on whether MacPorts should have a sort of "caskroom" type thing–currently it tries to avoid this except in cases where it's impractical to build from source (e.g. Java).
draebek 6y ago
FWIW I use Homebrew Casks to install binary stuff, which MacPorts doesn't offer, and MacPorts to install everything else. (Oops, other than stuff that is only available on the Mac App Store, for which I use mas, which will probably fatally break some day.)
stjohnswarts 6y ago
I can't say I've needed to use anything outside the appstore and macports, I'm very satisfied with them. For macports you have to install the CLI tools for Xcode.
Nginx487 6y ago
MacPorts is an implementation of BSD family ports package managers. I don't know much about modern ports, but when I was an active FreeBSD user, it did not install binaries, compiling the package with all dependencies instead - that is why it offers only open-source packages by definition. Darwin itself a BSD family, so I guess MacPorts were the first package manager implementation. However, proprietary applications is a common thing on Mac, unlike Linux/BSD systems, that is why Homebrew offers much wider choice of packages.
- saagarjha 6y ago
  MacPorts offers prebuilt binaries for many packages these days, although you can generally install them from source if you so wish (and it will do so if you are on a release for which the package is not built).

theobeers 6y ago

Thank you for this comment, and thanks to saagarjha for the blog post. I’ve had the feeling over the past year or so, that Homebrew is getting in the way of other steps that I’d like to take to secure my system. (And I’ve been confused by the policy of “absolutely no root until something goes wrong; then we tell you to use sudo to run terrifyingly broad commands.”)

sneak 6y ago

Additionally, Homebrew is spyware and the authors refuse to remove this functionality.

katbyte 6y ago
Have anymore detail on that statement?
colinb 6y ago
Really? Please tell me more.
- sneak 6y ago
  Homebrew silently reports your IP address (and thus coarse location), a unique identifier (that allows your location to be tracked over time), as well as any packages you install, to Google (and by extension the US military intelligence community), each time you use it. I switched to Nix.
  - novok 6y ago
    HOMEBREW_NO_ANALYTICS=1 / brew analytics off doesn't prevent that?
    - snazz 6y ago
      Analytics connections are also trivial to block on a DNS level. Homebrew isn’t malware; it’s not going to circumvent a simple DNS block for analytics.
    - SSLy 6y ago
      that should be the default and google analytics should be opt-in at best
    - sneak 6y ago
      It does, but software that is spyware unless you twiddle the hidden knob to make it not spy is still spyware.

monadic2 6y ago

When are we going to see the unix filesystem reflect a threat model other than protecting users from each other? The filesystem permissions you're referring to being messed up work off threat model assumptions that pre-date unix. I mean maybe if Apple provided a decent way to sandbox processes or restrict them outside the traditional unix user-owned-process model, but all their efforts here seem designed to pimp their app store. /usr/local is just one place where this friction arises. SIP does not point to improvements here in the near future.

saagarjha 6y ago
Interestingly, both MacPorts and Homebrew use the facilities Apple has already provided to sandbox processes.
- monadic2 6y ago
  Hmm, I am not sure we are using the term the same way. The processes built still run with my user id with full access to everything that entails. In any case, the App Store sandboxing is pretty useless at enabling end-users to control what the process does. I mean little snitch should be built in to the OS by now and given user experience considerations outside the control or snitch—say, shipping apps with explicit whitelisted routes to the internet you can view before launching one. /usr/local is a remnant of a time that makes no sense anymore for most developers in a time of dedicated workstations and I can hardly blame homebrew for pushing back against any of the cruft that's built up over the years but is now difficult to justify.
  - saagarjha 6y ago
    Sandboxing is usually applied during build time and not at runtime, which was probably different than what you were thinking.
- spease 6y ago
  Does nix?