News for hackers. Stuff that matters.

A comment on What NPM should do to stop a new colors attack. Parent comment

Re:What NPM should do to stop a new colors attack by rsstack on Monday January 10, 2022 @12:37PM (#29878378)
I'll leave it as an exercise for the reader to understand the difference between "I am not liable if I have a bug that ruins your production environment" and "I am not liable if I maliciously introduce a fatal bug knowingly into your production environment".
[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by phkahler on Monday January 10, 2022 @01:23PM (#29879118)
But he didn't introduce it into any particular production environment.

For fucks sake, people need to pin dependencies to a known good version at the very least.

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by cecilpl2 on Monday January 10, 2022 @04:00PM (#29882356)
Of course he did. Intent matters, and this was a reasonably foreseen consequence of the way the system is set up.

He knew how npm works and he knew the implication of adding that code is that hundreds of libraries and production systems would automatically upgrade and install it.

In fact, the whole point of what he did was to introduce the code into production environments.

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by jessaustin on Monday January 10, 2022 @10:18PM (#29887006)
Raise your hand if you pull directly from the internet into production without testing!

<no hands raised>

How can we claim he did anything to production if no one will admit they're dumb enough to push this latest version without testing it?

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by fulafel on Monday January 10, 2022 @01:00PM (#29878750)
Most of those (malice, who introduced it to your environment, fatal bug) seem contestable, even if we grant for the purpose of argument that the as-is disclaimer does not cover all cases.
[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by rsstack on Monday January 10, 2022 @01:02PM (#29878788)
Did you see the commit before it was deleted? I'd love to see a lawyer claiming anything else.
[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by fulafel on Monday January 10, 2022 @01:07PM (#29878868)
Which of the 3 claims are you referring to?

The commit is here as far as i know, not deleted: https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d1...

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by WJW on Monday January 10, 2022 @01:26PM (#29879164)
Any reasonable expert in the field will testify that it is not possible to write an infinite loop like that unintentionally.
[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by fulafel on Monday January 10, 2022 @03:35PM (#29881914)
The commit had a comment to the effect of being test / toy code not meant to be put into a release. I don't think a claim of randomly producing the snippet would be put forward in the hypothetical court case. Then there's the question of malice vs some other motive of expression in looping and printing some ASCII / zalgo art in your own terminal art lib.
[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by salawat on Monday January 10, 2022 @02:39PM (#29880656)
Any reasonable expert in the field will tell you you don't plug an auto-updating dependency into production. Marak wrote code. You, (the consumer), pulled, and deployed it without due diligence. That is entirely on you.

Not one person is obligated to keep your crap working except you. This has really outed all the people who really should know better.

[ Parent | on HN ]