Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our audit of Homebrew

blog.trailofbits.com

Post reply on HN
Print view View original

11–20 of 205 posts

Re: Our audit of Homebrew

#11

Post by woodruffw »

apitman wrote: post #4

A while back I was trying to understand why Homebrew requires pre-built executables to be installed into /home/linuxbrew. I asked about it here[0]. This requirement basically makes it impossible to use homebrew to quickly install programs on systems where you don't have root, or at least have homebrew already configured (not sure if that would solve it but I assume so). They pointed me to an example program that woul…

The short (but possibly not satisfying) answer is that Homebrew's relocation of packages (including binary relocation) is best effort, in part because of the myriad ways in which packages can embed absolute (or incorrect relative) paths and other state in their build products. macOS bottles are generally more relocatable (in part because of a lot of scar tissue around binary relocation), but it's a general problem with build system quality, build complexities, and - reasonably - disinterested upstreams.

Re: Our audit of Homebrew

#12

Post by Alifatisk »

woodruffw wrote: post #3
yjftsjthsd-h wrote: post #2

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.)

First time seeing TOB being used honestly, it would’ve helped saying something along the lines of ”Trait of Bits (TOB from now on)”

Re: Our audit of Homebrew

#13

Post by [deleted] »

jmbwell wrote: post #10

With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.

[deleted]

Re: Our audit of Homebrew

#14

Post by ggm »

jmbwell wrote: post #10

With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.

For people who don't know, pkgsrc works fine on macOS, the complaint was well made: its not the default.

I use brew, and have used pkgsrc in the past. I could go back for low pain.

Re: Our audit of Homebrew

#16

Post by CaliforniaKarl »

jmbwell wrote: post #10

With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.

I've been using MacPorts for as long as I've wanted a macOS package manager, and it's been working very well for me.

Re: Our audit of Homebrew

#17

Post by paholg »

jmbwell wrote: post #10

With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.

When I've had to use a Mac, I've used nix to good success. I'm actually surprised how well it worked; I was able to basically just use the same config I use on Linux, removing just the few Linux-specific packages.

Re: Our audit of Homebrew

#18

Post by arprocter »

jmbwell wrote: post #10

With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.

It'd be nice if brew was a little more apt-y, and all the beer nomenclature is a bit silly

My first exposure to Mac package stuff was fink in the early aughts - compiling everything on a Pismo G3 was pretty slow going

Re: Our audit of Homebrew

#19

Post by greggsy »

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 source? How does the user gain confidence that their brew update is still referencing a trusted source? What happens when a domain is taken over? How quickly can the team respond to untrusted sources from formulas?

I know these aren’t all Homebrew problems to solve, but they’re important ecosystem considerations.

(These problems also exist in the winget and choco platforms, but less so in commercially supported repos like apt and yum. For me, and many other admins, they are a major concern when it comes to the Windows Store.)

Edit: lastly, in case the homebrew team are watching: an npm-style vulnerability notice would be awesome

Post reply on HN