News for hackers. Stuff that matters.
Re:What NPM should do to stop a new colors attack by sigzero on Monday January 10, 2022 @08:10PM (#29885712)
Of course it was an "attack". Is doesn't matter that he owned his own packages. He knew exactly what he was doing with his changes and the effect it would have on projects that relied on his.
Re:What NPM should do to stop a new colors attack by datenarsch on Monday January 10, 2022 @08:29PM (#29885904)
It's his project. It's your fault if you blindly trust random 3rd-party code on the internet and have your mission-critical software depend on it.
Re:What NPM should do to stop a new colors attack by dathinab on Monday January 10, 2022 @09:57PM (#29886808)
> It's his project.

If you publish software you have responsibilities and no "provided as-is" clause can fully free you from it. Especially if you do so with the intention to cause harm.

> It's your fault if you blindly trust random 3rd-party code on the internet and have your mission-critical software depend on it.

The problem is not to "rust random 3rd-party code on the internet" but the "blindly" part.

Like never ever deploy without locking dependencies and testing any new dependencies before updating the lock and preferable even give the changes/diff a shallow review.

I think anyone providing programs (instead of libs) installed though npm (or "blind" untested CI builds for releases) is as much a problem as the one who caused the problems this time. Maybe even more as they also open the door for other more malicious attacks.

Re:What NPM should do to stop a new colors attack by gigel82 on Monday January 10, 2022 @11:40PM (#29887632)
> If you publish software you have responsibilities and no "provided as-is" clause can fully free you from it. Especially if you do so with the intention to cause harm.

Says who?

I can publish whatever the heck I want to my project and unless you and I have a contract that clearly defines expectations and resolutions, you're SOL.

Re:What NPM should do to stop a new colors attack by thn-gap on Tuesday January 11, 2022 @03:48AM (#29889092)
Intentions matter. The 'provided as-is' helps cover the author for unintended behaviors that are a result of some non desired bug.

You can't just update your extensively used code to add some ransomware or virus and be let off the hook because you warned users in a text file. The legal system will check what did you know and what your intentions were.

In this case, not that the author did a bad attack, but it's still a jerk move when the intention was uniquely to disrupt others and break things.

Re:What NPM should do to stop a new colors attack by fault1 on Tuesday January 11, 2022 @02:43AM (#29888706)
Well, at least in the United States, it's the default the other way (there are implied warranties) unless licensed otherwise. That's exactly what most open source licenses do to protect the author. That being said, I could imagine in some jurisdictions, the law limits the ability for people to disclaim such warranties. It would be an interesting case.
Re:What NPM should do to stop a new colors attack by dathinab on Tuesday January 11, 2022 @01:01PM (#29895113)
> Says who?

law

EDIT: At lest in some places.