I hate to have to be this harsh as it is clear you did a lot of work, but I have warned members of the brew team about serious gaps here multiple times over the years and seemingly nothing has been done. Brew is not anywhere close to a level of supply chain security to be allowed anywhere near production access or production code review.
Language package managers are a joke and not worth comparing to but at least we can quarantine those. No security conscious person would run NPM outside of a VM or a container with code they did not review. But brew is a system package manager so the risk is not comparable. It might be the thing that installs the VM or container tools in the first place, so users have little way to protect themselves.
Your setup is based on the honor system and it is important people know that so they do not use it on any system they need to be able to trust.
If I were to create a fake identity and contribute my way to becoming a brew maintainer, I would have the power to create yet another pseudonym to submit malicious code that I "review" and merge.
Or since builds are mostly not reproducible a compromise of a single CI/CD pipeline could inject a trusting trust attack into a dependency of a dependency of the compiler, and then I own every downstream system that uses brew forever even after version updates.
Or maybe I compromised the github credentials of a single engineer and did a merge as them at the right moment when they were doing a bunch of others to get it lost in the noise. Without signing impersonation is easy.
I would not actually do any of these things, but someone else could have already, a year ago.
You will never solve any of these holes without full source bootstrapping, deterministic builds, mandating every maintainer sign every commit, and review with a well known and pinned keys individually controlled on smartcards, and then also sign every binary artifact with multiple keys after independent reproducible builds.
This is the bare minimum for a system package manager. Comparing ourselves to others does not cut it anymore, because patient humans and AI bots will absolutely take advantage of honor system security models.
Implying brew is secure enough for production use is going to get people hurt.
A responsible system package manager must trust no single human, no single credential, and no single machine.
They are all significant risks, and we pay significant money to JFrog for their X-ray product to scan and alert on bad dependencies, and significant internal tooling to track which package was used on which developer enclaves.
Those are also all just as bad but you can at least run those fully in containers or vms and never let them touch your host system.
Brew however is a system level package manager so it is expected to install your top level tools with substantial privilege, so for using it on a production capable system you would want maintainer signed commits, maintainer signed reviews, and 2+ maintainer signed reproducible builds, all with well known long lived keys controlled by smartcards of each maintainer on high trust systems.
I am not just talking out of my ass here. We do all of the above in stagex because it is the bare minimum.
https://docs.brew.sh/Homebrew-Security-and-Supply-Chain
We take supply chain security very seriously, moreso than many package managers.
I hate to have to be this harsh as it is clear you did a lot of work, but I have warned members of the brew team about serious gaps here multiple times over the years and seemingly nothing has been done. Brew is not anywhere close to a level of supply chain security to be allowed anywhere near production access or production code review.
Language package managers are a joke and not worth comparing to but at least we can quarantine those. No security conscious person would run NPM outside of a VM or a container with code they did not review. But brew is a system package manager so the risk is not comparable. It might be the thing that installs the VM or container tools in the first place, so users have little way to protect themselves.
Your setup is based on the honor system and it is important people know that so they do not use it on any system they need to be able to trust.
If I were to create a fake identity and contribute my way to becoming a brew maintainer, I would have the power to create yet another pseudonym to submit malicious code that I "review" and merge.
Or since builds are mostly not reproducible a compromise of a single CI/CD pipeline could inject a trusting trust attack into a dependency of a dependency of the compiler, and then I own every downstream system that uses brew forever even after version updates.
Or maybe I compromised the github credentials of a single engineer and did a merge as them at the right moment when they were doing a bunch of others to get it lost in the noise. Without signing impersonation is easy.
I would not actually do any of these things, but someone else could have already, a year ago.
You will never solve any of these holes without full source bootstrapping, deterministic builds, mandating every maintainer sign every commit, and review with a well known and pinned keys individually controlled on smartcards, and then also sign every binary artifact with multiple keys after independent reproducible builds.
This is the bare minimum for a system package manager. Comparing ourselves to others does not cut it anymore, because patient humans and AI bots will absolutely take advantage of honor system security models.
Implying brew is secure enough for production use is going to get people hurt.
A responsible system package manager must trust no single human, no single credential, and no single machine.
I’m one of Homebrew’s security maintainers, and I don’t recall any contact with you. Who did you reach out to?
If you have concrete concerns, please bring them to us. Vague concerns and hand-waving about “people getting hurt” isn’t appropriate or productive.
1 reply →
How is that any different from PyPI, npm, cargo, etc?
They are all significant risks, and we pay significant money to JFrog for their X-ray product to scan and alert on bad dependencies, and significant internal tooling to track which package was used on which developer enclaves.
Those are also all just as bad but you can at least run those fully in containers or vms and never let them touch your host system.
Brew however is a system level package manager so it is expected to install your top level tools with substantial privilege, so for using it on a production capable system you would want maintainer signed commits, maintainer signed reviews, and 2+ maintainer signed reproducible builds, all with well known long lived keys controlled by smartcards of each maintainer on high trust systems.
I am not just talking out of my ass here. We do all of the above in stagex because it is the bare minimum.
https://github.com/whoschek/homebrew-cooldown