While I use Homebrew on my Mac — it is a major risk. I am afraid that the project is not following strict security policies and will be compromised at some point. Evil package or evil version of brew can steal or modify my data.
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.
> While I use Homebrew on my Mac — it is a major risk. I am afraid that the project is not following strict security policies and will be compromised at some point. Evil package or evil version of brew can steal or modify my data.
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).
It is not feasible to avoid installing any third-party software. Moreover I admitted that I use Homebrew.
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.
I don't understand the distinction you're making between Homebrew and other non-profit OSS orgs: Homebrew has a documented governance structure[1] and is hosted under a non-profit foundation.
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'm not a very technical person, but I think MacPorts adheres better to macOS standards and security practices. (At least it asks my admin password before any major interaction.) Been using for a few years, coming from Homebrew, and it's running smoothly.
By default, Homebrew requires world-writeable location in the PATH (doesn't matter if it's /opt/homebrew or /usr/local). In my opinion, this isn't a sensible choice.
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.
It does matter though? /opt/homebrew is specifically used by Homebrew, whereas /usr/local is kind of a more shared location that old Homebrew hijacked.
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).
MacPorts drops elevation on package installation, so no, sudo is a better way than globally messing with the permissions and writing a confused FAQ about it
I just whish macports had buikdslaves for m1/m2 architecture. It's just too much to have to rebuild clang and gcc (as build deps) on every other upgrade...
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...
Or just hire a few FTEs to properly support and maintain the CLI. Pull in new FreeBSD base at releases if they really want to axe their overhead. It's always just read as absolutely lazy how slowly the CLI progresses. Hire a few more and they could absolutely offer a package repo. This company dwarfs Red Hat prior acquisition.
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.
Same here.. I just want a default sandbox (no network + only file access to it's subdirectories)
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.
They have, it's called Macports. It started as a port to Darwin of the existing *BSD ports and (I believe) is subsidized by Apple.
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.
No thank you. I don't want a walled garden where Apple has absolute authority to enforce anti-competitive policies like they do with the existing App Store (especially on iOS), and where they require you to pay an annual fee to publish anything, and where they tie everything to an AppleID.
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.
By this logic, the ability to install arbitrary software is a major risk.
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.
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.
I think the idea is that there should be an option to have Apple-App-Store-audited capability-manifest-sandboxed CLI apps with auto-updates, as well as untrusted, non-sandboxed CLI apps.
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.
Most packages that Homebrew install just wouldn't fit nearly into the kind of sandbox model that you suggested. Just think about command-line applications that can take in any file as input and process them, e.g. Git, ffmpeg, etc. Or like a compiler like clang. Even for GUI apps most Mac applications do not use sandbox / App Store because it's actually quite difficult to work within that framework for a lot of types of applications.
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.
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.