I have very mixed feelings about homebrew. When it works, it is awesome, but when it doesn't it can be a serious nightmare. In particular, homebrew refuses to run under sudo. Instead, to instal in /usr/local it wants me to recursively chown /usr/local to myself, which is a Really Bad Idea (tm). I have mostly stopped using it for this reason. I understand that running a program that runs third-party scripts under sudo…
Homebrew 1.1.0
171–180 of 216 posts
Re: Homebrew 1.1.0
#172Earlier quoted context omitted.
Other than being in a different directory, what difference is that going to make? You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen. Also you can actually install it wherever you like, this is just the default/recommended location: https://github.com/Homebrew/brew/blob/master/docs/Installati...
/usr/local/bin is a global resource populated by binaries run by many different users including root. Making it user-writable opens the door to privilege escalation attacks by replacing binaries that are then run by other users.
Re: Homebrew 1.1.0
#173I'm going to ditto the positive comments. Kudos to the maintainers - not just for the package itself but for growing it. They successfully went from a hacky page with some scripts, to a big giant repository, to multiple repos, to a fully fledged mature best-practices package manager for macOS with all the bells and whistles. The sign of a great project isn't just that it does one thing well, but that it grows with th…
Thanks for the kind words. You'd be surprised how motivating they are. <3
Re: Homebrew 1.1.0
#174Earlier quoted context omitted.
Ditto. I install almost everything via brew and brew cask, and store the list of packages in git. It makes setting up a new machine a breeze. Thanks for all your hard work!
This is a cool idea! How does one go about doing this though? Is there a flag to output a text file with the names of installed versioned packages?
Re: Homebrew 1.1.0
#175Re: Homebrew 1.1.0
#176Earlier quoted context omitted.
What are those risks?
/usr/local/bin is a global resource. It is generally full of binaries that get run by many different users including root. If a regular user can replace those binaries the result is a privilege escalation.
Re: Homebrew 1.1.0
#177Re: Homebrew 1.1.0
#178Just a quick poll. Is anybody still using MacPorts or anything else? If so, why?
Nix package manager on my Mac [1]. Deterministic builds, plays well with POSIX/UNIX, though fewer repo's available than Brew and others. [1]: https://news.ycombinator.com/item?id=11772686
For example, I want to search for a package name before installing. I'm guessing it's just "brew search pkg"... yup. Now what do I do with nix? Google says it's "nix -qa pkg", that totally makes sense, and I just love how I have to memorize some arcane letters.
This is true for virtually every linux package manager I've tried (wtf is apt-cache? I can't remember pacman commands after using it for a year). Seriously, typing anything with a minus sign is slower than typing word, so what's even the point? At this point I won't (choose to) use a package manager that doesn't get this right.
Re: Homebrew 1.1.0
#179Earlier quoted context omitted.
/usr/local/bin is a global resource. It is generally full of binaries that get run by many different users including root. If a regular user can replace those binaries the result is a privilege escalation.
which programs from /usr/local/bin get run by root under current macOS?
Re: Homebrew 1.1.0
#180Earlier quoted context omitted.
/usr/local/bin is a global resource populated by binaries run by many different users including root. Making it user-writable opens the door to privilege escalation attacks by replacing binaries that are then run by other users.
Why would using /opt/homebrew/bin stop these sorts of attacks?
But you're right: to really fix this problem requires that homebrew change its installation process entirely.