4 ms·

For what it’s worth, Homebrew responded by entirely removing the automation, not just patching the specific vulnerability: https://brew.sh/2021/04/21/security-i

by btown 6y ago

For what it’s worth, Homebrew responded by entirely removing the automation, not just patching the specific vulnerability: https://brew.sh/2021/04/21/security-incident-disclosure/ https://brew.sh/2021/04/21/security-incident-disclosure/ To me this means they take the class of threats seriously. And in the first place, automating version bumps could actually improve availability of security hotfixes for brew-installed software, so it’s consistent with a good faith security stance. And, to be fair, there are plenty of NPM repositories with far fewer qualms about pushing untrusted code in dependencies to dev machines...

jacquesm 6y ago
NPM shouldn't be up for serious consideration as part of anything that needs to be secure after their series of incidents like these. If that's the new standard that is problematic.
- tenacious_tuna 6y ago
  I think it's less about using NPM as a good-practice model, and more just as an example of a widespread tool with worse flaws. Not an excuse, just a comparison.
- btown 6y ago
  https://github.com/stripe/stripe-js https://github.com/stripe/stripe-js strikes perhaps the most realistic balance possible, recognizing that NPM is an insecure place for their core JS logic that creates a PCI compliant iFrame, and so their NPM package is just a loader for a script tag hosted securely. And yet they encourage people to use NPM for the wrapper itself. Which is just as vulnerable to supply chain attacks as anything else on NPM. If this isn't tacit acknowledgement of a "new standard" I don't know what is. I absolutely agree that it's problematic.
aequitas 6y ago
This also makes the default auto update behaviour of Homebrew itself a double edged sword. On the one end it ensures people run into less issues because Homebrew is always up to date but on the other end an RCE like this will be propagated to every user automatically within a really short time.

by btown 6y ago

jacquesm 6y ago

NPM shouldn't be up for serious consideration as part of anything that needs to be secure after their series of incidents like these. If that's the new standard that is problematic.

tenacious_tuna 6y ago
I think it's less about using NPM as a good-practice model, and more just as an example of a widespread tool with worse flaws. Not an excuse, just a comparison.
btown 6y ago
https://github.com/stripe/stripe-js https://github.com/stripe/stripe-js strikes perhaps the most realistic balance possible, recognizing that NPM is an insecure place for their core JS logic that creates a PCI compliant iFrame, and so their NPM package is just a loader for a script tag hosted securely. And yet they encourage people to use NPM for the wrapper itself. Which is just as vulnerable to supply chain attacks as anything else on NPM. If this isn't tacit acknowledgement of a "new standard" I don't know what is. I absolutely agree that it's problematic.

aequitas 6y ago

This also makes the default auto update behaviour of Homebrew itself a double edged sword. On the one end it ensures people run into less issues because Homebrew is always up to date but on the other end an RCE like this will be propagated to every user automatically within a really short time.