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.

     /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Reminds me that there is still no official package manager on macOS. So https://nodejs.org/en/download/ has you comparing check sums.

2. Most of my post wasn’t addressing security, but actual real usability gains by using Homebrew.

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.

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.

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.

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.

That’s certainly true in some cases, but is definitely not the case in the majority. I think you are letting your personal biases color your judgement to much.

https://github.com/Homebrew/brew/blob/e2c76cce8e01fd80e0910d...

https://github.com/Homebrew/brew/blob/master/Library/Homebre...

https://github.com/pypa/packaging-problems/issues/74

Developer's website may change at any time, and even go back-and-forth between good and bad version. The pip software version won't. Put a version pin, and you can be sure you get a good package or an clear error.

Granted, you can record/verify the checksum of downloaded files as well, but many people don't. And crazy practices like 'curl | sh' make that impossible anyway.

Fixed that for you.