Apple should close this gap and I am puzzled why they have not done that yet. Because even for iOS development people need things beyond the xcode toolcahin and they resort to either of the available options. Homebrew is just one of them.
Not only cli app store but the mac app store also badly needs some love.
In 2023 I want Apple to stay as far the hell away as possible from App and package management as possible on my Macintosh. I don’t have the same hang ups on my iPhone, but I don’t want a merger of policies and incentives between the two platforms either.
A company like Apple could kick whatever money to an OSS project and write it off as charity for taxes, I think for that matter.
Homebrew specifically stops you from doing stuff as root. It asks for your password once at install time so it never has to do it again.
Homebrew, as the name implies, was built for hobbists with little regards for security. Not a problem for many, but it does make it incompatible with a corporate environment.
The goal posts definitely seem to be moving over the course of this thread?
Either way, I think bad default folders is better than bad default security practices. Most package manager forces you to use sudo to run them as root, and I think that's much much worse in terms of security practices and encourages the wrong behaviors and potentially allowing build/install scripts to wreck havoc on your system. (Note that /opt/homebrew is not world writable as you suggested. It's only writable by the user)
Instead, Homebrew prefers to run in a user account, default to yours. If you have a multi-user computer, you can install Homebrew to a local user folder to have isolation and not using a global location like /opt/homebrew, or you can make a special Homebrew user account (rather than using root), which is what the docs suggest (https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad).
I don't think the current solution is perfect, but I do think the motivation to prevent usage of sudo is correct in terms of security. In fact, I would argue that the other package managers that use sudo are taking the easy way out (albeit insecure).
I've even considered donating a Mac mini or something - but not to the point that I've yet emailed the macports list to ask how I could do that...
Ed: see
If you install untrusted code, it can do nefarious things.
No platform can save you from yourself.
Specifically, I would expect two things:
1. In general, macOS .app bundles should be able to “provide” a bin/ directory that gets added (appended, not prepended!) to your PATH while you have the package available on disk + non-quarantined. Just like .app bundles can “provide” file extension bindings that cause things to open in them. (And probably, just like with file extension bindings, you’d want to give the user the same “this is a program downloaded from the Internet…” Gatekeeper warning the first time a command-line invocation causes the user to end up running an executable from a given .app package, if the .app hasn’t yet been Gatekeeper-blessed.) Kind of surprised this hasn’t always been a thing since NeXTSTEP, actually.
(And, ideally, rather than needing to care about PATH ordering re: these applications’ exposed bin/ executables, instead make a generic system for interactively choosing preference-ordering, like Debian’s update-alternatives(1) but as a per-user runtime-bound preference.)
2. The App Store should allow at least apps that contain both GUI and CLI versions (e.g. gVim packaging its own command-line `vi`; or Sublime Text with its `subl` command) — where all the same capability-manifest sandboxing applies to the command-line executables that applies to the GUI app; and where the CLI version of the executable linker-loader is made slightly smarter re: auto-granting capabilities, such that if you e.g. pass a file or directory path as a command-line argument to a CLI program, then that CLI program should be auto-granted a capability on that file/directory during that run.
macOS also doesn't have a way to tag a command line application to have sandboxing, as sandboxing only works for an "app" bundle, not random executables.
This isn't really a Homebrew problem anyway. If there is this magical sandboxing capability that works, nothing stops a Homebrew package from using it.
This is a genuine question: what is your threat model, and what security policies would you like to see? It's hard to imagine a threat model that assumes an "evil version of brew" that doesn't also prevent you from installing any third-party software on your machine. Malicious packages are always possible, but Homebrew's integrity checks do an adequate (but improvable!) job of making such attacks auditable; I'm not aware of any successful supply-chain attacks mounted against Homebrew users.
I have a lot of experience with various package managers, and Homebrew is not particularly out of band with its peers (which should be read, partially, as a general indictment of packaging practices).
However I don’t understand what makes Homebrew reliable. Homebrew is a non-profit project run entirely by unpaid volunteers.
I trust repositories controlled by corporations (RHEL, Ubuntu) or properly(?) governed non-profit organizations (Debian) more. Also I trust App Store more, because of sandboxing, static and dynamic analysis.
The App Store exists primarily to distribute proprietary applications. Homebrew exists primarily to distribute open source packages. Comparing the two (and Apple's justified focus on sandboxing, etc.) feels like a mismatch.
I strongly disagree with this stance, and it's a very authoritarian one at that. The common people can't be trusted with freedom so we should give up that freedom and trust in <insert authority here>. I find this stance morally repugnant and entirely at odds with where the future of technology should be going.
Tl;Dr: Hard disagree. Some of us prefer to use our computers as general computing devices, as opposed to just being desk-driven iPhones.
The alternative is to run VMs/containers/etc for each project. But at that point, it will the beginning of the end for Apple's software, cause you're esentially running linux and using macOS as a terminal/thin client.. (Unit) devtools is how they got big with OS/X, and I think they sometimes forget this.
I use a Macbook for work, and every day I go without having to create an AppleID is a good day.
What I want is a dang CLI package manager, and Homebrew is pretty alright at that. No, it's not perfect, but it's far better than anything Apple has done related to app stores.
It installs itself in /opt/local, it respects the Apple SIP.
Homebrew basically sucks, because it doesn't follow Unix conventions and it doesn't follow MacOS conventions.
Macports has both pre-compiled and build-from-source, supports current and past MacOS releases, uses xcode/clang for compilation, supports port variants and multiple versions installed in parallel (with "port select" to choose a default) etc etc.
Not sure why people use anything else.
I think this will also hurt the Mac platform. I wish Apple would invest some effort into building an App Store for cli programs. While it may be complicated for the community(require signing, sandboxing, developer effort), it is likely to have better security guarantees than Homebrew.