I strongly recommend to consider switching to macports or pkgsrc or nix as your package manager. And/or possibly just using a linux VM as your development environment, such as NixOS.
I'm sympathetic to the idea that sometimes software "updates" in fact introduce regressions, but there's a reason that one of the most universal traits among security professionals is "keeping automatic updates enabled".
Surely the appropriate course of action is to fork a project rather than to just run outdated versions?
Forced & default automatic updates have a long-term consequence of reducing fragmentation of the software landscape, ultimately leading to a reduction in the degrees of freedom for the end user.
Developers love this, but on the flip side they're gradually losing personal control over their computers and operating systems and software as a result.
Let's say there's a small piece of software you want to install. A command-line PDF-processing utility, or something. You use brew to install it.
brew decides to update everything. Let's say (not an arbitrary example) this includes OpenSSL. It removes the old OpenSSL.
Everything you built which somehow depends on OpenSSL (and that's a lot of stuff) is now broken. If it was just Homebrew installs, that would be fine, because they'd be upgraded too[1]. But it isn't. It's everything you've built from source which linked against the former, Homebrew-installed OpenSSL.
You now have to spend the rest of the afternoon rebuilding and reinstalling stuff because Homebrew decided to trash a library that it had previously installed... all because you wanted to install one tiny command-line tool.
This has bitten me, and many others, countless times. Here's two examples from a minute's Googling about the OpenSSL issue: https://github.com/kelaberetiv/TagUI/issues/635, https://github.com/kelaberetiv/TagUI/issues/86. But it's far from an isolated case - I've had stuff break on me because brew has decided to upgrade proj, for example, and the newer proj headers aren't backwards-compatible. (Pretty much all open-source geo stuff depends on proj somehow.)
In theory you can brew pin stuff. But either I brew pin everything, or I need a crystal ball to decide what brew will break next. OpenSSL? proj? Postgres? I honestly wouldn't have worked those out for myself.
I am not installing Homebrew on any Mac I own in the future.
[1] In theory. I've had Homebrew make an entire Postgres database unreadable due to an arbitrary, and unwanted, upgrade. Fortunately I was saved by recovering the old data files into Postgres.app, which can run different versions of Postgres.
I've been ruminating on making the switch to nix, you might already be familiar with it, but if not, here's an article I came across:
https://wickedchicken.github.io/post/macos-nix-setup/
Reproducible builds are super appealing: "Nix builds packages in isolation from each other. This ensures that they are reproducible and don't have undeclared dependencies, so if a package works on one machine, it will also work on another."
As is the focus on reliability: "Nix ensures that installing or upgrading one package cannot break other packages. It allows you to roll back to previous versions, and ensures that no package is in an inconsistent state during an upgrade."
From https://nixos.org
- mac-arm-support has just happened in Nix, with comments like "neovim does not work on m1" 2 weeks ago ( https://github.com/NixOS/nixpkgs/issues/95903#issuecomment-8... ). it works just fine in homebrew.
- when installing it on a new mac, you need to use the "--darwin-use-unencrypted-nix-store-volume" switch, which does not inspire confidence (and yes, the documentation points out that on mac computers with T2 chip this still creates an encrypted volume or something, the point is, when installing homebrew i do not have to tell it to do something unencrypted)
- sometimes you get the feeling that nix-on-mac is less important than nixos. like, the whole problem with that "--darwin-use-unencrypted-nix-store-volume" thing is because nix wants to live in the "/nix" directory, and apple does not like that. you could install nix into an another directory and have no apple-problems, but the rest of the nix-ecosystem standardized on "/nix", so if you do that, you get no binary packages etc. with homebrew, you get a package-manager that is focused on macos, it does things the way that makes it easy to use on macos.
still, the advantages of Nix are very impressive, and i'll keep looking at it, i just wanted to balance out all the overly positive switch-to-git articles a little :-)
(NOTE: all this info is from following nix-related topics for a couple months. i did not install nix on mac yet.)
For example, they included their repo github API key in their publicly accessible jenkins site, which meant that anyone could make a commit to the repo, which would be instantly used by anyone going forward:
https://medium.com/@vesirin/how-i-gained-commit-access-to-ho...
Buuuut hands-down the real clown-shoe reason nobody should run brew is that it modifies /usr/local to be user-writeable so they can be exceptionally lazy and install everything as the user.
Guess what's at the top of /etc/paths? /usr/local/bin.
Any script or program you run, anyone who sits down at your computer for less than a minute, can pwn you without any fancy hax0r tricks...just by adding a binary or script with the same name as a command from /usr/sbin/ or /usr/bin. You'd likely never know or notice unless you happened to run 'which', get unexpected behavior from said binary/script, or notice weird shit in ps/Activity Monitor. Imagine a script or binary that pretended to be ssh and politely passed along everything to the real ssh binary while also sending your keys, passphrases, etc to a remote host.