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

161–170 of 205 posts

Re: Our audit of Homebrew

#161

Post by pmarreck »

bokchoi wrote: post #96
pmarreck wrote: post #52

I ditched `brew` for `nix` a while back and while the TUI could be more end-user-friendly (to the point that I wrote a wrapper called "ixnay" just so I could do "ixnay install " as easily as with brew, https://github.com/pmarreck/ixnay ), the overall guarantees make it worth it.

I also find the nix command line annoying. I'll give this a try. I like the embedded `#help` documentation!

The help thing works great but it's on the verge of being over-engineered lol

Helped that I'm good at regex lol

Re: Our audit of Homebrew

#162

Post by pmarreck »

Brian_K_White wrote: post #108
bokchoi wrote: post #96

Earlier quoted context omitted.

I also find the nix command line annoying. I'll give this a try. I like the embedded `#help` documentation!

So do I ;) I've had some form of `grep '^#h ' $0` in most of my scripts forever. This one is a purity stunt and doesn't use grep, or anything else: https://github.com/bkw777/pdd.sh (the script itself is of no use to you since it only talks to a piece of hardware) The command dispatcher case statement and all the embedded help is in do_cmd() at 2857, and the help reader is help() at 425 I like their explicit #args vs…

> It works but it feels kind of 70's or assembly.

I mean, this is basically all of Bash lol. A very clever idea that has endured since the 70's but also shows it... And yet we get obsessed with "writing perfect Bash" still.

The amazing thing is that there are also old "functional shells" like es-shell https://wryun.github.io/es-shell/ (he still works on this and it is indeed very interesting!)

Re: Our audit of Homebrew

#163

Post by rahen »

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 pkgin and pkgsrc for years on macOS. Occasionally, I still need a small brew prefix when a dependency is missing or difficult to build. Molten-vk was the last such package.

pkgsrc is by far the most KISS package manager for macOS, I like it.

Re: Our audit of Homebrew

#164

Post by mzs »

brandall10 wrote: post #44
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.

Anyone know why Homebrew overtook MacPorts? I only have a vague recollection of a Rails colleague pushing me to switch circa 2013 or so and haven't given it much thought since, but it (MacPorts) seemed to be similarly ubiquitous prior.

When you installed a port with macports the idea was to use as much of the macports for build and runtime dependencies. Over time that became greater and so port install would be slow until you built enough dependancies. It also consumed more storage.

When you installed a port with brew it used as much of the OSX, X11, and XCode installed utilities as possible so it was faster and used less storage. But then you would install an update from Apple and things would break cause of that reliance, things like /usr/bin/perl.

Re: Our audit of Homebrew

#165

Post by woodruffw »

wredue wrote: post #158
justusw wrote: post #82

Earlier quoted context omitted.

Funny that you mention it, I also went Homebrew -> MacPorts -> Nix. Homebrew had analytics and broke versions too often. MacPorts is way more stable, but some niche packages would not build well, and I had terminfo issues with tmux. Nix allows me to override most of that, and I can share home manager config with my Debian workstation.

For the life of me, I will never understand how developers, of all people, see “just take ownership of system directories, which we will relentlessly pollute” as acceptable behavior for homebrew. Flabbergasted.

I don't think this is a fair characterization: on Intel, Homebrew uses `/usr/local`, which Apple has (historically) left empty as a location for non-OS managed software to be placed. To my understanding, this is an artifact of macOS's partial BSD ancestry. On ARM-based Macs, Homebrew uses `/opt` to avoid even this confusion (a trait it shares with other non-OS software but administrative-type software).

On the other hand, if Homebrew used `/usr` by default, this would be a fair characterization. But it doesn't.

Re: Our audit of Homebrew

#166

Post by lionkor »

dotBen wrote: post #148
greggsy wrote: 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…

Ah yes, the "bad guys".

Re: Our audit of Homebrew

#167

Post by croemer »

Brian_K_White wrote: post #152
freep1zza wrote: post #92

Earlier quoted context omitted.

One should try to avoid using double negatives in both speech and programming to make intent more obvious ;-)

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?

Re: Our audit of Homebrew

#168

Post by 0xedd »

lionkor wrote: post #166
dotBen wrote: 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…

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 internet. /s

Re: Our audit of Homebrew

#169

Post by tadfisher »

koito17 wrote: post #71

Before moving to Nix, I was using MacPorts since Homebrew had some...eccentric behavior at the time (didn't work with multi-user setups, owned your /usr/local, lots of "works on my machine" problems from auto-updating and lack of version control, ...). One thing that has always felt insecure about Homebrew to me was the ability to use GitHub (not Git) URLs as ad-hoc packages. I wonder if that is how TOB-BREW-13 worke…

Nix doesn't sandbox builds by default on macOS. You can try enabling it yourself with `sandbox = true` in nix.conf, but Things May Break.

The Nix sandbox is also not really meant as a security boundary; there's no effort put into preventing sandbox escapes, and lots of stuff leaks from the host into the sandbox environment. You really want something like gVisor or a full VM if you want to build untrusted packages.

Post reply on HN