3 ms·

https://docs.brew.sh/Homebrew-Security-and-Supply-Chain https://docs.brew.sh/Homebrew-Security-and-Supply-Chain We take supply chain security very seriously, m

https://docs.brew.sh/Homebrew-Security-and-Supply-Chain https://docs.brew.sh/Homebrew-Security-and-Supply-Chain We take supply chain security very seriously, moreso than many package managers.

lrvick 20d ago
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.
- woodruffw 19d ago
  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.
  - lrvick 19d ago
    I had jumped into chats and a github issue as I recall, probably 7-8 years ago based on the employer I was researching it for, but would be hard to track that down now. Anyway, my tone may not be entirely constructive, but it is one of frustration as seemingly no one is taking supply chain attacks seriously anywhere I look. I am quite sure if homebrew was backdoored, it would give an attacker control of production systems of countless financial companies, defense contractors, healthcare providers, AI labs. I think it is insane they trust rando homebrew maintainers with that much power, but they do and they are probably not going to stop because they do not even understand these risks, and there are not practical alternatives to brew on MacOS. So that puts some major responsibility on the Homebrew team to either warn people to stop using it in high risk environments, or manage homebrew in a way appropriate for those environments. Stagex actually does every single thing I am recommending Homebrew do, and with a way smaller team. What we do is also nowhere near enough, but the bar is in hell.

https://docs.brew.sh/Homebrew-Security-and-Supply-Chain https://docs.brew.sh/Homebrew-Security-and-Supply-Chain We take supply chain security very seriously, moreso than many package managers.

lrvick 20d ago

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.

woodruffw 19d ago
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.
- lrvick 19d ago
  I had jumped into chats and a github issue as I recall, probably 7-8 years ago based on the employer I was researching it for, but would be hard to track that down now. Anyway, my tone may not be entirely constructive, but it is one of frustration as seemingly no one is taking supply chain attacks seriously anywhere I look. I am quite sure if homebrew was backdoored, it would give an attacker control of production systems of countless financial companies, defense contractors, healthcare providers, AI labs. I think it is insane they trust rando homebrew maintainers with that much power, but they do and they are probably not going to stop because they do not even understand these risks, and there are not practical alternatives to brew on MacOS. So that puts some major responsibility on the Homebrew team to either warn people to stop using it in high risk environments, or manage homebrew in a way appropriate for those environments. Stagex actually does every single thing I am recommending Homebrew do, and with a way smaller team. What we do is also nowhere near enough, but the bar is in hell.