Live data from Hacker News

Our audit of Homebrew

blog.trailofbits.com

191–200 of 205 posts

Re: Our audit of Homebrew

#191

Earlier quoted context omitted.

> we got things like flatpak, appimage directly from developers Some people prefer timely, high-quality, well-tested bugfixes and security updates for the underlying low-level dependencies of an app. An upstream app developer is much less likely to provide an updated flatpak mere minutes after e.g. a critical OpenSSH security fix comes out of embargo. Distro maintainers on the other hand, such as the Homebrew core ma…

Core system package managers (apt etc) handle security issues quickly and in collaboration with security researchers and authorities. They have far more manpower, experience and connections than brew. Bleeding edge is handled by rolling package managers, and these often build automatically from source as soon as a commit is tagged. I don't see a clear reason to use brew, which does everything a little bit worse. In f…

> They have far more manpower, experience and connections than brew.

And Homebrew’s maintainer team, in turn, has far more of all that than the average Flatpak app developer has, which your earlier comment suggested as an alternative to Homebrew.

> I see it as a red flag in projects since it usually indicates lack of first class Linux support.

In most distros, upstream projects have very little say in whether or not the distro is going to include them. It’s the distro maintainers who make that decision, and it depends on many different factors, some of them outside of the upstream project’s control, but none of them related to „first class Linux support.“

For example: is the upstream license an acceptable fit for the distro? How many dependencies does it have, and are those already available as packages in that distro? Does it make technical assumptions that clash with the distro’s assumptions? Has anyone stepped up and authored the package yet? And so on.

Never have I seen “lack of first class Linux support” as a scale-tipping argument against including a particular package in a distro.

Re: Our audit of Homebrew

#192

Earlier quoted context omitted.

Core system package managers (apt etc) handle security issues quickly and in collaboration with security researchers and authorities. They have far more manpower, experience and connections than brew. Bleeding edge is handled by rolling package managers, and these often build automatically from source as soon as a commit is tagged. I don't see a clear reason to use brew, which does everything a little bit worse. In f…

> They have far more manpower, experience and connections than brew. And Homebrew’s maintainer team, in turn, has far more of all that than the average Flatpak app developer has, which your earlier comment suggested as an alternative to Homebrew. > I see it as a red flag in projects since it usually indicates lack of first class Linux support. In most distros, upstream projects have very little say in whether or not…

You realise flatpak had been around almost 20 years and has a HUGE community and commercial vendors behind it?

Brew was until recently just one guy in SF.

But let's agree to disagree.

Re: Our audit of Homebrew

#193
I am a bit surprised this did not highlight major low skill attack surface in Homebrew as compared to almost all Linux and *BSD package managers: Supply chain integrity.

Homebrew maintainers mostly do not sign commits/packages, do not sign reviews/merges, do not verify author/reviewer sigs at compile time, do not reproduce builds in separately controlled CI, do not enforce hardware 2FA on Github.

Every user of brew is only as secure as whichever of hundreds of brew maintainers has the worst opsec today.

Also since dependabot automatically makes commits, you could get a malicious commit into an external project you control, wait for dependabot to make a commit to homebrew to upgrade it, then merge it yourself (as becoming a homebrew maintainer has almost no vetting, just fix a few easy bugs)

You could also just take over one of the expired email domains of a maintainer and send a password reset email to yourself and take over an account of someone on vacation or hiatus.

Can likely get thousands of companies compromised before anyone notices.

Honestly I would never allow Brew on any company machines I have authority over. It is giving hundreds of randos, (and anyone that takes advantage of their poor opsec) the ability to execute any code on user systems.

Major Linux package managers do not go nearly far enough with things like review signing, but most at -least- do author-level package signing, human review, and independent reproduction for most packages.

Given how many high value targets like corporate sysadmins allow brew on their computers, Brew is on track to overshadow Crowdstrike any day now for most harm caused by insufficient supply chain management.

Re: Our audit of Homebrew

#194

Earlier quoted context omitted.

Human language is not math. It needs to convey concepts that are infinitely variable rather than binary. When a poet or novelist says something in an unusual way, they are being more accurate not less accurate. If there is ambiguity, it is because the concept or observation they mean to express has some ambiguous element. Trying to avoid that is just downsampling analog color reality to a 200ppi 1bpp fax. A related c…

The speed of light _is_ constant, how could it otherwise be a fundamental constant? I think you might have meant time/distance is relative?

What is the definition of speed?

Re: Our audit of Homebrew

#195
post #168

Earlier quoted context omitted.

Ah yes, the "bad guys".

Yeah, well, harvesting human organs (selling them to US customers) and maintaining death camps in 2024 is kind of "bad guys" for me. But, to each his own, I suppose. https://www.ohchr.org/en/press-releases/2021/06/china-un-hum... https://theconversation.com/killing-prisoners-for-transplant... https://www.bbc.com/news/world-asia-china-54277430 Other than these small misdemeanours, they're saints! Doubly so on the inte…

So is aiding and actively supporting a genocide and celebrating a war criminal, so what is your point?

Re: Our audit of Homebrew

#196

Earlier quoted context omitted.

> They have far more manpower, experience and connections than brew. And Homebrew’s maintainer team, in turn, has far more of all that than the average Flatpak app developer has, which your earlier comment suggested as an alternative to Homebrew. > I see it as a red flag in projects since it usually indicates lack of first class Linux support. In most distros, upstream projects have very little say in whether or not…

You realise flatpak had been around almost 20 years and has a HUGE community and commercial vendors behind it? Brew was until recently just one guy in SF. But let's agree to disagree.

> Brew was until recently just one guy in SF.

For some very loose definition of "recently." It's been a team of multiple maintainers, spread across the world, for well over a decade at this point.

Re: Our audit of Homebrew

#197

Earlier quoted context omitted.

For me, the key push towards using it as a Homebrew replacement was the fact that I already used Devbox to create isolated dev environments for individual projects I work on. Now I have one tool to manage all dependencies. Other than that, it likely comes down to personal preference. One neat thing is `devbox global push/pull ` to persist my config in a repo.

Oh this looks pretty cool. I started using Docker a while ago for dev projects to avoid package/language version hell, but sometimes its a bit overkill

I had done the same before I learned about Devbox.

It's very lightweight and gets very powerful combined with `git worktree` to work on multiple branches in parallel, each with its own database instance.

Re: Our audit of Homebrew

#199
post #168

Earlier quoted context omitted.

Ah yes, the "bad guys".

Yeah, well, harvesting human organs (selling them to US customers) and maintaining death camps in 2024 is kind of "bad guys" for me. But, to each his own, I suppose. https://www.ohchr.org/en/press-releases/2021/06/china-un-hum... https://theconversation.com/killing-prisoners-for-transplant... https://www.bbc.com/news/world-asia-china-54277430 Other than these small misdemeanours, they're saints! Doubly so on the inte…

The U.S. also harvests the organs of dead prisoners without consent. This is well-documented. 2 Democratic senators even proposed a bill to "reduce sentences" by "donating" your organs.

The U.S. runs the world's most extensive biological weapons research program and firmly opposes any verification for the BWC to which the U.S. is a signatory. The Pentagon operates a ridiculous number of bio labs in other nations.

The U.S. NIH was indirectly responsible for Covid - thanks to sponsorship of gain-of-function research into bat coronaviruses via the Ecohealth alliance, sponsorship of which was approved by good old "I represent Science" Dr Fauci. A massive and desperate cover up operation was performed by the NIH here. Hell, there were e-mails sent to delete everything and deflect all inquiries.

The U.S. deliberately sponsors coups in nations across the world for leaders they don't like - as evidenced by de-classified documents. The U.S. military budget is 7 times higher than that of China. Nearly a million people were killed directly and in-directly in Yemen thanks to good old American bombs.

Let's not even get into earlier acts - like Obama's "moderate rebels" in Syria who were busy chaining women in Aleppo and who devolved into ISIS after the Syrian army kicked them out and decided to conquer Iraq instead - all with the latest American weaponry in hand! (I strongly suggest speaking to a native Syrian who lived in Aleppo during that time to know about the horror)

Other than these very small misdemeanours, the U.S. is a saint! Doubly so on the internet. /s

Re: Our audit of Homebrew

#200

There's a bunch of TOB-BREW- n listed - are those like CVE numbers just for this project? Edit: Oh, it's "Trail Of Bits - homeBREW". But probably still yes.

Yep. We use the TOB-$PRODUCT-$XXXX convention for our audit findings, where $PRODUCT is the target under audit and $XXXX is a unique incrementing counter for each finding. (As far as I know, a lot of audit firms do similar things.)

[flagged]
Post reply on HN