Live data from Hacker News

Our audit of Homebrew

blog.trailofbits.com

141–150 of 205 posts

Re: Our audit of Homebrew

#141
post #135

I’m a bit puzzled by the wording of this blog post, because it says you’ve worked with Homebrew to do this audit, but your name sounds familiar to me, and indeed if we check Homebrew’s README [1]: > Homebrew's maintainers are […long list of names…] William Woodruff […] [1]: https://github.com/Homebrew/brew Is there any reason this is not mentioned in the blog post? I don’t think it would make a difference, but just t…

I wasn’t a maintainer at the time I did the audit :-). I’ve been a non-maintaining “member” of the project for a long time, which is the pseudo-emeritus position we give to previous maintainers who want to continue participating in internal conversations and governance. I was then offered membership again, months after the audit, due to some unrelated work on Homebrew that didn’t exist and wasn’t planned before the a…

Thank you!

Re: Our audit of Homebrew

#142

I’m still good on MacPorts. Seems I’m alone these days. Works fine for me.

You are not. I've been using MacPorts for 15+ years at this point. Started with fink and then made the switch around the days of Snow Leopard. I'm also a BSD user, so no surprise there. I enjoy being able to compile ports with non-standard variants (e.g., non-free codecs in ffmpeg, removing un-needed interpreters from packages, etc.)

Re: Our audit of Homebrew

#143

I peeked at the sandbox escape bug and its associated fix: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7... . Is this…correct? Like, this is to prevent it from being interpolated into a sandbox profile and messing things up. How confident are we about this list of characters?

The commit message could have answered that question, but instead, it only repeats what the diff already tells us: "Don't allow special characters in sandbox rule paths". It doesn't explain why, or what's special about the particular characters that it disallows. A better message would have said something like "Prevent certain characters in the path because otherwise ... We need to worry about these specific characters but not others because..."

Even if I wrote this code and knew what it did today, if I come across this it a year from now, I'm left scratching my head: why did I make this change?

A real world example of a good commit message:

https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce98...

Re: Our audit of Homebrew

#144

I peeked at the sandbox escape bug and its associated fix: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7... . Is this…correct? Like, this is to prevent it from being interpolated into a sandbox profile and messing things up. How confident are we about this list of characters?

Surprised too, if that is the fix. Wouldnt a whitelist be better than a blacklist?

Re: Our audit of Homebrew

#145

Earlier quoted context omitted.

Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.

>Apple should have written it themselves. Please don't. It would be a resource hog SwiftUI monstrosity like the new Settings app. And while they are at it, they would probably introduce the 46353th bespoke feature into the Swift language too, because why not?

It would be (or at least have) a command-line utility like rpm, npm, apt, or pacman. That's necessary for it to integrate well with various installation scripts. So you wouldn't have to use a UI at all, especially if it's bad.

Re: Our audit of Homebrew

#146

Earlier quoted context omitted.

Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.

What a nonsensical conclusion. Homebrew existing is no reason for Apple to do replicate that trainwreck.

I thought it was clear from my comment that I was suggesting Apple would do it better. Think of how useful something like apt, npm, or pip is, and then realize that MacOS has no in-house equivalent.

Re: Our audit of Homebrew

#147

  > Since 2012, Trail of Bits has helped secure some of the world’s most targeted organizations and products. We combine high-­end security research with a real­ world attacker mentality to reduce risk and fortify code.
It's interesting that I don't see any analysis referencing OpenBSD (either as a product or as an alternative to something else they have done research on).

Re: Our audit of Homebrew

#148
post #19

Excellent work - a methodical review like this is exactly what I’ve been looking for in these sorts of open source solutions. I know it’s not the focus of a code review like this, but I’m interested to hear your views on the general supply chain lifecycle problems inherent to open-source package management platforms. Principally, are vetting processes appropriate to ensure that new formulas refer to the correct sourc…

I can't emphasize enough how much of a genuine issue this is, especially where package managers are being used on production environments or within CI/CD pipelines. There's enough publicized cases of Chinese CCP operatives gaining pull request access to key packages, and I'm sure many more get discovered that are covered up/not made public. Even just turn over of package ownership from reputable entities to lesser known individuals is of course worrying.

As a SWE/EngMgr turned VC, I'm curious if there's startups or commercial companies providing some kind of assurance here (but also worried the $ TAM for solving this problem probably isn't enough to make it a standalone business).

Re: Our audit of Homebrew

#149
post #148
post #19

Excellent work - a methodical review like this is exactly what I’ve been looking for in these sorts of open source solutions. I know it’s not the focus of a code review like this, but I’m interested to hear your views on the general supply chain lifecycle problems inherent to open-source package management platforms. Principally, are vetting processes appropriate to ensure that new formulas refer to the correct sourc…

I can't emphasize enough how much of a genuine issue this is, especially where package managers are being used on production environments or within CI/CD pipelines. There's enough publicized cases of Chinese CCP operatives gaining pull request access to key packages, and I'm sure many more get discovered that are covered up/not made public. Even just turn over of package ownership from reputable entities to lesser kn…

> enough publicized cases of Chinese CCP operatives gaining

Like? not doubting you, just not aware of multiple cases beyond the big near-miss earlier this year

Re: Our audit of Homebrew

#150
post #148

Earlier quoted context omitted.

I can't emphasize enough how much of a genuine issue this is, especially where package managers are being used on production environments or within CI/CD pipelines. There's enough publicized cases of Chinese CCP operatives gaining pull request access to key packages, and I'm sure many more get discovered that are covered up/not made public. Even just turn over of package ownership from reputable entities to lesser kn…

> enough publicized cases of Chinese CCP operatives gaining Like? not doubting you, just not aware of multiple cases beyond the big near-miss earlier this year

Also for that case, I don't think we have any clue who the guy is. Name just not meaning anything. Or anyone has any link to a formal trace to the origin?
Post reply on HN