[HN Gopher] Our audit of Homebrew
___________________________________________________________________
Our audit of Homebrew
Author : zdw
Score : 752 points
Date : 2024-07-30 22:39 UTC (1 days ago)
(HTM) web link (blog.trailofbits.com)
(TXT) w3m dump (blog.trailofbits.com)
| yjftsjthsd-h wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| jonahx wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| One should try to avoid using double negatives in both
| speech and programming to make intent more obvious ;-)
| gorlilla wrote:
| Except the ambiguity was the intent.
| Brian_K_White wrote:
| 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.
| croemer wrote:
| The speed of light _is_ constant, how could it otherwise
| be a fundamental constant? I think you might have meant
| time/distance is relative?
| Brian_K_White wrote:
| "not inconsistent" is a common phrase and is used for a
| reason. It's a subtle difference but "not inconsistent"
| is not exactly the same as "is consistent".
| simonklitj wrote:
| That's not necessarily what was meant though.
|
| "Not inconsistent" is more cautious and less assertive.
| It allows for some ambiguity rather than claiming perfect
| consistency.
| Cloudef wrote:
| I use nix on both mac and linux, also on CI where homebrew
| is especially brittle
| lifty wrote:
| Don't you have to disable SIP to use nix on macOS?
| Cloudef wrote:
| No. Even though SIP is slightly annoying because you
| can't have strace equivalent with it.
| socksy wrote:
| No, see
| https://nix.dev/manual/nix/2.18/installation/installing-
| bina...
| FireBeyond wrote:
| If there's any hope of Nix seeing widespread adoption as
| a Mac package manager, uh... this link kinda shoots it
| down a lot.
|
| From that:
|
| - create a new APFS volume for your Nix store
|
| - update /etc/synthetic.conf to direct macOS to create a
| "synthetic" empty root directory to mount your volume -
| specify mount options for the volume in /etc/fstab: rw:
| read-write, noauto: prevent the system from auto-mounting
| the volume (so the LaunchDaemon mentioned below can
| control mounting it, and to avoid masking problems with
| that mounting service), nobrowse: prevent the Nix Store
| volume from showing up on your desktop; also keeps
| Spotlight from spending resources to index this volume
|
| - if you have FileVault enabled: generate an encryption
| password, put it in your system Keychain, use it to
| encrypt the volume
|
| - create a system LaunchDaemon to mount this volume early
| enough in the boot process to avoid problems loading or
| restoring any programs that need access to your Nix store
|
| Even as someone who knows how to do all that... no
| thanks.
| apitman wrote:
| 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
|
| [1]: https://facebook.github.io/watchman/docs/install#prebuilt-
| bi...
| bagels wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| nightpool wrote:
| I don't think that's accurate--homebrew specifically says
| that it only uses the .linuxbrew directory when a formula
| contains a hardcoded path (which it scans for), and only if
| you choose not to install it from source.
|
| So, based on the responses from the maintainers, for the
| .linuxbrew directory to be used, you have to satisfy 2
| conditions:
|
| 1. you have to be installing one of the ~10% of formula
| that isn't trivially relocatable.
|
| 2. you have to be using a precompiled binary (which it
| seems like homebrew is smart enough to not do if condition
| #1 fails and you're not using sudo)
| woodruffw wrote:
| The short (but possibly not satisfying) answer is that
| Homebrew's relocation of packages (including binary relocation)
| is best effort, in part because of the myriad ways in which
| packages can embed absolute (or incorrect relative) paths and
| other state in their build products. macOS bottles are
| generally more relocatable (in part because of a lot of scar
| tissue around binary relocation), but it's a general problem
| with build system quality, build complexities, and - reasonably
| - disinterested upstreams.
| woodruffw wrote:
| 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/eb9344f2261...
| jmbwell wrote:
| 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.
| ggm wrote:
| 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.
| CaliforniaKarl wrote:
| 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 wrote:
| Yeah, I switched from Homebrew to MacPorts a few years ago
| and couldn't be happier.
| throwaway290 wrote:
| Same here.
| wwalexander wrote:
| MacPorts is awesome. The PortGroups also make it super easy
| to make new packages.
| brandall10 wrote:
| Anyone know why Homebrew overtook MacPorts? I only have a
| vague recollection of a Rails colleague pushing me to switch
| circa 2013 or so and haven't given it much thought since, but
| it (MacPorts) seemed to be similarly ubiquitous prior.
| llimllib wrote:
| Here's why I switched early on in homebrew's life from
| ports
|
| - brew had and has many more packages available
|
| - brew updates versions more quickly
|
| - brew uses much more simple paths that fit my brain better
|
| - brew has a pleasing simplicity
| 1123581321 wrote:
| MacPorts was slower (bringing in its own dependencies for
| everything meant longer build steps) and required sudo
| more. There were some annoying fiddly parts that made it
| seem like the homebrew users around you were having more
| fun exploring packages.
|
| It was also exciting how many packages and casks were in
| homebrew and it was easy to make your own.
|
| Also, back then there were lots of people experiencing
| package managers for the first time and they took to
| homebrew easily.
|
| Then so many projects started to publish brew install links
| as a way to get started; homebrew felt like a default.
|
| Now, with our faster computers, more space, and more
| packages installed, and macports shipping more binaries and
| using its own normal user, macports' duplication of
| dependencies looks more like an advantage than a
| disadvantage. And because homebrew taught so many people
| how to use package managers, macports is not their first so
| easier to start using.
| steve_adams_86 wrote:
| > Also, back then there were lots of people experiencing
| package managers for the first time and they took to
| homebrew easily.
|
| I suppose it was almost 15 years ago now but this is what
| I recall. Homebrew was easier, snappier, and the general
| friction coefficient felt smaller.
|
| It's a little funny reading this and then wonder... Why
| _did_ I leave MacPorts behind? I don 't think I put much
| thought into it at the time and rather went by feel. I
| was still somewhat new to this stuff having started my
| career more in design than development.
| BeFlatXIII wrote:
| I'd push back slightly on the "more space" claim due to
| Apple's notorious stinginess for SSD & RAM.
| jrochkind1 wrote:
| At the point I switched from MacPorts to Homebrew, homebrew
| just worked more reliably in my experience. It installed
| things quicker and with fewer build/install failures. i
| don't know enough about what was going on under the hood to
| have any theory as to why this was my experience; I don't
| want to know what's going on under the hood, I just want to
| type `install whatever`, and have it work.
| sizeofchar wrote:
| When I started using a Mac in 2009, MacPorts, Fink (and I
| think there was another I can't recall the name) simply
| wouldn't work for me. They would take very long to build
| what I wanted, there weren't nearly as many packages as was
| in Debian/Ubuntu, and many were old versions. Worse, many
| build attempts would just fail.
|
| In that scenario, brew worked like a charm. It was quick,
| had most or even more packages than Debian/Ubuntu and they
| were newer. Failure to install was rare.
|
| Then, Apple started yearly release of OS X, and that both
| broke brew and my system hard, so I started investigating
| and found out about the many "shortcuts" that brew took and
| how it violated systems components. I was dismayed, and
| abandoned brew for good.
|
| So, I stood a period where I would use many of my tools
| inside a Ubuntu VM, until probably 2013-2014, when for some
| reason I tried again MacPorts, and I don't know why, but
| that time it was much more reliable, and because of Apple's
| insane atm SSDs with 2 GB/s bandwidth, install became quick
| enough. Packages were still somewhat lagging behind in
| available versions, but the variety of them kinda reached
| the levels of what was in Debian/Ubuntu, so it was good
| enough for me.
|
| Then, the killer feature, I found out about macports
| variants and selectors, which I find the most awesome thing
| to this date in package managers (I haven't tried nix,
| still, it might be magnitude better in that regard). No
| needing to use rvm, pyenv, custom installs of gcc messing
| with make/autotools, and the only sane way of compiling
| various Haskell projects (before haskell-stack).
| CaliforniaKarl wrote:
| I don't know when they introduced it, but I believe
| MacPorts will build the common variants of the more-used
| packages. So, if you install a package with the default
| variants, you'll get a binary download instead of
| building from source.
|
| But indeed; fast SSDs, parallel compilation, and modern
| CPUs really help!
| saagarjha wrote:
| I think MacPorts builds basically everything and offers
| it as a binary if they think they can distribute it
| legally
| steve1977 wrote:
| I guess MacPorts was (and is) geared more towards users
| with some proper UNIX or BSD background, e.g. people coming
| from FreeBSD.
|
| Whereas Homebrew targets the typical Mac user who might
| need a CLI application occasionally, i.e. someone looking
| for simplicity, without being too technically savvy.
|
| The latter group certainly makes up a much bigger share of
| users on macOS, especially nowadays.
| fragmede wrote:
| this was a while back, in the Gentoo Linux heyday, so it
| was popular to compile things, except that this was when
| computers were slow, so that meant waiting for compiles.
| the problem with macports was that (iirc, it's been a
| while) it compiled its own version of Python instead of
| just using the system python, which also broke sometimes.
| and then you had to compile all that shit again. brew won
| out because it was faster, and didn't duplicate redundant
| shit for no perceived reasom.
| pxc wrote:
| Here's my guess.
|
| Homebrew had at least these things going for it:
| - it has always had a strong emphasis on presenting a
| simple, clean, pleasant, pretty, playful UI and executed
| that well - when it came out, source-based package
| managers for macOS generally didn't have any binary caching
| mechanisms, so compile time mattered - Homebrew's
| embrace of the base system as opposed to bringing its own
| dependencies bought it greater reuse at the cost of
| robustness, driving down total time to install many
| packages - the language that `brew` and its packages
| were written in was trendy at thw time as well as pre-
| installed on macOS, which made them instantly accessible to
| huge numbers of web developers - the older macOS
| package managers generally drew on traditions and tooling
| from the Linux world (e.g., Fink, with Debian tooling) or
| the wider Unix world (e.g., MacPorts and various *BSD ports
| systems and packages written in some Tcl IIRC).
|
| The type of person with the experience that would lead them
| to prefer tools and conventions like one sees in Fink,
| MacPorts, and Pkgsrc, or to contribute to those projects,
| has likely always been dismayed, if not repulsed, by a
| number of Homebrewisms. I think we can therefore conclude
| that Homebrew didn't win the package availability race by
| converting MacPorts contributors-- Homebrew succeeded in
| attracting a largely untapped pool of _new_ contributors.
| Eventually there followed the majority of non-contributor
| users who just want to use whatever already offers the
| software they want to run.
| throwaway290 wrote:
| People like beer but also Homebrew had a cute site and made
| ports simpler than MacPorts. Turns out complexity was maybe
| not unwarranted. I was among first adopters of brew but now
| I port for years
| mzs wrote:
| When you installed a port with macports the idea was to use
| as much of the macports for build and runtime dependencies.
| Over time that became greater and so port install would be
| slow until you built enough dependancies. It also consumed
| more storage.
|
| When you installed a port with brew it used as much of the
| OSX, X11, and XCode installed utilities as possible so it
| was faster and used less storage. But then you would
| install an update from Apple and things would break cause
| of that reliance, things like /usr/bin/perl.
| paholg wrote:
| When I've had to use a Mac, I've used nix to good success. I'm
| actually surprised how well it worked; I was able to basically
| just use the same config I use on Linux, removing just the few
| Linux-specific packages.
| SOLAR_FIELDS wrote:
| Do you not use many packages and only strictly use FOSS
| tooling? I have a large and growing list of packages that
| have to be managed in Homebrew still because the package is
| one of the following:
|
| 1. Not available at all in nixpkgs (e.g. Docker Desktop,
| BetterTouchTool, etc)
|
| 2. In nixpkgs, but completely broken or missing some
| architecture support (e.g. Firefox)
|
| 3. Actually available and somewhat functional in nixpkgs, but
| some significant features don't work because of code signing
| requirements and needing to be managed in the Applications
| folder (e.g. 1Password)
|
| Quite a few tools do in fact work well with nix on Mac.
| Especially if it's FOSS and/or a cli-only based tool. And for
| FOSS tooling such as Firefox, there is often a convoluted
| workaround (I'm currently using `github:bandithedoge/nixpkgs-
| firefox-darwin`). And of course you can always package it
| yourself by doing things The Hard Way.
|
| But the platform is still quite a ways away from being able
| to be used as a daily driver on Mac without Homebrew.
| paholg wrote:
| Huh, interesting. I did primarily use FOSS and CLI
| applications. It's been a couple years, so I don't remember
| what exactly I used it for. I probably installed Docker
| Desktop via whatever method docker recommends, and I'm not
| sure about Firefox.
|
| For alacrity, I remember it being annoying to integrate
| into Mac's launcher, but it otherwise worked.
|
| Pretty much everything else was programming-related and
| just worked.
| Cloudef wrote:
| If you want graphical apps to be handled by nix on macos,
| you might be interested in
| <https://github.com/BatteredBunny/brew-nix>. nixpkgs does
| not package macos sandboxed apps AFAIK, that means
| typically only cli utilities, libraries and development
| tools only work.
| SOLAR_FIELDS wrote:
| Tried this when it was released on HN. It does not work
| out of the box. There is some problem with launching apps
| from outside of the applications folder. The trampoline
| Mac-app-util approach does not work. Though in theory it
| probably should for most applications. I don't know
| enough about the code signing process to be able to debug
| what is wrong with it.
| pxc wrote:
| I recently tried out mac-app-util1, which fixes some of the
| usual pain with GUI apps. In conjunction with brew-nix2, 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 painfully slow `brew` invocations
| that lurk in my activation scripts.
|
| --
|
| 1: https://github.com/hraban/mac-app-util
|
| 2: https://github.com/BatteredBunny/brew-nix
| SOLAR_FIELDS wrote:
| I tried this exact combination but it did not work out of
| the box for the apps I tried. For gui apps bundled with
| brew-nix they will panic due to something about how the
| code signing keys are copied with brew-nix. The Mac-app-
| util trampoline launcher does work with the regular way
| that brew is managed with nix (which under the hood just
| shells out to brew) though. So the problem is likely
| related to brew-nix installing apps outside of the
| Applications folder.
|
| I hacked around a bit trying a few different approaches
| before giving up and switching back to the regular nix-
| Darwin homebrew approach. But the issue is probably
| solvable by someone who knows a lot more about how the
| code signing process works with Macs and the Applications
| folder
| arprocter wrote:
| 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 wrote:
| 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
| bainganbharta wrote:
| This is the pkgsrc-based package manager I use on macOS. It's
| simple and has the packages I need.
|
| https://pkgsrc.smartos.org/install-on-macos/
| throw0101a wrote:
| > _https://pkgsrc.smartos.org/install-on-macos/_
|
| Note that Pkgsrc is a NetBSD-derived project.
|
| * https://pkgsrc.org
|
| The Joyent folks leveraged it to allow their customers, who
| were perhaps not as familiar with Solaris/SmartOS, a larger
| pool of packages. Pkgsrc was running on Solaris before
| Joyent, Joyent built on top of it.
| 8b16380d wrote:
| Just use pkgsrc or macports. IMO way easier and less intrusive
| than homebrew.
| rahen wrote:
| I've been using pkgin and pkgsrc for years on macOS.
| Occasionally, I still need a small brew prefix when a
| dependency is missing or difficult to build. Molten-vk was the
| last such package.
|
| pkgsrc is by far the most KISS package manager for macOS, I
| like it.
| neverrroot wrote:
| Not surprised to see some problems. Still sad to see security
| take a backseat as opposed to convenience.
| greggsy wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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?
| lionkor wrote:
| Ah yes, the "bad guys".
| 0xedd wrote:
| Yeah, well, harvesting human organs (selling them to US
| customers) and maintaining death camps in 2024 is kind of
| "bad guys" for me. But, to each his own, I suppose.
|
| https://www.ohchr.org/en/press-releases/2021/06/china-un-
| hum... https://theconversation.com/killing-prisoners-for-
| transplant... https://www.bbc.com/news/world-asia-
| china-54277430
|
| Other than these small misdemeanours, they're saints!
| Doubly so on the internet. /s
| user3939382 wrote:
| I'm still good on MacPorts. Seems I'm alone these days. Works
| fine for me.
| bdangubic wrote:
| honebrew works too :)
| 8b16380d wrote:
| Nah I've been on macports for years now. No problems; the
| community is very active, just follow the mailing lists etc
| paradox460 wrote:
| 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 wrote:
| There are dozens of us!
| blt wrote:
| 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 wrote:
| 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 wrote:
| 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.)
| scovetta wrote:
| Well done! And thank you to the Open Tech Fund for sponsoring
| work to protect everyone who uses Homebrew.
| marxisttemp wrote:
| MacPorts is always waiting for you with more packages, a better
| design, and Jordan Hubbard's history with BSD/Apple :)
| jagged-chisel wrote:
| so many projects release only formulas for homebrew. I keep
| both and try to use McPorts first.
| ggm wrote:
| Most homebrew users started in macports, or fink. Very few I
| talk to (admittedly not many and curmugeons) want to go back.
| eduction wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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
| azinman2 wrote:
| I much rather them use system libraries than build
| parallel libs that don't go through Apple's vetting /
| changes. This has worked well for me in practice. I've
| actually never run into an issue where the system library
| got updated and that broke homebrew's apps.
| eduction wrote:
| That seems like a totally valid perspective. Macports
| page I linked claims that Apple is often too slow to
| update, and in some cases only does so when there is a
| security breach. I can't vouch for if that's true. In my
| experiments maybe 10 yrs ago it took substantially longer
| for me to install a certain set of packages on Macports
| vs homebrew due to the parallel library thing. But I had
| had some broken packages with brew and found Macports
| more reliable.
|
| Does seem like something Apple should fund / handle IMO.
| dmd wrote:
| That was probably true in homebrew's first year. At this
| point I would be shocked if more than a fraction of a
| percent of homebrew users have ever even heard of macports
| or fink.
| ggm wrote:
| On reflection I think you are very probably right. I
| should have thought more about my origin story before
| posting.
|
| Once, long ago...
| atribecalledqst wrote:
| On an old Macbook I keep around for various rare offline
| tasks, I actually did go back to MacPorts from Homebrew.
| Chief reason being: Homebrew doesn't support old versions
| of the OS so I was SOL trying to install a new package on
| it. The backwards compatibility is a nice feature!
|
| My current machine is also not on the latest so I wonder if
| an attempt to brew update would nag me now...
| eviks wrote:
| It's also a worse design in some aspects, so not a clear winner
| remram wrote:
| For example?
| eviks wrote:
| - too much sudo friction
|
| - homebrew's design of having a single app's folder is
| better, e.g., can use your basic file manager to see the
| total size
|
| - updates requiring manual inervention
|
| - fewer/less updated packages (mabye due to the previous
| deficiency?)
|
| - large duplicate database wasting space (and think it's
| even uncompressed) (brew got better when it moved to it
| API)
| MilaM wrote:
| I was wondering recently if there are any downsides of using
| MacPorts and homebrew for different packages on the same
| system. Homebrew excels at keeping all my single binary CLI
| tools up to date, but I don't particularly like how it forces
| me to upgrade more complex software packages like MySQL or
| FFmpeg constantly.
|
| There is also the issue, that my iMac is stuck on Ventura, and
| soon won't be supported by homebrew anymore.
| Asmod4n wrote:
| The approach of Mac ports and Homebrew have been the complete
| opposite when Homebrew came into existence. Mac ports tried
| to make packages compatible with whatever Apple shipped, aka
| their own twists on Perl, python, OpenSSL etc. While Homebrew
| tried to make macOS compatible with whatever existed out
| there. As a developer Homebrew gave you a more up to date and
| fully functional experience. Can't tell you how it is today
| since Apple removed all interpreters and such from macOS.
| pmarreck wrote:
| 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), the
| overall guarantees make it worth it.
| bokchoi wrote:
| I also find the nix command line annoying. I'll give this a
| try. I like the embedded `#help` documentation!
| Brian_K_White wrote:
| 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
|
| (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 wrote:
| > 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/ (he
| still works on this and it is indeed very interesting!)
| pmarreck wrote:
| The help thing works great but it's on the verge of being
| over-engineered lol
|
| Helped that I'm good at regex lol
| pyjamafish wrote:
| I wish I had known about ixnay earlier! I also got annoyed of
| the user experience, to the point where I also wrote my own
| tool, hdn: https://github.com/seasonedfish/hdn
|
| I added a mention of ixnay to its readme :)
| pmarreck wrote:
| Thanks for the mention!
|
| I just noticed there's a bug with uninstalling. Probably a
| parsing issue, they must have changed the output of nix for
| that (this isn't the first time that happened...)
| arandomhuman wrote:
| 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 wrote:
| There have been a few attempts at this. I think some of them
| may even be working.
| megamix wrote:
| Is MacPorts not the same? Genuinely asking.
| sirn wrote:
| 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 wrote:
| 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 [2]
| https://github.com/kladd/pacman-osx
| nothrowaways wrote:
| Apple should have been the one funding the audit.
| CydeWeys wrote:
| 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 wrote:
| Apple would certainly favor macports over that rubbish ruby
| thing. Ports are from FreeBSD, MacOS is from FreeBSD.
| pxc wrote:
| Then why did Apple hire the creator of Homebrew to work on
| the package manager for Swift?
| saagarjha wrote:
| You should read
| https://en.wikipedia.org/wiki/MacPorts#History. But to
| answer your question: why not? Apple employs thousands of
| software engineers.
| dewey wrote:
| No need to call someone's free open source project
| "rubbish".
| latexr wrote:
| 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.1
|
| * 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.2
|
| * There's a liaison between Homebrew and Apple, who helped
| during the Intel to Apple Silicon transition.3
|
| 1 https://web.archive.org/web/20100908131627/http://develop
| er....
|
| 2 I know this from a reliable source and it is public
| information, but it was so long ago it's hard to find.
|
| 3 The official Homebrew Twitter account tweeted about this
| at the time. I no longer have a Twitter account so can't
| dig it up.
| arvinsim wrote:
| IMO, it's just counter to what Apple aspires MacOS to be.
|
| If they would do it all over again, I would bet that they
| would have wanted to make MacOS be like iOS.
| Lio wrote:
| I'm not sure.
|
| Back in the day Apple marketed macOS as a serious Unix
| system for scientists and engineers boasting about NASA's
| use of it.
|
| I think if Apple aspired to lockdown general purpose
| computing they would push the ipad pro range with more
| models and slowly kill off the Mac but they're not doing
| that.
| throw0101a wrote:
| > _Back in the day Apple marketed macOS as a serious Unix
| system for scientists and engineers boasting about NASA's
| use of it._
|
| They still jump through the necessary hoops to be
| certified as UNIX(r) with each macOS release:
|
| * https://www.opengroup.org/openbrand/register/
| robxorb wrote:
| > IMO, it's just counter to what Apple aspires MacOS to be.
|
| Every OS wants to be attractive to developers. Apple has a
| long history of underdelivering this core proposition. To
| me it's an odd situation to reason about - look at Apple's
| dev conferences and then look at what it's like on the
| ground in dev's reality.
| freep1zza wrote:
| What a nonsensical conclusion. Homebrew existing is no reason
| for Apple to do replicate that trainwreck.
| CydeWeys wrote:
| I thought it was clear from my comment that I was
| suggesting Apple would do it _better_. Think of how useful
| something like apt, npm, or pip is, and then realize that
| MacOS has no in-house equivalent.
| meindnoch wrote:
| >Apple should have written it themselves.
|
| Please don't. It would be a resource hog SwiftUI monstrosity
| like the new Settings app. And while they are at it, they
| would probably introduce the 46353th bespoke feature into the
| Swift language too, because why not?
| CydeWeys wrote:
| It would be (or at least have) a command-line utility like
| rpm, npm, apt, or pacman. That's necessary for it to
| integrate well with various installation scripts. So you
| wouldn't have to use a UI at all, especially if it's bad.
| sohrob wrote:
| 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 wrote:
| 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/
| mikemcquaid wrote:
| Workbrew wraps a vanilla, unmodified Homebrew on Macs running
| it under a 'workbrew' user for user privilege separation and
| better multi-user support.
| koito17 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ninetyninenine wrote:
| Nix also allows github.
| koito17 wrote:
| 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.
| duijf wrote:
| 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.
| tadfisher wrote:
| 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.
| efitz wrote:
| Were the reported issues all addressed by the Homebrew
| maintainers or are any still unmitigated?
| zargon wrote:
| https://brew.sh/2024/07/30/homebrew-security-audit/
| razodactyl wrote:
| 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.
| saagarjha wrote:
| I peeked at the sandbox escape bug and its associated fix:
| 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 wrote:
| 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/92fe7c7d42cc941ed70d6fce98...
| frenchman99 wrote:
| Surprised too, if that is the fix. Wouldnt a whitelist be
| better than a blacklist?
| tucosan wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| 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 wrote:
| 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 wrote:
| Thank you!
| mootoday wrote:
| 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
| charlie0 wrote:
| As someone unfamiliar with Nix, how is this better than
| Homebrew?
| mootoday wrote:
| 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 wrote:
| 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
| alberth wrote:
| > 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).
___________________________________________________________________
(page generated 2024-07-31 23:01 UTC)