The repo owner was stupid for not checking what they were merging, and the author is stupid for making the pull request in the first place. If they wanted to prove a point, they should have merged something a little less harmful, like "echo This file could have deleted your home folder. Don't run random scripts from the Internet without inspecting them first."
Wow, how disappointing. And poor title to describe a very bad decision by a human being, not a movement. This has nothing to do with open source, and everything to do with human nature. Someone on the inside of a closed source project with commit rights at a company with a poor review process could just as easily have done this to make some kind of point. Same result.
Furthermore, I can't possibly audit every single line of every open source project I run on my personal machine. Did you review every line of the last distro you installed? A python package installed via pip can just as easily 'rm -r ~' as a bash script can, as can a vim plugin, etc. etc. In the end, it often comes down to trust, and credibility.
I'm not sure I understand with how you got to "entirely". Yes, his pull request was dangerous but it also reveals how the repo owner would accept just about any pull request you send him. That seems like a major issue. I'm sure both parties involved will not make these mistakes in the future.
I get the impression he was not expecting that pull request to get merged. This was silly, but not malicious. He wasn't trying to delete home directories to prove a point: the point he was making was directed at the repo owner.
Meanwhile, merging that pull request seems downright stupid, but maybe there are mitigating factors I'm not aware of?
Don't issue pull requests that you don't want merged. It's really that simple. The maintainer could easily merge it by accident by absentmindedly clicking the button they normally click in response to well-formed pull requests while thinking they'd rejected it. Maybe they have a cat, or a toddler, who knows?
Don't put your name on stuff you don't want merged.
Sometimes the hard way to learn the lesson is the best way and sometimes a costly mistake by someone is an education for lots of people. It's an unfortunate side of human nature but it's valuable.
My own experience by proxy: A colleague of mine kept everything he owned on a single CDRW. It got put in a Pioneer slot loader. A few seconds later "boom" and the disk shattered into thousands of small pieces. He cried. I, and the 15 other people in the room, learned about keeping backups in multiple locations.
The same thing happens when a seal eats a penguin. Hundreds of other penguins learn to keep away from seals.
It's a shame, the fact that he decided to rm -rf ~ has hijacked the point he was trying to make in the first place. Now everyone's discussing if there's a better way of making his point rather than downloading random scripts on the internet and running them.
And the dramatic irony is: he tried to warn people that bad things can happen if they run scripts without verifying... by doing _exactly_ what he is warning about -- doing malicious stuff to you. It wasn't well thought out, was it?
Lesson: one can make a point without deleting someone's home directory... (or something equally evil)
He saw someone making a careless rookie mistake, who quite obviously didn't really understand what they were doing, and equally obviously didn't understand how dangerous it was, and then deliberately put a live landmine in their way.
He then posted to his blog saying how shocked, amazed and not in any way responsible he was for the resulting explosion.
Haha. Next time if you are just trying to make a point to the open source maintainer who's supposed to be reviewing your pull request, write the payload but comment it out so it doesn't actually do anything.
The real lesson here is DON'T MERGE PULL REQUESTS YOU HAVEN'T LOOKED AT.
Also the owner of the script saying that the person should not made a pull request (and a issue) instead is missing the point, not that I agree with a dangerous pull request (in case the owner of the repository is crazy), but the owner of the repository merging the request just because it was a request (instead of a issue) sounds like someone wishing to shit to happen.
It would be like pushing a wedge into the train tracks and blaming the guy (that also had the bad idea) to put the wedge near the tracks.
Among people gullible enough to download and run executables containing random unknown content, the blogger has now lost some personal credibility, but the good news is the gullible will continue to download and run executables containing random content because they see the story as an individual social norms violation, not a miserable systemic failure. The blogger was successful in that had he not submitted a rm -Rf and then publicized the story, the problem would not be discussed at all, but it was a failure in that the story only resonates with those who already don't care about security.
This is one of my pet peeves of late - so many tools and tutorials advise the user to curl and pipe some script of the net to install and make it work.
Why aren't we teaching people to be a little cautious - to download, review and then install?
How did developers become so lazy, and so coddled that we desire convenience over security or forethought?
Or worse, is it really due to an increasing number of developers who are unable rather than unwilling to review scripts, tools or libraries before use.
Do we need a new movement for 'the literate programmer', that emphasises the need to learn than just the core language or framework or ecosystem that they are using?
The Underhanded C Contest was a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake. The contest rules define a task, and a malicious component. Entries must perform the task in a malicious manner as defined by the contest, and hide the malice.
I could download their install script, read it through and then proceed to run it
Since I'm trusting rvm not to do any harm in the first place, I might as well use their handy one-liner and install it in one go. Anything they can do in their one-liner they can do to me when I install rvm anyways.