Live data from Hacker News

Homebrew 1.1.0

brew.sh

111–120 of 216 posts

Re: Homebrew 1.1.0

#111
post #102
post #90

Earlier quoted context omitted.

That's not quite as bad as all of /usr/local, but still not great. Why "e.g."? What else is there? And why not just use /usr/local/homebrew or even better, a path determined by an environment variable? I don't mind giving you a user-owned directory to install things in. I mind very much being required to change system default security settings.

You can use a different directory, though some packages may be broken: https://github.com/Homebrew/brew/blob/master/docs/Installati...

Yeah, that's kind of the situation I'm in. So for any given package it's a crap shoot whether or not it will work. (And if it doesn't work, uninstalling it can be a real problem!) Hence my continued mixed feelings about homebrew in general.

Re: Homebrew 1.1.0

#113
post #90

Earlier quoted context omitted.

That's not quite as bad as all of /usr/local, but still not great. Why "e.g."? What else is there? And why not just use /usr/local/homebrew or even better, a path determined by an environment variable? I don't mind giving you a user-owned directory to install things in. I mind very much being required to change system default security settings.

We don't require you to take ownership of any directories that already exist when macOS is installed (i.e. `/usr/local` subdirectories but not `/usr/local` itself). Regardless of whether we should have picked another path, changing now would require rebuilding all our binary packages and that's a lot of effort with little return and almost certain breakages.

I haven't done a clean install of OS X in a long time, but I'm pretty sure /usr/local/bin exists. But even if it doesn't I don't find this a compelling argument. Having /usr/local/bin owned by root is a universally accepted standard in the unix world, and with very good reason: having /usr/local/bin owned by a user introduces security risks.

Re: Homebrew 1.1.0

#114
post #96

Earlier quoted context omitted.

Care to explain, or are you just rambling?

They phone home (to Google Analytics) by default: https://github.com/Homebrew/brew/blob/master/docs/Analytics.... It's pretty ridiculous. They're giving Google a map of everything individual users install. The only reason it's "anonymous" is that they're relying on Google to throw away personally identifying data before Homebrew sees it.

oh, so a 'echo export HOMEBREW_NO_ANALYTICS=1 >> /etc/profile' is too difficult?

Re: Homebrew 1.1.0

#115
post #43
post #37

Just a quick poll. Is anybody still using MacPorts or anything else? If so, why?

I still use macports! As for why, there are a couple of reasons. First, Macports is often the fastest at updating their ports database after new versions of an upstream are released. Next, I also like that Macports doesn't really rely on anything OS-X specific except for Xcode. So I don't need to worry about crap like whether some Python package will work with Apple's Python distribution, or whether installing a new…

> I don't need to worry about crap like whether some Python package will work with Apple's Python distribution

This is exactly why I use Macports. Everything lives in a parallel universe of /opt. This means the first few packages you install take WAY long as they pull in a ton of dependencies; Homebrew avoids this by relying on stuff already installed by the system. But the up-front cost pays off in the long run (IMO) since you face fewer issues with breakage. OS X can update its userland tools and you generally don't care.

Re: Homebrew 1.1.0

#116

Earlier quoted context omitted.

(Reaching back into foggy memory...) The last time I installed Homebrew, I think I had the problem that `/usr/local/bin` didn't exist, and I didn't have write permissions for `/usr/local/` so I couldn't create it (w/out sudo/chown) etc. This, using Sierra. Does that seem likely? Usual? What's the ideal solution?

You need to use `sudo` as a one-off thing when you install Homebrew. Our installer does that for you otherwise we'll prompt you with `brew doctor`.

Why don't you have your binaries installed in a user-owned directory like ~/brew or whatever, and then put that at the front of the path? Asking people to `chown` a system path is plainly a contravention of the principle of least privilege.

Re: Homebrew 1.1.0

#117
post #37

Just a quick poll. Is anybody still using MacPorts or anything else? If so, why?

Macports. It works and does what I need it to do. I switched to Mac from Linux, and with that background it was unnerving to see a system deliberately written to install non-root-owned files in /usr, so I ruled Homebrew out. I've always found it puzzling that people ask whether anyone "still" uses Macports, as though it is some decrepit thing. Homebrew is the one that seems strange to me.

My thoughts exactly.

I'm a daily linux user, but occasionally some job requires me to use a Mac. Every time I see some OSX tool that starts with the premise of "just go ahead and `sudo chown` a system location and then curl this script into a `sudo bash` pipe" I just think to myself, if they care so little about security to not get the easy stuff right, can I really expect them to nail the hard stuff?

Usually not. I'll have to give Macports a try. As I understand it, it's an implementation/port of the BSD ports system, so I'd expect it to have a more solid foundation.

Re: Homebrew 1.1.0

#118
post #108

Earlier quoted context omitted.

> Instead, to instal in /usr/local it wants me to recursively chown /usr/local to myself, which is a Really Bad Idea (tm). Why is this a really bad idea for a personal machine? The only problems I can think of are some subdirectories that are conventionally given some other user ownership to make running a related server under a specific user, and the problem of putting potentially arbitrary probably unreviewed execu…

> Why is this a really bad idea for a personal machine? It's a security risk. Having user access to /usr/local allows me (or, more to the point, an attacker running as me and not root) to surreptitiously replace system binaries, some of which may be run by other users. Some of those other users may have access to parts of the system that I don't have. Some of those other users may even be running as root. > What's th…

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...

Re: Homebrew 1.1.0

#119
post #64

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…

I have the same concerns and have been using Nix for my Mac package manager [1] instead. Functionally it's far better, though with far fewer packages available currently.

[1]:https://news.ycombinator.com/item?id=11772686

Re: Homebrew 1.1.0

#120
post #114

Earlier quoted context omitted.

They phone home (to Google Analytics) by default: https://github.com/Homebrew/brew/blob/master/docs/Analytics.... It's pretty ridiculous. They're giving Google a map of everything individual users install. The only reason it's "anonymous" is that they're relying on Google to throw away personally identifying data before Homebrew sees it.

oh, so a 'echo export HOMEBREW_NO_ANALYTICS=1 >> /etc/profile' is too difficult?

Yes. Privacy should be the default.
Post reply on HN