9 ms·

Our audit of Homebrew

845 points by zdw 2y ago

amai 2y ago
Nowadays even Windows has a package manager (https://en.wikipedia.org/wiki/Windows_Package_Manager https://en.wikipedia.org/wiki/Windows_Package_Manager). Why does Apple/Mac OS X not develop something similar?
yjftsjthsd-h 2y ago
There's a bunch of TOB-BREW-n listed - are those like CVE numbers just for this project? Edit: Oh, it's "Trail Of Bits - homeBREW". But probably still yes.
- woodruffw 2y ago
  Yep. We use the TOB-$PRODUCT-$XXXX convention for our audit findings, where $PRODUCT is the target under audit and $XXXX is a unique incrementing counter for each finding. (As far as I know, a lot of audit firms do similar things.)
  - Alifatisk 2y ago
    First time seeing TOB being used honestly, it would’ve helped saying something along the lines of ”Trait of Bits (TOB from now on)”
    - RulerOf 2y ago
      Other companies do similar things. Red Hat creates RHSA-YYYY:XXXX for example, like this one for Log4Shell: https://access.redhat.com/errata/RHSA-2022:0442 https://access.redhat.com/errata/RHSA-2022:0442
  - jonahx 2y ago
    I cannot reply to your top comment for some reason, so asking here: What is your personal recommendation for Mac users? Would you suggest a different package manager and, if so, which?
    - woodruffw 2y ago
      Given that I did the audit, I don’t think it’s appropriate for me to offer an endorsement (or a negative endorsement) in this context. What I’ll say is this: the findings on Homebrew were not inconsistent with what I’d expect to find on any similarly sized userspace package manager that serves its own binary builds.
      - luckman212 2y ago
        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"
        freep1zza 2y ago
        One should try to avoid using double negatives in both speech and programming to make intent more obvious ;-)
        gorlilla 2y ago
        Except the ambiguity was the intent.
        Brian_K_White 2y ago
        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.
  - MARION_787 2y ago
    [flagged]
  - MARION_787 2y ago
    [flagged]
  - MARION_787 2y ago
    [flagged]
  - MARION_787 2y ago
    [flagged]
  - MARION_787 2y ago
    [flagged]
  - MARION_787 2y ago
    [flagged]
apitman 2y ago
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 would break if not run this way: Facebook's Watchman[1]. It bizarrely (to me) has hard coded paths compiled into it, which force you to run it from specific directories. Would love to understand what's going on here and why you would ever make software work this way. I feel I'm missing a fairly obvious Chesterton's Fence. [0]: https://github.com/orgs/Homebrew/discussions/5371 https://github.com/orgs/Homebrew/discussions/5371 [1]: https://facebook.github.io/watchman/docs/install#prebuilt-binaries-2 https://facebook.github.io/watchman/docs/install#prebuilt-bi...
- bagels 2y ago
  In the case of Watchman, I have to assume that internal use is the most supported use case, and uniformity of deployment is desirable across the fleet there, and so, configurability wasn't as big of a concern?
  - cqqxo4zV46cp 2y ago
    My short experience with Watchman (a few years ago) indicates this. It’s pretty clearly only technically open-source, without much regard at all paid to third parties actually using it.
    - chatmasta 2y ago
      I’ve had a few build pipelines break over the years because of a watchman dependency. IIRC it was usually an issue with an npm library depending on watchman but downloading a binary that was incompatible with the architecture or implemented the wrong syscalls for the operating system.
  - apitman 2y ago
    That makes sense. The weird part to me is that Homebrew would limit their approach and eliminate an entire class of use cases to accommodate programs that work this way. There has to be more to it.
woodruffw 2y ago
I'm the author of this post and one of the people behind the audit; happy to answer questions about it. If you're having trouble finding the audit itself (it's linked indirectly), I'm linking a copy here as well[1]. [1]: https://github.com/trailofbits/publications/blob/eb9344f2261031a4be1be2f223e9b5bc535be6b9/reviews/2023-08-28-homebrew-securityreview.pdf https://github.com/trailofbits/publications/blob/eb9344f2261...
jmbwell 2y ago
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.
- deleted 2y ago
  [deleted]
- ggm 2y ago
  For people who don't know, pkgsrc works fine on macOS, the complaint was well made: its not the default. I use brew, and have used pkgsrc in the past. I could go back for low pain.
- arprocter 2y ago
  It'd be nice if brew was a little more apt-y, and all the beer nomenclature is a bit silly My first exposure to Mac package stuff was fink in the early aughts - compiling everything on a Pismo G3 was pretty slow going
  - jonhohle 2y ago
    Switch to MacPorts. It supports precompiled packages, doesn’t take over the world and force anything on you the same way Homebrew does. I’m really disappointed in how Homebrew took a lot of attention away from the existing package managers, made a bunch of terrible decisions related to packaging and flexibility and genera Unix philosophy, and then ate the world. : shakes fist at clouds, get off my lawn
- CaliforniaKarl 2y ago
  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.
  - nsagent 2y ago
    Yeah, I switched from Homebrew to MacPorts a few years ago and couldn't be happier.
user3939382 2y ago
I’m still good on MacPorts. Seems I’m alone these days. Works fine for me.
- 8b16380d 2y ago
  Nah I’ve been on macports for years now. No problems; the community is very active, just follow the mailing lists etc
- deleted 2y ago
  [deleted]
- bdangubic 2y ago
  honebrew works too :)
- paradox460 2y ago
  I keep ports around for things like lilypond (which I use for quasi-professional score engraving) and some other packages that homebrew is weird on. The removal of options a few years back still stinks for be
- wwalexander 2y ago
  There are dozens of us!
- blt 2y ago
  I got sick of Homebrew after a while and tried switching to MacPorts, but it feels like an endless uphill battle when so many packages only offer source and Homebrew distributions.
- pxc 2y ago
  I mostly just use Nix, but I also have pkgsrc, MacPorts, and (kinda) Homebrew installed on my Mac. The only ones with any CLI tools installed, though, are Nix and pkgsrc.
- _0xdd 2y ago
  You are not. I've been using MacPorts for 15+ years at this point. Started with fink and then made the switch around the days of Snow Leopard. I'm also a BSD user, so no surprise there. I enjoy being able to compile ports with non-standard variants (e.g., non-free codecs in ffmpeg, removing un-needed interpreters from packages, etc.)
alxmdev 2y ago
[flagged]
- trav4225 2y ago
  Hah! IIRC, it was a binary tree of some sort.
- deleted 2y ago
  [deleted]
neverrroot 2y ago
Not surprised to see some problems. Still sad to see security take a backseat as opposed to convenience.
greggsy 2y ago
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 source? How does the user gain confidence that their brew update is still referencing a trusted source? What happens when a domain is taken over? How quickly can the team respond to untrusted sources from formulas? I know these aren’t all Homebrew problems to solve, but they’re important ecosystem considerations. (These problems also exist in the winget and choco platforms, but less so in commercially supported repos like apt and yum. For me, and many other admins, they are a major concern when it comes to the Windows Store.) Edit: lastly, in case the homebrew team are watching: an npm-style vulnerability notice would be awesome
- dotBen 2y ago
  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 known individuals is of course worrying. As a SWE/EngMgr turned VC, I'm curious if there's startups or commercial companies providing some kind of assurance here (but also worried the $ TAM for solving this problem probably isn't enough to make it a standalone business).
  - brimwats 2y ago
    > 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
    - azurezyq 2y ago
      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?
deleted 2y ago
[deleted]
scovetta 2y ago
Well done! And thank you to the Open Tech Fund for sponsoring work to protect everyone who uses Homebrew.
marxisttemp 2y ago
MacPorts is always waiting for you with more packages, a better design, and Jordan Hubbard’s history with BSD/Apple :)
- jagged-chisel 2y ago
  so many projects release only formulas for homebrew. I keep both and try to use McPorts first.
  - ggm 2y ago
    Most homebrew users started in macports, or fink. Very few I talk to (admittedly not many and curmugeons) want to go back.
    - eduction 2y ago
      Key difference is Mac ports keeps its tree separate in /opt. This means things take longer initially to install because it can’t just leverage system stuff already there. Upside is greater reliability because it doesn’t have to worry about a system update changing its dependencies. I prefer the greater reliability of macports.
      - parhamn 2y ago
        > Key difference is Mac ports keeps its tree separate in /opt What do you mean by this? brew has been linking from /opt/homebrew for years now.
        ggm 2y ago
        The person you're responding to may have been using homebrew on Intel. It's been in /opt on ARM since inception on ARM.
        eduction 2y ago
        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 can be upgraded more or less aggressively than Apple's. https://trac.macports.org/wiki/FAQ#syslibs https://trac.macports.org/wiki/FAQ#syslibs
pmarreck 2y ago
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 <packagename>" as easily as with brew, https://github.com/pmarreck/ixnay https://github.com/pmarreck/ixnay), the overall guarantees make it worth it.
- bokchoi 2y ago
  I also find the nix command line annoying. I'll give this a try. I like the embedded `#help` documentation!
  - Brian_K_White 2y ago
    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 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 #help One jank in mine is I have a verbosity level setting which affects most messages, and help() uses it to filter some of the help. Normal verbosity shows only the normal help for the normal commands. If verbosity is set higher, then help() shows more commands. The way that's implimented in help() is extra comments that change the behavior of help() as it's scanning the file from top to bottom. When it hits a '#v 2' it starts only displaying the help if the user has currently set verbosity>=2 until further notice. Later down the file it hits a '#v 1' and starts displaying help again... It works but it feels kind of 70's or assembly. #v 1 #h normal help for mortals #h ... #v 2 #h don't confuse the simple folk with this dangerous powerful stuff... #h ... #v 1 #h a few more normal commands #h ... #v 0 #h display this even the user has set verbosity to 0 to request silence #h ...
    - pmarreck 2y ago
      > 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/ https://wryun.github.io/es-shell/ (he still works on this and it is indeed very interesting!)
arandomhuman 2y ago
If macs supported PKGBUILDs like Pacman with a similar level of performance and there were correctly maintained packages for core programs I'd feel like using a mac would have a lot less compromises for convenience. Homebrew is great and the formulae are maintained really well but the simplicity of PKGBUILDS, the fast syncing, and lack of cognitive burden of recalling multiple arguments/flags for package managers make me wish pacman just worked on macs.
- pxc 2y ago
  There have been a few attempts at this. I think some of them may even be working.
- megamix 2y ago
  Is MacPorts not the same? Genuinely asking.
  - sirn 2y ago
    The concept is the same (given a definition file, build a package from a central repo, aka ports-like), but one of the features of PKGBUILD has is that it's easy to build an ad-hoc package outside the main tree. For example, you can download a bundle of PKGBUILD and `makepkg` in any directory to build a package. In other ports-like build systems, this can be a bit more complicated. For example, MacPorts allows you to use a local repository, but it requires configuring that local repository in `/opt/local/etc/macports/sources.conf` and `portindex` it beforehand before MacPorts could pick it up. Some others don't support building out of the main tree at all. Personally, out of all ports-like building systems, I like MacPorts' Portfile the most. It's similar to FreeBSD Ports' BSD Makefile (MacPorts was created by Jordan Hubbard who also co-created FreeBSD Ports) but using DSL via Tcl interp instead of being a shell script (POSIX shell in the case of Alpine's APKBUILD, bash in the case of others). From my experience, the syntax is very nice to work with, though you need to know a bit of Tcl for a non-trivial package.
- izik 2y ago
  The vanilla pacman will not work on macos as expected but there are attempts [1],[2] to make it works with some modifications/hacks. [1] https://github.com/liudongmiao/pacman https://github.com/liudongmiao/pacman [2] https://github.com/kladd/pacman-osx https://github.com/kladd/pacman-osx
nothrowaways 2y ago
Apple should have been the one funding the audit.
- CydeWeys 2y ago
  Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.
  - rurban 2y ago
    Apple would certainly favor macports over that rubbish ruby thing. Ports are from FreeBSD, MacOS is from FreeBSD.
    - pxc 2y ago
      Then why did Apple hire the creator of Homebrew to work on the package manager for Swift?
      - saagarjha 2y ago
        You should read https://en.wikipedia.org/wiki/MacPorts#History https://en.wikipedia.org/wiki/MacPorts#History. But to answer your question: why not? Apple employs thousands of software engineers.
    - dewey 2y ago
      No need to call someone’s free open source project “rubbish”.
    - latexr 2y ago
      That is provably false from so many angles. * Apple has no aversion to Ruby, and on the contrary has multiple developers pushing for it. They themselves had MacRuby, a project that allowed one to create Mac OS X (at the time) applications with Ruby.¹ * The reason there’s even an Xcode command line tools package available officially from Apple is because of Homebrew. A third-party made it first by extracting the necessary bits and then Apple officially supported it.² * There’s a liaison between Homebrew and Apple, who helped during the Intel to Apple Silicon transition.³ ¹ https://web.archive.org/web/20100908131627/http://developer.apple.com:80/mac/articles/scriptingautomation/cocoaappswithmacruby.html https://web.archive.org/web/20100908131627/http://developer.... ² I know this from a reliable source and it is public information, but it was so long ago it’s hard to find. ³ The official Homebrew Twitter account tweeted about this at the time. I no longer have a Twitter account so can’t dig it up.
sohrob 2y ago
Great that there are people looking into this. I wonder if there would be similar findings were they to perform an audit on MacPorts or the Nix package manager.
eddyg 2y ago
Any idea how much impact the audit has and/or applies to Workbrew[0], their new business-oriented MDM-manageable package tool? [0] https://workbrew.com/ https://workbrew.com/
- mikemcquaid 2y ago
  Workbrew wraps a vanilla, unmodified Homebrew on Macs running it under a ‘workbrew’ user for user privilege separation and better multi-user support.
KennyBlanken 2y ago
[flagged]
- mrpippy 2y ago
  On Apple Silicon Macs, Homebrew installs in /opt/homebrew.
- deleted 2y ago
  [deleted]
koito17 2y ago
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.
- justusw 2y ago
  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.
  - wredue 2y ago
    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.
    - woodruffw 2y ago
      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.
      - 2y ago
efitz 2y ago
Were the reported issues all addressed by the Homebrew maintainers or are any still unmitigated?
- zargon 2y ago
  https://brew.sh/2024/07/30/homebrew-security-audit/ https://brew.sh/2024/07/30/homebrew-security-audit/
razodactyl 2y ago
The amount of value returned to the Apple ecosystem through brew is remarkable and while this post makes me even more in awe of the care that goes towards the community, I'm sad that one of the richest companies in the world isn't giving more back.
- deleted 2y ago
  [deleted]
saagarjha 2y ago
I peeked at the sandbox escape bug and its associated fix: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c716585b072b5a401602f7847272ae5d4a https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7.... Is this…correct? Like, this is to prevent it from being interpolated into a sandbox profile and messing things up. How confident are we about this list of characters?
- js2 2y ago
  The commit message could have answered that question, but instead, it only repeats what the diff already tells us: "Don't allow special characters in sandbox rule paths". It doesn't explain why, or what's special about the particular characters that it disallows. A better message would have said something like "Prevent certain characters in the path because otherwise ... We need to worry about these specific characters but not others because..." Even if I wrote this code and knew what it did today, if I come across this it a year from now, I'm left scratching my head: why did I make this change? A real world example of a good commit message: https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce988d6b7936a9765a https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce98...
- frenchman99 2y ago
  Surprised too, if that is the fix. Wouldnt a whitelist be better than a blacklist?
Ferret7446 2y ago
[flagged]
- leokennis 2y ago
  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"?
  - andruby 2y ago
    (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/mxcl/status/608682016205344768 https://x.com/mxcl/status/608682016205344768 [1] https://news.ycombinator.com/item?id=15713801 https://news.ycombinator.com/item?id=15713801
    - latexr 2y ago
      > I personally wouldn't hold that against him (or Homebrew). No one should hold that against Homebrew. Max was already not part of it when that happened and he does not speak for the remaining team.
    - Ferret7446 2y ago
      I had to dig it up, I'm talking about this. https://www.reddit.com/r/google/comments/7l5ibp/max_howell_homebrew_creater_finally_opens_up_on/ 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.
tucosan 2y ago
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.
- j16sdiz 2y ago
  They noted that and just assume formulae are trustworthy. > ... These avenues do not necessarily violate Homebrew’s core security assumptions (which assume trustworthy formulae),...
- woodruffw 2y ago
  I don’t think the current Homebrew core formulae reviewers consider their team too small to sufficiently review all new incoming formula requests. But even if it was: this is one of the vagaries of packaging that’s explicitly called out in the post: the boundary between first- and third-party execution is inherently murky, and there’s IMO relatively more security “value” in determining where third-party execution can surprisingly happen than pointing out all of the unsurprising things that happen when you intentionally run third-party code. (With that being said, I think packagaging ecosystems in general should be reviewed for those kinds of acceptance processes. But that would be closer to a “red team” style audit than a software audit, since it’s about human processes.)
- Bluecobra 2y ago
  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.
hk__2 2y ago
I’m a bit puzzled by the wording of this blog post, because it says you’ve worked with Homebrew to do this audit, but your name sounds familiar to me, and indeed if we check Homebrew’s README [1]: > Homebrew's maintainers are […long list of names…] William Woodruff […] [1]: https://github.com/Homebrew/brew https://github.com/Homebrew/brew Is there any reason this is not mentioned in the blog post? I don’t think it would make a difference, but just to clarify things.
- woodruffw 2y ago
  I wasn’t a maintainer at the time I did the audit :-). I’ve been a non-maintaining “member” of the project for a long time, which is the pseudo-emeritus position we give to previous maintainers who want to continue participating in internal conversations and governance. I was then offered membership again, months after the audit, due to some unrelated work on Homebrew that didn’t exist and wasn’t planned before the audit was planned. This was all disclosed as part of a conflict-of-interest disclosure I did, both with my company and with the Homebrew maintainers, but I agree that the blog post could also say that explicitly. I’ll try and get it added today. TL;DR: I was not a maintainer at the time the audit was performed, but I was previously (years before) and am currently a maintainer. The audit was performed by myself and my colleagues in our professional capacities.
  - hk__2 2y ago
    Thank you!
  - Ylpertnodi 2y ago
    Why, oh why....are TL;DR's at the end of articles/ comments?
mootoday 2y ago
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 https://mootoday.com/blog/i-replaced-homebrew-with-devbox https://mootoday.com/blog/i-replaced-homebrew-with-devbox
- charlie0 2y ago
  As someone unfamiliar with Nix, how is this better than Homebrew?
  - mootoday 2y ago
    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 <repo>` to persist my config in a repo.
    - replete 2y ago
      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
      - mootoday 2y ago
        I had done the same before I learned about Devbox. It's very lightweight and gets very powerful combined with `git worktree` to work on multiple branches in parallel, each with its own database instance.
  - KolenCh 2y ago
    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.
alberth 2y ago
> Since 2012, Trail of Bits has helped secure some of the world’s most targeted organizations and products. We combine high-end security research with a real world attacker mentality to reduce risk and fortify code. It's interesting that I don't see any analysis referencing OpenBSD (either as a product or as an alternative to something else they have done research on).
mysore 2y ago
[flagged]
daghamm 2y ago
Kinda off topic, but when I see a project or an article use brew on Linux instead of their native package manager or something like flatpak I generally assume the author has very limited knowledge about Linux and I can ignore this project/article.
- Hackbraten 2y ago
  Even though Homebrew isn’t meant as a replacement for the system package manager, there are legitimate use cases. For example, if you’re on Debian but need a newer version of just one tool, it makes absolute sense to install Homebrew alongside. It’s designed to play well with the system package manager, uses its own separate prefix so it won’t cause shared libs confusion, and only shadows the packages you install with it. Nothing wrong with that inherently, and certainly not a sign of limited knowledge.
  - daghamm 2y ago
    I don't see that. Brew on Linux is a copy of dito on osx which itself was inspired by Linux package managers. Instead of using the real deal, people generally suggest Brew because that's what they are familiar with from osx. If you need bleeding edge of something (and don't want to build from source) we got things like flatpak, appimage directly from developers or AUR and nix and other stuff. I'm yet to find someone proposing brew over the rest because of some new package genuinely being available only on brew only.
    - Hackbraten 2y ago
      > we got things like flatpak, appimage directly from developers Some people prefer timely, high-quality, well-tested bugfixes and security updates for the underlying low-level dependencies of an app. An upstream app developer is much less likely to provide an updated flatpak mere minutes after e.g. a critical OpenSSH security fix comes out of embargo. Distro maintainers on the other hand, such as the Homebrew core maintainers, can do that. They also have security audits, see TFA, and established processes. Nothing wrong with that at all. > and nix That just comes down to personal preference. Some people like Nix due to the amazing level of isolation it provides, and that’s perfectly fine. Some prefer Homebrew instead because it’s easy to use and respects the FHS. All the things we’ve discussed so far are highly subjective, come down to personal preference, and say absolutely nothing about how skilled a user is.
lrvick 2y ago
I am a bit surprised this did not highlight major low skill attack surface in Homebrew as compared to almost all Linux and *BSD package managers: Supply chain integrity. Homebrew maintainers mostly do not sign commits/packages, do not sign reviews/merges, do not verify author/reviewer sigs at compile time, do not reproduce builds in separately controlled CI, do not enforce hardware 2FA on Github. Every user of brew is only as secure as whichever of hundreds of brew maintainers has the worst opsec today. Also since dependabot automatically makes commits, you could get a malicious commit into an external project you control, wait for dependabot to make a commit to homebrew to upgrade it, then merge it yourself (as becoming a homebrew maintainer has almost no vetting, just fix a few easy bugs) You could also just take over one of the expired email domains of a maintainer and send a password reset email to yourself and take over an account of someone on vacation or hiatus. Can likely get thousands of companies compromised before anyone notices. Honestly I would never allow Brew on any company machines I have authority over. It is giving hundreds of randos, (and anyone that takes advantage of their poor opsec) the ability to execute any code on user systems. Major Linux package managers do not go nearly far enough with things like review signing, but most at -least- do author-level package signing, human review, and independent reproduction for most packages. Given how many high value targets like corporate sysadmins allow brew on their computers, Brew is on track to overshadow Crowdstrike any day now for most harm caused by insufficient supply chain management.

845 points by zdw 2y ago

amai 2y ago

Nowadays even Windows has a package manager (https://en.wikipedia.org/wiki/Windows_Package_Manager https://en.wikipedia.org/wiki/Windows_Package_Manager). Why does Apple/Mac OS X not develop something similar?

yjftsjthsd-h 2y ago

There's a bunch of TOB-BREW-n listed - are those like CVE numbers just for this project? Edit: Oh, it's "Trail Of Bits - homeBREW". But probably still yes.

woodruffw 2y ago
Yep. We use the TOB-$PRODUCT-$XXXX convention for our audit findings, where $PRODUCT is the target under audit and $XXXX is a unique incrementing counter for each finding. (As far as I know, a lot of audit firms do similar things.)
- Alifatisk 2y ago
  First time seeing TOB being used honestly, it would’ve helped saying something along the lines of ”Trait of Bits (TOB from now on)”
  - RulerOf 2y ago
    Other companies do similar things. Red Hat creates RHSA-YYYY:XXXX for example, like this one for Log4Shell: https://access.redhat.com/errata/RHSA-2022:0442 https://access.redhat.com/errata/RHSA-2022:0442
- jonahx 2y ago
  I cannot reply to your top comment for some reason, so asking here: What is your personal recommendation for Mac users? Would you suggest a different package manager and, if so, which?
  - woodruffw 2y ago
    Given that I did the audit, I don’t think it’s appropriate for me to offer an endorsement (or a negative endorsement) in this context. What I’ll say is this: the findings on Homebrew were not inconsistent with what I’d expect to find on any similarly sized userspace package manager that serves its own binary builds.
    - luckman212 2y ago
      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"
      - freep1zza 2y ago
        One should try to avoid using double negatives in both speech and programming to make intent more obvious ;-)
        gorlilla 2y ago
        Except the ambiguity was the intent.
        Brian_K_White 2y ago
        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.
- MARION_787 2y ago
  [flagged]
- MARION_787 2y ago
  [flagged]
- MARION_787 2y ago
  [flagged]
- MARION_787 2y ago
  [flagged]
- MARION_787 2y ago
  [flagged]
- MARION_787 2y ago
  [flagged]

apitman 2y ago

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 would break if not run this way: Facebook's Watchman[1]. It bizarrely (to me) has hard coded paths compiled into it, which force you to run it from specific directories. Would love to understand what's going on here and why you would ever make software work this way. I feel I'm missing a fairly obvious Chesterton's Fence. [0]: https://github.com/orgs/Homebrew/discussions/5371 https://github.com/orgs/Homebrew/discussions/5371 [1]: https://facebook.github.io/watchman/docs/install#prebuilt-binaries-2 https://facebook.github.io/watchman/docs/install#prebuilt-bi...

bagels 2y ago
In the case of Watchman, I have to assume that internal use is the most supported use case, and uniformity of deployment is desirable across the fleet there, and so, configurability wasn't as big of a concern?
- cqqxo4zV46cp 2y ago
  My short experience with Watchman (a few years ago) indicates this. It’s pretty clearly only technically open-source, without much regard at all paid to third parties actually using it.
  - chatmasta 2y ago
    I’ve had a few build pipelines break over the years because of a watchman dependency. IIRC it was usually an issue with an npm library depending on watchman but downloading a binary that was incompatible with the architecture or implemented the wrong syscalls for the operating system.
- apitman 2y ago
  That makes sense. The weird part to me is that Homebrew would limit their approach and eliminate an entire class of use cases to accommodate programs that work this way. There has to be more to it.

woodruffw 2y ago

I'm the author of this post and one of the people behind the audit; happy to answer questions about it. If you're having trouble finding the audit itself (it's linked indirectly), I'm linking a copy here as well[1]. [1]: https://github.com/trailofbits/publications/blob/eb9344f2261031a4be1be2f223e9b5bc535be6b9/reviews/2023-08-28-homebrew-securityreview.pdf https://github.com/trailofbits/publications/blob/eb9344f2261...

jmbwell 2y ago

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.

deleted 2y ago
[deleted]
ggm 2y ago
For people who don't know, pkgsrc works fine on macOS, the complaint was well made: its not the default. I use brew, and have used pkgsrc in the past. I could go back for low pain.
arprocter 2y ago
It'd be nice if brew was a little more apt-y, and all the beer nomenclature is a bit silly My first exposure to Mac package stuff was fink in the early aughts - compiling everything on a Pismo G3 was pretty slow going
- jonhohle 2y ago
  Switch to MacPorts. It supports precompiled packages, doesn’t take over the world and force anything on you the same way Homebrew does. I’m really disappointed in how Homebrew took a lot of attention away from the existing package managers, made a bunch of terrible decisions related to packaging and flexibility and genera Unix philosophy, and then ate the world. : shakes fist at clouds, get off my lawn
CaliforniaKarl 2y ago
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.
- nsagent 2y ago
  Yeah, I switched from Homebrew to MacPorts a few years ago and couldn't be happier.

user3939382 2y ago

I’m still good on MacPorts. Seems I’m alone these days. Works fine for me.

8b16380d 2y ago
Nah I’ve been on macports for years now. No problems; the community is very active, just follow the mailing lists etc
deleted 2y ago
[deleted]
bdangubic 2y ago
honebrew works too :)
paradox460 2y ago
I keep ports around for things like lilypond (which I use for quasi-professional score engraving) and some other packages that homebrew is weird on. The removal of options a few years back still stinks for be
wwalexander 2y ago
There are dozens of us!
blt 2y ago
I got sick of Homebrew after a while and tried switching to MacPorts, but it feels like an endless uphill battle when so many packages only offer source and Homebrew distributions.
pxc 2y ago
I mostly just use Nix, but I also have pkgsrc, MacPorts, and (kinda) Homebrew installed on my Mac. The only ones with any CLI tools installed, though, are Nix and pkgsrc.
_0xdd 2y ago
You are not. I've been using MacPorts for 15+ years at this point. Started with fink and then made the switch around the days of Snow Leopard. I'm also a BSD user, so no surprise there. I enjoy being able to compile ports with non-standard variants (e.g., non-free codecs in ffmpeg, removing un-needed interpreters from packages, etc.)

alxmdev 2y ago

[flagged]

trav4225 2y ago
Hah! IIRC, it was a binary tree of some sort.
deleted 2y ago
[deleted]

neverrroot 2y ago

Not surprised to see some problems. Still sad to see security take a backseat as opposed to convenience.

greggsy 2y ago

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 source? How does the user gain confidence that their brew update is still referencing a trusted source? What happens when a domain is taken over? How quickly can the team respond to untrusted sources from formulas? I know these aren’t all Homebrew problems to solve, but they’re important ecosystem considerations. (These problems also exist in the winget and choco platforms, but less so in commercially supported repos like apt and yum. For me, and many other admins, they are a major concern when it comes to the Windows Store.) Edit: lastly, in case the homebrew team are watching: an npm-style vulnerability notice would be awesome

dotBen 2y ago
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 known individuals is of course worrying. As a SWE/EngMgr turned VC, I'm curious if there's startups or commercial companies providing some kind of assurance here (but also worried the $ TAM for solving this problem probably isn't enough to make it a standalone business).
- brimwats 2y ago
  > 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
  - azurezyq 2y ago
    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?

deleted 2y ago

[deleted]

scovetta 2y ago

Well done! And thank you to the Open Tech Fund for sponsoring work to protect everyone who uses Homebrew.

marxisttemp 2y ago

MacPorts is always waiting for you with more packages, a better design, and Jordan Hubbard’s history with BSD/Apple :)

jagged-chisel 2y ago
so many projects release only formulas for homebrew. I keep both and try to use McPorts first.
- ggm 2y ago
  Most homebrew users started in macports, or fink. Very few I talk to (admittedly not many and curmugeons) want to go back.
  - eduction 2y ago
    Key difference is Mac ports keeps its tree separate in /opt. This means things take longer initially to install because it can’t just leverage system stuff already there. Upside is greater reliability because it doesn’t have to worry about a system update changing its dependencies. I prefer the greater reliability of macports.
    - parhamn 2y ago
      > Key difference is Mac ports keeps its tree separate in /opt What do you mean by this? brew has been linking from /opt/homebrew for years now.
      - ggm 2y ago
        The person you're responding to may have been using homebrew on Intel. It's been in /opt on ARM since inception on ARM.
      - eduction 2y ago
        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 can be upgraded more or less aggressively than Apple's. https://trac.macports.org/wiki/FAQ#syslibs https://trac.macports.org/wiki/FAQ#syslibs

pmarreck 2y ago

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 <packagename>" as easily as with brew, https://github.com/pmarreck/ixnay https://github.com/pmarreck/ixnay), the overall guarantees make it worth it.

bokchoi 2y ago
I also find the nix command line annoying. I'll give this a try. I like the embedded `#help` documentation!
- Brian_K_White 2y ago
  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 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 #help One jank in mine is I have a verbosity level setting which affects most messages, and help() uses it to filter some of the help. Normal verbosity shows only the normal help for the normal commands. If verbosity is set higher, then help() shows more commands. The way that's implimented in help() is extra comments that change the behavior of help() as it's scanning the file from top to bottom. When it hits a '#v 2' it starts only displaying the help if the user has currently set verbosity>=2 until further notice. Later down the file it hits a '#v 1' and starts displaying help again... It works but it feels kind of 70's or assembly. #v 1 #h normal help for mortals #h ... #v 2 #h don't confuse the simple folk with this dangerous powerful stuff... #h ... #v 1 #h a few more normal commands #h ... #v 0 #h display this even the user has set verbosity to 0 to request silence #h ...
  - pmarreck 2y ago
    > 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/ https://wryun.github.io/es-shell/ (he still works on this and it is indeed very interesting!)

arandomhuman 2y ago

If macs supported PKGBUILDs like Pacman with a similar level of performance and there were correctly maintained packages for core programs I'd feel like using a mac would have a lot less compromises for convenience. Homebrew is great and the formulae are maintained really well but the simplicity of PKGBUILDS, the fast syncing, and lack of cognitive burden of recalling multiple arguments/flags for package managers make me wish pacman just worked on macs.

pxc 2y ago
There have been a few attempts at this. I think some of them may even be working.
megamix 2y ago
Is MacPorts not the same? Genuinely asking.
- sirn 2y ago
  The concept is the same (given a definition file, build a package from a central repo, aka ports-like), but one of the features of PKGBUILD has is that it's easy to build an ad-hoc package outside the main tree. For example, you can download a bundle of PKGBUILD and `makepkg` in any directory to build a package. In other ports-like build systems, this can be a bit more complicated. For example, MacPorts allows you to use a local repository, but it requires configuring that local repository in `/opt/local/etc/macports/sources.conf` and `portindex` it beforehand before MacPorts could pick it up. Some others don't support building out of the main tree at all. Personally, out of all ports-like building systems, I like MacPorts' Portfile the most. It's similar to FreeBSD Ports' BSD Makefile (MacPorts was created by Jordan Hubbard who also co-created FreeBSD Ports) but using DSL via Tcl interp instead of being a shell script (POSIX shell in the case of Alpine's APKBUILD, bash in the case of others). From my experience, the syntax is very nice to work with, though you need to know a bit of Tcl for a non-trivial package.
izik 2y ago
The vanilla pacman will not work on macos as expected but there are attempts [1],[2] to make it works with some modifications/hacks. [1] https://github.com/liudongmiao/pacman https://github.com/liudongmiao/pacman [2] https://github.com/kladd/pacman-osx https://github.com/kladd/pacman-osx

nothrowaways 2y ago

Apple should have been the one funding the audit.

CydeWeys 2y ago
Apple should have written it themselves. It's embarrassing that they didn't. Nonprofit Linux distros with one-millionth the resources manage to write package managers and run repos, and then with MacOS, Apple gives you diddly-squat.
- rurban 2y ago
  Apple would certainly favor macports over that rubbish ruby thing. Ports are from FreeBSD, MacOS is from FreeBSD.
  - pxc 2y ago
    Then why did Apple hire the creator of Homebrew to work on the package manager for Swift?
    - saagarjha 2y ago
      You should read https://en.wikipedia.org/wiki/MacPorts#History https://en.wikipedia.org/wiki/MacPorts#History. But to answer your question: why not? Apple employs thousands of software engineers.
  - dewey 2y ago
    No need to call someone’s free open source project “rubbish”.
  - latexr 2y ago
    That is provably false from so many angles. * Apple has no aversion to Ruby, and on the contrary has multiple developers pushing for it. They themselves had MacRuby, a project that allowed one to create Mac OS X (at the time) applications with Ruby.¹ * The reason there’s even an Xcode command line tools package available officially from Apple is because of Homebrew. A third-party made it first by extracting the necessary bits and then Apple officially supported it.² * There’s a liaison between Homebrew and Apple, who helped during the Intel to Apple Silicon transition.³ ¹ https://web.archive.org/web/20100908131627/http://developer.apple.com:80/mac/articles/scriptingautomation/cocoaappswithmacruby.html https://web.archive.org/web/20100908131627/http://developer.... ² I know this from a reliable source and it is public information, but it was so long ago it’s hard to find. ³ The official Homebrew Twitter account tweeted about this at the time. I no longer have a Twitter account so can’t dig it up.

sohrob 2y ago

Great that there are people looking into this. I wonder if there would be similar findings were they to perform an audit on MacPorts or the Nix package manager.

eddyg 2y ago

Any idea how much impact the audit has and/or applies to Workbrew[0], their new business-oriented MDM-manageable package tool? [0] https://workbrew.com/ https://workbrew.com/

mikemcquaid 2y ago
Workbrew wraps a vanilla, unmodified Homebrew on Macs running it under a ‘workbrew’ user for user privilege separation and better multi-user support.

KennyBlanken 2y ago

[flagged]

mrpippy 2y ago
On Apple Silicon Macs, Homebrew installs in /opt/homebrew.
deleted 2y ago
[deleted]

koito17 2y ago

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.

justusw 2y ago
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.
- wredue 2y ago
  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.
  - woodruffw 2y ago
    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.
    - 2y ago

efitz 2y ago

Were the reported issues all addressed by the Homebrew maintainers or are any still unmitigated?

zargon 2y ago
https://brew.sh/2024/07/30/homebrew-security-audit/ https://brew.sh/2024/07/30/homebrew-security-audit/

razodactyl 2y ago

The amount of value returned to the Apple ecosystem through brew is remarkable and while this post makes me even more in awe of the care that goes towards the community, I'm sad that one of the richest companies in the world isn't giving more back.

deleted 2y ago
[deleted]

saagarjha 2y ago

I peeked at the sandbox escape bug and its associated fix: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c716585b072b5a401602f7847272ae5d4a https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7.... Is this…correct? Like, this is to prevent it from being interpolated into a sandbox profile and messing things up. How confident are we about this list of characters?

js2 2y ago
The commit message could have answered that question, but instead, it only repeats what the diff already tells us: "Don't allow special characters in sandbox rule paths". It doesn't explain why, or what's special about the particular characters that it disallows. A better message would have said something like "Prevent certain characters in the path because otherwise ... We need to worry about these specific characters but not others because..." Even if I wrote this code and knew what it did today, if I come across this it a year from now, I'm left scratching my head: why did I make this change? A real world example of a good commit message: https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce988d6b7936a9765a https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce98...
frenchman99 2y ago
Surprised too, if that is the fix. Wouldnt a whitelist be better than a blacklist?

Ferret7446 2y ago

[flagged]

leokennis 2y ago
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"?
- andruby 2y ago
  (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/mxcl/status/608682016205344768 https://x.com/mxcl/status/608682016205344768 [1] https://news.ycombinator.com/item?id=15713801 https://news.ycombinator.com/item?id=15713801
  - latexr 2y ago
    > I personally wouldn't hold that against him (or Homebrew). No one should hold that against Homebrew. Max was already not part of it when that happened and he does not speak for the remaining team.
  - Ferret7446 2y ago
    I had to dig it up, I'm talking about this. https://www.reddit.com/r/google/comments/7l5ibp/max_howell_homebrew_creater_finally_opens_up_on/ 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.

tucosan 2y ago

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.

j16sdiz 2y ago
They noted that and just assume formulae are trustworthy. > ... These avenues do not necessarily violate Homebrew’s core security assumptions (which assume trustworthy formulae),...
woodruffw 2y ago
I don’t think the current Homebrew core formulae reviewers consider their team too small to sufficiently review all new incoming formula requests. But even if it was: this is one of the vagaries of packaging that’s explicitly called out in the post: the boundary between first- and third-party execution is inherently murky, and there’s IMO relatively more security “value” in determining where third-party execution can surprisingly happen than pointing out all of the unsurprising things that happen when you intentionally run third-party code. (With that being said, I think packagaging ecosystems in general should be reviewed for those kinds of acceptance processes. But that would be closer to a “red team” style audit than a software audit, since it’s about human processes.)
Bluecobra 2y ago
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.

hk__2 2y ago

I’m a bit puzzled by the wording of this blog post, because it says you’ve worked with Homebrew to do this audit, but your name sounds familiar to me, and indeed if we check Homebrew’s README [1]: > Homebrew's maintainers are […long list of names…] William Woodruff […] [1]: https://github.com/Homebrew/brew https://github.com/Homebrew/brew Is there any reason this is not mentioned in the blog post? I don’t think it would make a difference, but just to clarify things.

woodruffw 2y ago
I wasn’t a maintainer at the time I did the audit :-). I’ve been a non-maintaining “member” of the project for a long time, which is the pseudo-emeritus position we give to previous maintainers who want to continue participating in internal conversations and governance. I was then offered membership again, months after the audit, due to some unrelated work on Homebrew that didn’t exist and wasn’t planned before the audit was planned. This was all disclosed as part of a conflict-of-interest disclosure I did, both with my company and with the Homebrew maintainers, but I agree that the blog post could also say that explicitly. I’ll try and get it added today. TL;DR: I was not a maintainer at the time the audit was performed, but I was previously (years before) and am currently a maintainer. The audit was performed by myself and my colleagues in our professional capacities.
- hk__2 2y ago
  Thank you!
- Ylpertnodi 2y ago
  Why, oh why....are TL;DR's at the end of articles/ comments?

mootoday 2y ago

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 https://mootoday.com/blog/i-replaced-homebrew-with-devbox https://mootoday.com/blog/i-replaced-homebrew-with-devbox

charlie0 2y ago
As someone unfamiliar with Nix, how is this better than Homebrew?
- mootoday 2y ago
  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 <repo>` to persist my config in a repo.
  - replete 2y ago
    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
    - mootoday 2y ago
      I had done the same before I learned about Devbox. It's very lightweight and gets very powerful combined with `git worktree` to work on multiple branches in parallel, each with its own database instance.
- KolenCh 2y ago
  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.

alberth 2y ago

> Since 2012, Trail of Bits has helped secure some of the world’s most targeted organizations and products. We combine high-end security research with a real world attacker mentality to reduce risk and fortify code. It's interesting that I don't see any analysis referencing OpenBSD (either as a product or as an alternative to something else they have done research on).

mysore 2y ago

[flagged]

daghamm 2y ago

Kinda off topic, but when I see a project or an article use brew on Linux instead of their native package manager or something like flatpak I generally assume the author has very limited knowledge about Linux and I can ignore this project/article.

Hackbraten 2y ago
Even though Homebrew isn’t meant as a replacement for the system package manager, there are legitimate use cases. For example, if you’re on Debian but need a newer version of just one tool, it makes absolute sense to install Homebrew alongside. It’s designed to play well with the system package manager, uses its own separate prefix so it won’t cause shared libs confusion, and only shadows the packages you install with it. Nothing wrong with that inherently, and certainly not a sign of limited knowledge.
- daghamm 2y ago
  I don't see that. Brew on Linux is a copy of dito on osx which itself was inspired by Linux package managers. Instead of using the real deal, people generally suggest Brew because that's what they are familiar with from osx. If you need bleeding edge of something (and don't want to build from source) we got things like flatpak, appimage directly from developers or AUR and nix and other stuff. I'm yet to find someone proposing brew over the rest because of some new package genuinely being available only on brew only.
  - Hackbraten 2y ago
    > we got things like flatpak, appimage directly from developers Some people prefer timely, high-quality, well-tested bugfixes and security updates for the underlying low-level dependencies of an app. An upstream app developer is much less likely to provide an updated flatpak mere minutes after e.g. a critical OpenSSH security fix comes out of embargo. Distro maintainers on the other hand, such as the Homebrew core maintainers, can do that. They also have security audits, see TFA, and established processes. Nothing wrong with that at all. > and nix That just comes down to personal preference. Some people like Nix due to the amazing level of isolation it provides, and that’s perfectly fine. Some prefer Homebrew instead because it’s easy to use and respects the FHS. All the things we’ve discussed so far are highly subjective, come down to personal preference, and say absolutely nothing about how skilled a user is.

lrvick 2y ago

I am a bit surprised this did not highlight major low skill attack surface in Homebrew as compared to almost all Linux and *BSD package managers: Supply chain integrity. Homebrew maintainers mostly do not sign commits/packages, do not sign reviews/merges, do not verify author/reviewer sigs at compile time, do not reproduce builds in separately controlled CI, do not enforce hardware 2FA on Github. Every user of brew is only as secure as whichever of hundreds of brew maintainers has the worst opsec today. Also since dependabot automatically makes commits, you could get a malicious commit into an external project you control, wait for dependabot to make a commit to homebrew to upgrade it, then merge it yourself (as becoming a homebrew maintainer has almost no vetting, just fix a few easy bugs) You could also just take over one of the expired email domains of a maintainer and send a password reset email to yourself and take over an account of someone on vacation or hiatus. Can likely get thousands of companies compromised before anyone notices. Honestly I would never allow Brew on any company machines I have authority over. It is giving hundreds of randos, (and anyone that takes advantage of their poor opsec) the ability to execute any code on user systems. Major Linux package managers do not go nearly far enough with things like review signing, but most at -least- do author-level package signing, human review, and independent reproduction for most packages. Given how many high value targets like corporate sysadmins allow brew on their computers, Brew is on track to overshadow Crowdstrike any day now for most harm caused by insufficient supply chain management.