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

151–160 of 205 posts

Re: Our audit of Homebrew

#151

Post by replete »

mootoday wrote: post #140
charlie0 wrote: post #139

Earlier quoted context omitted.

As someone unfamiliar with Nix, how is this better than Homebrew?

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

Re: Our audit of Homebrew

#152

Post by Brian_K_White »

freep1zza wrote: post #92
luckman212 wrote: post #79

Earlier quoted context omitted.

My dumb brain had to read it 3 times before realizing that by saying "the findings were not inconsistent with what I'd expect" you meant "the findings _were_ consistent with what I'd expect"

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 concept that even the most aspbergers STEM head should be able to understand, is how a scientist almost never asserts anything unequivocally. Almost every statement is qualified with whatever is appropriate to the context. Even the most fundamental constants of the universe like the speed of light are famously relative. Are those scientists being more or less ambiguous when they decline to say something simple and direct?

Everything they don't say is deliberate and carefully crafted to be as correct as possible, not some sloppy ommission.

Re: Our audit of Homebrew

#153

Post by Bluecobra »

tucosan wrote: post #128

The main attack vector IMHO is the simple fact that one can sneak in new packages with malicious intent by simply contributing a new formula. The team of maintainers is too small to audit all of the newly contributed formulae. I'm suprised that this attack vector wasn't part of the audit.

Yeah, I just had a scare the other day with someone downloading a console emulator called "Cmder" which is a collection of a bunch of FOSS tools. It literally had ~1,000 files that could be malicious including powershell scripts, perl scripts, python scripts, shell scripts, DLLs, EXEs, etc. It turned out it was benign, but it's really scary that people just clone these Git repos and hope for the best.

Re: Our audit of Homebrew

#154

Post by Ferret7446 »

andruby wrote: post #118
leokennis wrote: post #116

Earlier quoted context omitted.

Can you supply supporting evidence (links etc.) regarding "the author was being extremely upset (...) about not passing a Google interview" and "Homebrew having... weird design decisions"?

(I'm not the other poster) They're probably referring to this tweet from Max Howell [0] > Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off. I personally wouldn't hold that against him (or Homebrew). We also don't really know if Google rejected him based on the binary tree, or if it was something else (personality?). [0] https://x.com/mx…

I had to dig it up, I'm talking about this.

https://www.reddit.com/r/google/comments/7l5ibp/max_howell_h...

Notably, Howell said:

> But ultimately, should Google have hired me? Yes, absolutely yes. I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like them. Surely, surely Google could have used that.

And a sensible response from Jonathan Blow to the "binary tree" nonsense:

> I hate to say it, but counter to most replies you are getting, I see this as an expected outcome. Inverting a binary tree is not some trick interview question. It's a very basic data structure manipulation, and the ideas involved there are applicable to everything. I probably wouldn't hire someone who couldn't solve this, either. It most likely indicates lack of comfort with (or understanding of) recursion, which is kind of serious. This is not to say that the hiring process is good (I have never experienced it) or that they shouldn't have hired you (quite possibly they should have) but maybe instead of getting mad, take this as a cue that you could build up your data-structure-manipulation muscles a bit more and become better for it -- as that stuff applies everywhere.

Re: Our audit of Homebrew

#155

Post by SOLAR_FIELDS »

Cloudef wrote: post #70
SOLAR_FIELDS wrote: post #41

Earlier quoted context omitted.

Do you not use many packages and only strictly use FOSS tooling? I have a large and growing list of packages that have to be managed in Homebrew still because the package is one of the following: 1. Not available at all in nixpkgs (e.g. Docker Desktop, BetterTouchTool, etc) 2. In nixpkgs, but completely broken or missing some architecture support (e.g. Firefox) 3. Actually available and somewhat functional in nixpkgs…

If you want graphical apps to be handled by nix on macos, you might be interested in https://github.com/BatteredBunny/brew-nix >. nixpkgs does not package macos sandboxed apps AFAIK, that means typically only cli utilities, libraries and development tools only work.

Tried this when it was released on HN. It does not work out of the box. There is some problem with launching apps from outside of the applications folder. The trampoline Mac-app-útil approach does not work. Though in theory it probably should for most applications. I don’t know enough about the code signing process to be able to debug what is wrong with it.

Re: Our audit of Homebrew

#156

Post by SOLAR_FIELDS »

pxc wrote: post #77
SOLAR_FIELDS wrote: post #41

Earlier quoted context omitted.

Do you not use many packages and only strictly use FOSS tooling? I have a large and growing list of packages that have to be managed in Homebrew still because the package is one of the following: 1. Not available at all in nixpkgs (e.g. Docker Desktop, BetterTouchTool, etc) 2. In nixpkgs, but completely broken or missing some architecture support (e.g. Firefox) 3. Actually available and somewhat functional in nixpkgs…

I recently tried out mac-app-util¹, which fixes some of the usual pain with GUI apps. In conjunction with brew-nix², it looks like it might be most of what I'll need to move away from having Nix manage Homebrew for me. I don't use very many GUI apps so now that the installation piece is taken care of, I can just package everything I use if it really comes down to it. That'd be worth it for me just to get rid of the p…

I tried this exact combination but it did not work out of the box for the apps I tried. For gui apps bundled with brew-nix they will panic due to something about how the code signing keys are copied with brew-nix. The Mac-app-util trampoline launcher does work with the regular way that brew is managed with nix (which under the hood just shells out to brew) though. So the problem is likely related to brew-nix installing apps outside of the Applications folder.

I hacked around a bit trying a few different approaches before giving up and switching back to the regular nix-Darwin homebrew approach. But the issue is probably solvable by someone who knows a lot more about how the code signing process works with Macs and the Applications folder

Re: Our audit of Homebrew

#157

Post by FireBeyond »

socksy wrote: post #111
lifty wrote: post #109

Earlier quoted context omitted.

Don’t you have to disable SIP to use nix on macOS?

No, see https://nix.dev/manual/nix/2.18/installation/installing-bina...

If there's any hope of Nix seeing widespread adoption as a Mac package manager, uh... this link kinda shoots it down a lot.

From that:

- create a new APFS volume for your Nix store

- update /etc/synthetic.conf to direct macOS to create a "synthetic" empty root directory to mount your volume - specify mount options for the volume in /etc/fstab: rw: read-write, noauto: prevent the system from auto-mounting the volume (so the LaunchDaemon mentioned below can control mounting it, and to avoid masking problems with that mounting service), nobrowse: prevent the Nix Store volume from showing up on your desktop; also keeps Spotlight from spending resources to index this volume

- if you have FileVault enabled: generate an encryption password, put it in your system Keychain, use it to encrypt the volume

- create a system LaunchDaemon to mount this volume early enough in the boot process to avoid problems loading or restoring any programs that need access to your Nix store

Even as someone who knows how to do all that... no thanks.

Re: Our audit of Homebrew

#158

Post by wredue »

justusw wrote: post #82
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…

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.

Re: Our audit of Homebrew

#159

Post by eduction »

azinman2 wrote: post #83
eduction wrote: post #61

Earlier quoted context omitted.

I did not know about the new directory practice, thanks. From what their site says it looks like it was done this way to keep ARM native stuff separate from old intel code which can still work under Rosetta. But I don't see any indication homebrew stopped linking system libraries as a matter of course (correct me if I'm wrong). MacPorts makes a point of not doing this. /opt/local is its own universe and dependencies…

I much rather them use system libraries than build parallel libs that don’t go through Apple’s vetting / changes. This has worked well for me in practice. I’ve actually never run into an issue where the system library got updated and that broke homebrew’s apps.

That seems like a totally valid perspective. Macports page I linked claims that Apple is often too slow to update, and in some cases only does so when there is a security breach. I can’t vouch for if that’s true. In my experiments maybe 10 yrs ago it took substantially longer for me to install a certain set of packages on Macports vs homebrew due to the parallel library thing. But I had had some broken packages with brew and found Macports more reliable.

Does seem like something Apple should fund / handle IMO.

Re: Our audit of Homebrew

#160

Post by pmarreck »

pyjamafish wrote: post #136
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 wish I had known about ixnay earlier! I also got annoyed of the user experience, to the point where I also wrote my own tool, hdn: https://github.com/seasonedfish/hdn I added a mention of ixnay to its readme :)

Thanks for the mention!

I just noticed there's a bug with uninstalling. Probably a parsing issue, they must have changed the output of nix for that (this isn't the first time that happened...)

Post reply on HN