Our audit of Homebrew

Original Article ↗ Hacker News Discussion ↗

An independent security audit of the Homebrew package manager for macOS and Linux found issues that are broadly in line with what reviewers would expect from a large userspace package manager, and most have been addressed by the project. Commenters use the findings to revisit long‑running debates about Homebrew’s design choices, security model, and filesystem behavior compared with alternatives like MacPorts, Nix, and pkgsrc. Many also highlight broader software supply-chain risks in community-run packaging ecosystems, arguing that processes for vetting formulas, signing artifacts, and handling third‑party contributions remain a critical but under-addressed attack surface.

Scope and nature of the audit

  • Audit used internal IDs like TOB‑BREW‑n (Trail of Bits + product + counter) rather than CVEs.
  • Auditor characterizes Homebrew’s issues as roughly what would be expected for a large userspace package manager that ships its own binaries.
  • Clarification later in thread that the auditor was not a Homebrew maintainer during the audit, but is one now; this was disclosed as a conflict of interest internally.

Security findings and fixes

  • Discussion of a sandbox escape fix where path characters are blacklisted before interpolation into a sandbox profile; several commenters question whether a whitelist would be safer and criticize the minimal commit message.
  • Some are surprised supply‑chain/process risks (e.g., malicious new formulas, maintainer compromise) weren’t a major focus; the report explicitly assumed formulas are trustworthy.
  • A long critique argues Homebrew’s supply‑chain integrity is weak vs. major Linux/BSD distros: limited signing, lack of reproducible builds and strict 2FA, heavy reliance on many maintainers’ GitHub security, and automated tools like Dependabot.
  • Others emphasize that attack surface from ecosystems (e.g., compromised upstream packages, PR access) is a broad problem beyond Homebrew.

Homebrew vs. other macOS package managers

  • Many users compare Homebrew with MacPorts, pkgsrc, Nix, and Devbox.
  • Pro‑Homebrew comments: larger and fresher package set, simpler UX, reusing system toolchain originally made it faster and lighter, became the de facto standard and widely referenced in docs.
  • Pro‑MacPorts/pkgsrc comments: separate tree under /opt, less dependence on Apple’s changing system libs, more conservative/upgradable in place, variants and selectors for feature tuning, perceived better Unix “hygiene.”
  • Several describe switching Homebrew → MacPorts → Nix as they prioritized reproducibility and isolation over convenience.

Nix, Devbox, and GUI app challenges

  • Nix is praised for reproducibility and sharing configs across macOS/Linux, but its CLI and installation are seen as intimidating; Devbox is mentioned as a friendlier Nix front‑end.
  • On macOS, Nix struggles with GUI apps needing code signing, SIP, and /Applications placement; workarounds (brew‑nix, mac‑app‑util) are promising but fragile, especially for apps like 1Password, Docker Desktop, and complex launchd integrations.
  • Nix’s sandboxing on macOS is not enabled by default and is not treated as a strong security boundary.

Design, communication, and Apple’s role

  • Debate over Homebrew’s design history: use of /usr/local, hard‑coded paths, and taking ownership of system‑adjacent directories are criticized; maintainers defend /usr/local as the traditional non‑OS prefix and note the ARM move to /opt/homebrew.
  • Some wish Apple had built and funded a first‑party package manager (or audited Homebrew themselves); others fear an Apple solution would be heavyweight or too iOS‑like.
  • Side discussion on ambiguous wording (“not inconsistent”) and the value/risks of deliberate ambiguity in technical communication.