Hacker News Reader

Comment by koito17 | Hacker News Reader

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 worked? That feature of Homebrew has always sounded like a security incident waiting to happen.

In any case, I'd be interested in seeing an audit of Nix on Mac OS. Especially if there is a flaw in how `nix develop` and related commands work.

View on HN

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.

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

The really shameful behaviour at the time was that if you changed it (which you theorically could), some packages were so poorly written than they just broke and homebrew just warned you it was going to be this way instead of actually fixing the issue.

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.

Nix also allows github.

Sure, Nix is extremely flexible in input definition, but it's different in the sense that Homebrew exposes a single command to e.g. install a cask from a user-inputted GitHub repository. So all an attacker needs to do is typo squat or take control of the GitHub repository that people are using to install a certain cask.

In Nix, flakes are pure functions and run in pure evaluation mode. One needs to consciously add a Git repository (URL + commit hash, branch, or tag) and then make use of something malicious exported by the input. But to find out what the flake exposes at all, reading the flake (or its documentation) is pretty much necessary.

All the Nix commands that take an 'installable' can take GitHub URLs. For instance:

    $ nix run github:NixOS/nixpkgs#hello
    Hello world!

That command will download nixpkgs from GitHub, evaluate the `hello` flake attribute, build it (or download it from a cache), and run it.

> But to find out what the flake exposes at all, reading the flake (or its documentation) is pretty much necessary.

If the flake exposes default packages or apps, then you do not need to provide a flake attribute:

    $ nix run github:NixOS/nixpkgs
    error: flake 'github:NixOS/nixpkgs' does not provide attribute 'apps.aarch64-darwin.default', 'defaultApp.aarch64-darwin', 'packages.aarch64-darwin.default' or 'defaultPackage.aarch64-darwin'

So you can run e.g. Alejandra [1], a Nix formatter, like so:

    $ nix run github:kamadorueda/alejandra

[1]: https://github.com/kamadorueda/alejandra

EDIT: For what it's worth, I think this feature can be useful sometimes, but it does also suffer from the same typosquatting problems as we see in other ecosystems.

Reply on news.ycombinator.com