Hacker News Reader

Comment by brianpgordon | Hacker News Reader

It seems like you're assuming that there's someone vetting these packages. For enterprise distros like Red Hat that's certainly true. Community package maintainers in, for example, the Debian project provide some safety as well. But there are plenty of package managers where that's just not the case. In the case of Homebrew, the package manager pulls down the program directly from upstream and installs it. It's exactly the same as downloading a tar file from the developer's website over HTTPS. Same with npm. Some package managers like Maven and NuGet will rehost artifacts but if the project owner is malicious or compromised then that won't help - so the risk profile is again basically the same as downloading a tar file from the website.

View on HN

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

Homebrew 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 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/ has you comparing check sums.

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

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

They do chroot. You can only install to specific directories

Ah, 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/e2c76cce8e01fd80e0910d...

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

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

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

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

To some extent, sure, but I think that extent is greater with Homebrew. It's my understanding that package maintainers for Debian, RHEL, etc are typically experts in the packages that they maintain. They overlay their own patches to ensure compatibility and submit patches upstream. With Homebrew there's only a small number of committers who maintain the homebrew-core repository, accepting PRs from thousands of people in the community. It's just a different situation.

> It's my understanding that package maintainers for Debian, RHEL, etc are typically experts in the packages that they maintain.

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.

Many package managers provide a real audit trail, and this (IMHO) is very valuable. For example, in python's PIP (and apparently in NPM too), the filenames are never reused:

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.

npm removes malware when reported.

s/when/if/

Fixed that for you.

I don't believe that changes the meaning.

(sorry, it was an obscure inverted reference to the saying "not if, but when")

Which is repeating that sources matter: curl from a source like Github with a solid abuse process is a very different story than an unknown server.

Reply on news.ycombinator.com