How does homebrew maintainers ensure the authenticity of binaries from each formula?

Question

Since homebrew is community-driven, what will happen if someone submits a malicious formula. Will this get merged into the main repository and end up being installed by everyone else? How can homebrew prevent this?

Answer 1

These things could conceivably happen. The general consensus out there seems to be that the likelihood is small enough to ignore. IT companies like Google, Amazon, and so on are perfectly OK with employees using it, so it is probably fine if you do too.

Google: 90% of our engineers use the software you wrote (Homebrew) [...]

--- Max Howell, initiator of Homebrew (https://twitter.com/mxcl/status/608682016205344768)

Review works

Getting a malicious formula merged is actually not that easy. The fact that you need a GitHub account and that building up a GitHub profile (to give yourself credibility) is a hard work (you have to program) can be a first line of defense.

There are actual humans looking at the formula during the Pull Request process. Nothing obvious should pass through, moreover, it is possible that just the fact of people being there and doing the checking dissuades many from even trying to propose something malicious.

Possible attacks

Has any repository hacking actually happened? Hard to say, because the following example could easily be just a honest mistake.

CVE-2008-0166

In 2008, an overactive Debian maintainer introduced a bug to OpenSSL, apparently in an effort to "clean up the code." (https://www.schneier.com/blog/archives/2008/05/random_number_b.html)

Lets now turn to other possible attack mechanisms

Typo-squatting

Attacker uploads a package that is similarly named to a popular one. People make typos and download the spoofed one.

This was successfully demonstrated for Pypi in N. P. Tschacher's bachelor thesis, see incolumitas.com/2016/06/08/typosquatting-package-managers/.

Any kind of manual review should catch it, so Homebrew is likely safe from it.

Reflections on Trusting Trust

(https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf)

Famous essay by Ken Thompson which walks you through a procedure to insert a Trojan horse into a software stack (both the compiler and the application), so that it is present in both, but not easily detectable in either.

Dependency confusion

(https://www.schneier.com/blog/archives/2021/02/dependency-confusion-another-supply-chain-vulnerability.html)

Pick a company that is running an internal package repository. Publish a public package which has the same name as an internal company package. Then, the package installer may mistakenly prioritize the public name, and therefore employees of the company suddenly start installing your package.