Comment by jchw | Hacker News Reader

Comment by jchw | Hacker News Reader

Parent Full thread

Well, I find it pretty frustrating when software on my machine breaks due to namespace pollution that happened automatically and without warning. Some MSys distributions do similar things on Windows, and I find it no less agitating (To be fair, at least Homebrew doesn't generally override e.g. system utilities with GNU utilities, and is somewhat careful about it, but it nonetheless does generally require itself to be on $PATH iirc. Still, my build processes regularly pick up things like Homebrew OpenSSL completely unintentionally...)

Ignoring the security issue for a moment, though, I think it is genuinely quite irritating that Homebrew doesn't support installing in a more self-contained manner. I'm not saying Homebrew developers did anything wrong to me personally or that they are obligated to work on the problem, but the other edge of that sword is that I don't have to like it either. It can be done, as shown, but it is pretty intentional about not supporting this workflow. I think that's a bummer.

(P.S.: I honestly didn't really grasp exactly what they were complaining about, but if they are trying to enforce a setup where the only binaries in the default shell $PATH are in directories that are not world-writable, that really does seem like a totally valid security mitigation.)

I mean, yes, namespace pollution is a problem but Homebrew goes to a fair amount of effort to avoid that. I have to add things like OpenSSL, etc. to my direnv for projects where I want to use those instead of the system versions and they support using /opt/homebrew on older systems, too, for people who don't mind skipping bottle builds.

> if they are trying to enforce a setup where the only binaries in the default shell $PATH are in directories that are not world-writable, that really does seem like a totally valid security mitigation.

Think about what threats you're concerned about. Homebrew installs are writable only by the user who installed them and members of the admin group. If you're not on a system with other users, this doesn't matter: someone who can run code or drop files into arbitrary locations as you can already do whatever they want (e.g. maybe you lock down /usr/local but do they even care as they drop something into your .profile or LaunchDaemons?). That's why Apple has worked on the various sandboxing methods because this model is too brittle.

If you are on a multiuser system, this could be a way to move sideways but it comes down to the question of how likely it is that an attacker would compromise the admin user who installed Homebrew without getting the ability to use their administrative privileges. That's certainly possible but it seems relatively uncommon and that's part of why I think it's a huge stretch to go from “there's an obscure edge case I want to hit” to “These people who've given me thousands of hours of their work for free are bad neighbors”.

I agree that this particular security mitigation is probably of limited usefulness in this scenario, because it's on macOS, and because the $PATH is likely only modified for the current user. (Maybe it was actually a bigger issue when Homebrew used /usr/local instead?)

However, I will hold that this mitigation in general still can be useful. After all, not every security issue is actually full remote code execution. There's plenty of security issues that allow you to write files somewhere; for example, path traversal bugs in PHP scripts, archivers, Git, etc. If being able to write files somewhere allows you to escalate privileges to another higher privilege user transparently without user input by overriding something on the $PATH of a cronjob, that really is an issue. Mitigating this risk on its own obviously doesn't net you a secure system, but as part of a security moat of sorts, it is certainly not useless.

> That's certainly possible but it seems relatively uncommon and that's part of why I think it's a huge stretch to go from “there's an obscure edge case I want to hit” to “These people who've given me thousands of hours of their work for free are bad neighbors”.

I guess I didn't take the phrasing "bad neighbors" to be all that hostile. It's certainly a curt way to complain about namespace pollution, but honestly, it does seem like an apt description of namespace pollution. If you want me to agree that it would be better if the tone of the memo were more forgiving, I do agree; but also, it does just seem like a frustrated rant, and it doesn't seem like it is aimed to personally attack anyone. I think that as an open source dev, while obviously everyone is human and has their limits, it's probably best to try not to take it personally as much as you can stomach it.

re: OpenSSL. I honestly think this might be the fault of Homebrew pkg-config being in my $PATH, or maybe a CMake find script just goes out of its way and it's not Homebrew's fault at all. Not sure. But, I did actually run into it at one point, and now I am very paranoid about ldd'ing macOS binaries I produce when the machine has Homebrew installed. Whoever's fault this is ultimately doesn't matter too much, but it sure is frustrating.

> Mitigating this risk on its own obviously doesn't net you a secure system, but as part of a security moat of sorts, it is certainly not useless.

No, that's why people keep talking about multi-user systems. On a developer workstation it's almost pointless. If people were running Homebrew on servers and it defaulted to allowing other users to write to its directory, he'd have more of a point but since the former isn't common and the latter isn't the case, it's not really helping anyone to present this in such bold terms.

I don't really have much to say to that since I did actually try to acknowledge this, honestly!

> I agree that this particular security mitigation is probably of limited usefulness in this scenario

> If you want me to agree that it would be better if the tone of the memo were more forgiving, I do agree

Not trying to be condescending by quoting myself here, but we're basically already at an agreement; The linked post has some issues.

Reply on news.ycombinator.com