5 ms·
> In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it. Sure, in the most basic case it does this, but ev
by jsjohnst 7y ago
> In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it.
Sure, in the most basic case it does this, but even in the most basic case it does more than that. At minimum it also verified the download matches a known good hash.
The important part (to me) is that Homebrew also ensures the package installed conforms to Homebrew’s standard. There’s a lot of standards (install in /usr, /usr/local, /opt, etc) on something as simple as where the files are put, let alone how it’s built and it’s dependencies are pulled in.
So to say there’s no value in installing from Homebrew over curl|sh is clearly misguided IMHO.
- lloydde 7y agoHomebrew is only as secure as the results of that first curl command /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" I get why https://docs.brew.sh/Installation https://docs.brew.sh/Installation doesn’t discuss the versioning or security practices. It is interesting that homebrew doesn’t seem to interface with macOS’s signing and installation practices. Reminds me that there is still no official package manager on macOS. So https://nodejs.org/en/download/ https://nodejs.org/en/download/ has you comparing check sums.
- jsjohnst 7y ago1. Using curl|sh isn’t the only way to install Homebrew 2. Most of my post wasn’t addressing security, but actual real usability gains by using Homebrew.
- brianpgordon 7y agoHow exactly is the file going to get tampered with if you're using curl-to-sh? Everyone uses HTTPS nowadays. Validating the hash is not really doing anything significant. As for ensuring that the package is well-behaved, could you elaborate on that? I'm not aware of Homebrew doing something like chrooting to /usr/local before running the install script. And the install script can do anything as your local user, same as curl-to-sh. Perhaps the Homebrew maintainers would catch something nefarious in the formula itself, but given that most formulas download code from the Internet and run it, that's not much help.
- dickeytk 7y agoThey do chroot. You can only install to specific directories
- brianpgordon 7y agoAh, I found it. On MacOS they rely on sandbox-exec which uses the sandboxing mechanism provided by the kernel: https://github.com/Homebrew/brew/blob/e2c76cce8e01fd80e0910ddbf8d03092d8753673/Library/Homebrew/formula_installer.rb#L930 https://github.com/Homebrew/brew/blob/e2c76cce8e01fd80e0910d... https://github.com/Homebrew/brew/blob/master/Library/Homebrew/sandbox.rb https://github.com/Homebrew/brew/blob/master/Library/Homebre...
- jsjohnst 7y ago> Validating the hash is not really doing anything significant. Yes it is, it’s ensuring that what the maintainer of the formula verified is still what’s being downloaded now. HTTPS does nothing to protect someone modifying the source URL, but the hash does that (assuming the maintainer actually inspected the initial download, which many if not most do). > but given that most formulas download code from the Internet and run it, that's not much help. 1) the previously erroneously dismissed hash helps there. 2) the sandbox which you linked to later also helps too.
- brianpgordon 7y agoI suppose it comes down to whether the Homebrew maintainer who accepts the formula PR containing the hash is actually examining the upstream code in detail. I think that is unlikely; there's too much code for Homebrew maintainers to be experts on everything contained in homebrew-core and follow every single patch. So yes, the hash prevents the upstream project from switching out the code at any time, but if they wanted to add some malicious code all they have to do is file a homebrew-core PR and hide it in a legitimate change.
- jsjohnst 7y ago> I think that is unlikely; there's too much code for Homebrew maintainers to be experts on everything contained in homebrew-core and follow every single patch. By that logic, everything in any package manager should be treated with distrust then. Debian, RHEL, Arch, etc etc. Not saying I disagree with distrusting, just making the point that risk exists everywhere, at some point you have to decide what you’re comfortable with.