3 ms·

It's not written as if Homebrew developers are forcing you to use it. It's written from the perspective of someone who doesn't really want to use Homebrew but s

by jchw 4y ago

It's not written as if Homebrew developers are forcing you to use it. It's written from the perspective of someone who doesn't really want to use Homebrew but still does so as a result of some decision calculus but finds it frustrating to use. If you find the tone to be too aggressive or unfriendly, that's fine. But also, in the same token, I don't think it's fair to invoke the "you don't have to use it" argument for fairly reasonable frustration. It's also not obligatory that anyone take someone's rant personally, after all.

acdha 4y ago
That’s a very charitable reason: this post is long on unsupported allegations starting with the title and boils down to the author not understanding security as well as he thinks and claiming it’s Homebrew’s fault that something unsupported requires more work.
- jchw 4y ago
  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.)
  - acdha 4y ago
    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”.
    - jchw 4y ago
      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.

by jchw 4y ago

acdha 4y ago

That’s a very charitable reason: this post is long on unsupported allegations starting with the title and boils down to the author not understanding security as well as he thinks and claiming it’s Homebrew’s fault that something unsupported requires more work.

jchw 4y ago
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.)
- acdha 4y ago
  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”.
  - jchw 4y ago
    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.