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

31–40 of 205 posts

Re: Our audit of Homebrew

#31

Post by chatmasta »

cqqxo4zV46cp wrote: post #6
bagels wrote: post #5

Earlier quoted context omitted.

In the case of Watchman, I have to assume that internal use is the most supported use case, and uniformity of deployment is desirable across the fleet there, and so, configurability wasn't as big of a concern?

My short experience with Watchman (a few years ago) indicates this. It’s pretty clearly only technically open-source, without much regard at all paid to third parties actually using it.

I’ve had a few build pipelines break over the years because of a watchman dependency. IIRC it was usually an issue with an npm library depending on watchman but downloading a binary that was incompatible with the architecture or implemented the wrong syscalls for the operating system.

Re: Our audit of Homebrew

#32

Post by 8b16380d »

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.

Just use pkgsrc or macports. IMO way easier and less intrusive than homebrew.

Re: Our audit of Homebrew

#33

Post by paradox460 »

user3939382 wrote: post #21

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

I keep ports around for things like lilypond (which I use for quasi-professional score engraving) and some other packages that homebrew is weird on. The removal of options a few years back still stinks for be

Re: Our audit of Homebrew

#34

Post by nightpool »

apitman wrote: post #9
bagels wrote: post #5

Earlier quoted context omitted.

In the case of Watchman, I have to assume that internal use is the most supported use case, and uniformity of deployment is desirable across the fleet there, and so, configurability wasn't as big of a concern?

That makes sense. The weird part to me is that Homebrew would limit their approach and eliminate an entire class of use cases to accommodate programs that work this way. There has to be more to it.

I don't think that's accurate—homebrew specifically says that it only uses the .linuxbrew directory when a formula contains a hardcoded path (which it scans for), and only if you choose not to install it from source.

So, based on the responses from the maintainers, for the .linuxbrew directory to be used, you have to satisfy 2 conditions:

1. you have to be installing one of the ~10% of formula that isn't trivially relocatable.

2. you have to be using a precompiled binary (which it seems like homebrew is smart enough to not do if condition #1 fails and you're not using sudo)

Re: Our audit of Homebrew

#35

Post by throwaway290 »

nsagent wrote: post #29
CaliforniaKarl wrote: post #16

Earlier quoted context omitted.

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.

Yeah, I switched from Homebrew to MacPorts a few years ago and couldn't be happier.

Same here.

Re: Our audit of Homebrew

#37

Post by wwalexander »

CaliforniaKarl wrote: post #16
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.

MacPorts is awesome. The PortGroups also make it super easy to make new packages.

Re: Our audit of Homebrew

#38

Post by jonahx »

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

I cannot reply to your top comment for some reason, so asking here:

What is your personal recommendation for Mac users? Would you suggest a different package manager and, if so, which?

Post reply on HN