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

171–180 of 205 posts

Re: Our audit of Homebrew

#171

Post by Cloudef »

FireBeyond wrote: post #157
socksy wrote: post #111

Earlier quoted context omitted.

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 (…

The installer does it all for you. Theres even graphical installer https://determinate.systems/posts/graphical-nix-installer/

Re: Our audit of Homebrew

#172

Post by pxc »

SOLAR_FIELDS wrote: post #156
pxc wrote: post #77

Earlier quoted context omitted.

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 installi…

Ugh! How annoying. Which apps did you try that with? I just gave it a try with a couple random ones. I tried Marta, CyberDuck, IINA, KeePassXC, and CotEditor and they all worked.

(Spotify didn't build because the Brew package doesn't have a hash, and Karabiner Elements didn't build bc idk why, but that's actually in Nixpkgs already and that version works fine.)

I did double-check that I have SIP enabled and everything. I'd be interested in trying to repro!

Aside: that mac-app-util works so nicely for the macOS apps that are already in Nixpkgs makes it feel much more worth it to me to package GUI apps for macOS, if that'll mean I can get rid of `brew` entirely. I wonder if this will spur others to also package more GUI apps this way.

Re: Our audit of Homebrew

#173

Post by SOLAR_FIELDS »

pxc wrote: post #172
SOLAR_FIELDS wrote: post #156

Earlier quoted context omitted.

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 installi…

Ugh! How annoying. Which apps did you try that with? I just gave it a try with a couple random ones. I tried Marta, CyberDuck, IINA, KeePassXC, and CotEditor and they all worked. (Spotify didn't build because the Brew package doesn't have a hash, and Karabiner Elements didn't build bc idk why, but that's actually in Nixpkgs already and that version works fine.) I did double-check that I have SIP enabled and everythin…

1Password and docker desktop are two good test subjects. 1Password especially is the one I mentioned above as being a problem child in general with nix setups on Mac

VScode in particular was the one that broke for me, though that is actually available and mostly functional in nixpkgs so that one is not a showstopper.but might be a good test case to repro

Re: Our audit of Homebrew

#174

Post by alanbernstein »

croemer wrote: post #167
Brian_K_White wrote: post #152

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?

Perhaps they're thinking of how it's dependent on the transmission material?

Re: Our audit of Homebrew

#175

Post by KolenCh »

woodruffw wrote: post #165
wredue wrote: post #158

Earlier quoted context omitted.

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…

But the problem is that /usr/local/bin is in the default PATH. They defended this discussion to take over until Apple silicon came and they “silently” fixed it avoiding admitting anything wrong in the beginning

Re: Our audit of Homebrew

#176

Post by KolenCh »

charlie0 wrote: post #139
mootoday wrote: post #138

There's an interesting alternative to Homebrew: Devbox It abstracts Nix in a way you don't have to know or learn anything about the Nix language. I wrote a few words on how I use it instead of Homebrew [1]. [1] https://mootoday.com/blog/i-replaced-homebrew-with-devbox https://mootoday.com/blog/i-replaced-homebrew-with-devbox

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

You might say devbox gives nix a brew-like interface and ergonomic.

More accurately, when you use a package manager, you use the “ecosystem” including the package index and pre-built binaries, and the cli. There aren’t many alternatives to homebrew as an ecosystem, especially including cask. Macports isn’t a homebrew replacement in the sense that it doesn’t have “cask”. Nix has something similar, although not as many packages. This makes nix probably the only viable alternative to homebrew with cask.

But nix is very hard to onboard. Devbox just makes it much easier to start using in say the first 30 min.

Re: Our audit of Homebrew

#177

Post by KolenCh »

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…

This a not a unique problem to homebrew. Any pre-built binaries potentially shares this problem unless the build system the software use is intentionally written to avoid this problems.

Any package managers that is designed to not hard code the prefix, ie you can choose where the binaries go into, needs to handle this problem and have their own ways to deal with it. Conda for example has a long string of …placehold_placehold_… to facilitate editing the hardcoded path…

Source distribution is more robust against this problem comparing to binary distribution. (But sometimes the authors of the software did not package them well and would have hardcoded some paths somewhere.)

That’s why when you change the homebrew prefix, they will built from source instead, and it (using a different prefix) might not work.

Re: Our audit of Homebrew

#178

Post by woodruffw »

KolenCh wrote: post #175
woodruffw wrote: post #165

Earlier quoted context omitted.

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…

But the problem is that /usr/local/bin is in the default PATH. They defended this discussion to take over until Apple silicon came and they “silently” fixed it avoiding admitting anything wrong in the beginning

I don’t really understand what the problem you’re referring to is: /usr/local is explicitly the non-OS software hierarchy, which is why Homebrew used it. When Apple Silicon came out, the prefix was changed as part of allowing native and Rosetta-driven Homebrew installations to co-exist. There’s no nefarious reasoning behind it.

Edit: a thread with a bit of the history can be found here[1].

[1]: https://github.com/Homebrew/brew/issues/9177

Re: Our audit of Homebrew

#179

Post by greggsy »

azurezyq wrote: post #150
brimwats wrote: post #149

Earlier quoted context omitted.

> enough publicized cases of Chinese CCP operatives gaining Like? not doubting you, just not aware of multiple cases beyond the big near-miss earlier this year

Also for that case, I don't think we have any clue who the guy is. Name just not meaning anything. Or anyone has any link to a formal trace to the origin?

It was a well organised operation. I don’t believe we’ll ever know. It likely wasn’t even one person.

Re: Our audit of Homebrew

#180

Post by pxc »

SOLAR_FIELDS wrote: post #173
pxc wrote: post #172

Earlier quoted context omitted.

Ugh! How annoying. Which apps did you try that with? I just gave it a try with a couple random ones. I tried Marta, CyberDuck, IINA, KeePassXC, and CotEditor and they all worked. (Spotify didn't build because the Brew package doesn't have a hash, and Karabiner Elements didn't build bc idk why, but that's actually in Nixpkgs already and that version works fine.) I did double-check that I have SIP enabled and everythin…

1Password and docker desktop are two good test subjects. 1Password especially is the one I mentioned above as being a problem child in general with nix setups on Mac VScode in particular was the one that broke for me, though that is actually available and mostly functional in nixpkgs so that one is not a showstopper.but might be a good test case to repro

I just tried 1Password and it refused to start not being in `/Applications`. I've seen this happen with one other app (Secretive), although it doesn't quite refuse to run. I can't remember all the details, but I think it has to do with a limitation in newer versions of macOS, where apps that try to register launchd services can only do so if they live in /Applications rather than ~/Applications. The problem with launching those background services from binaries that live in ~/Applications disappears if you disable SIP. When I first encountered it, it made me wonder if ~/Applications is not really supported on modern macOS. I wish I could find the issue for that but I didn't, when I looked just now. :-\

Oh, here's that issue: https://github.com/maxgoedjen/secretive/issues/77

1Password definitely acts weird for me, to where I kind of wonder if the .app folder is malformed somehow. The version installed in the Nix store actually works fine-- but not if I double-click it or open it with the `open` command. In that case it kinda acts like something is going to launch but then it never comes up. But if I manually invoke `/Applications/Nix\ Apps/1Password.app/Contents/MacOS/1Password` from my terminal, it starts up fine! But when I directly launch that executable from Finder, the application does not start and I see that same message about not living in /Applications printed in the terminal. Idk why 1Password refuses to run from anywhere other than /Applications but that seems to be it's message rather than the operating system's.

It's a shame 1Password's Mac app can't run from the Nix store. They clearly have at least one Nixer at the company because they have cool integrations like this:

https://developer.1password.com/docs/cli/shell-plugins/nix/

I couldn't even get the Docker Desktop package to build from `brew-nix`. OrbStack in the Nix store died on signature errors, but when I visited Security & Privacy in System Preferences after that, there was a little notice that OrbStack had been blocked from running because it was from an unrecognized developer, with the option to allow it. After being allowed, it seemed to work as normal. Same for Podman Desktop.

Why do the signatures for those apps end up getting replaced with this setup anyway?

Post reply on HN