I could just as easily embed something like that in any code on any open source project in any language as part of the installer or the main code base.
You can limit the damage by keeping backups, and running software you don't really trust under a limited account. The latter is understandably more difficult with certain applications, but it's once again one of those security-usability tradeoffs.
I basically avoid installing much in the way of new software as much as I can, as my existing setup does what I need, and anything new gets subjected to careful scrutiny first, but this is not a workable solution for everyone. Nevertheless, I can see how those with an attitude that makes them very eager to install and try new software could also make them more vulnerable to things like this.
Bingo... pretty trivial to stick an `rm -rf /*` shell call somewhere in your code. Not sure what difference it makes whether it's in a package manager file, or the code. Lesson... read the code before running it.
Title of the post should be "Running code you haven't read can be dangerous"
A lot of people using package managers, though, might think that someone else has read the code that's about to be installed (so they don't have to read it before installing it). I've installed five or six things for development work using pip recently and I would have been shocked if they were malicious (or if I had to read thousands of lines of Python to make sure they weren't malicious).
It is interesting the contrast in cultures between developers and "hackers" it was not uncommon to hear about script kiddies picking up code and realizing later that a rm rf line was contained in the file. The common reaction to a scenario like that would be well the script kid got what he deserved. However, there is a fringe within that group that is more interested in testing these thing in VMs (so the damage would be minimal in that case). However when a security issue is brought to light like this and the only difference is the intentions of the user the arguments are so completely different. Script Kid downloads rm rf script and runs HAHA! Javascript Developer downloads package and runs blindly "well who let that happen and how do we stop it from happening again" hopefully some HN reader can respond to this to succinctly convey the philosophical mechanism going on here as I cannot quite place it.
Maybe the script kids think that they're playing One-Shot Prisoner's Dilemma (or occasionally Iterated Prisoner's Dilemma) and the developers think they're playing some other game?
Thanks for the reference schoen this is why I love HN. I sometimes have difficulty organizing thoughts into neatly categorized theories like this, best I can usually do is realize i'm sure somebody has thought about this before and explained better than I can.
https://news.ycombinator.com/item?id=8896186
https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...
You can limit the damage by keeping backups, and running software you don't really trust under a limited account. The latter is understandably more difficult with certain applications, but it's once again one of those security-usability tradeoffs.
I basically avoid installing much in the way of new software as much as I can, as my existing setup does what I need, and anything new gets subjected to careful scrutiny first, but this is not a workable solution for everyone. Nevertheless, I can see how those with an attitude that makes them very eager to install and try new software could also make them more vulnerable to things like this.