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 encoderer on Monday January 10, 2022 @04:44PM (#29883084)
I think you’re being far too kind in your interpretation. If one wishes to stop maintaining, all you must do is nothing. Instead, by pushing an intentionally broken patch, It is foreseeable that there will be hundreds or thousands of maintainers of other code that will have to respond to your actions. I think it’s reasonable to call that an attack.
[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by toomuchtodo on Monday January 10, 2022 @04:53PM (#29883229)
If you consume open source code without reviewing it, it’s no different than executing arbitrary user code. Your environment’s security is based on hope and trust.

Maintainers shouldn’t be malicious, absolutely, but users should do a bit more than pulling code and running it. Otherwise, it’s curl | bash dressed up with a ci pipeline. How many times does dependabot bump your dependency revisions and no one looks except to ensure tests pass?

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by encoderer on Monday January 10, 2022 @05:42PM (#29883952)
A lot of it is based on trust, that’s evidently true, and as such, I think it’s perfectly fine to publicly shame a maintainer who looks to have breached that trust.
[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by bergheim on Monday January 10, 2022 @05:03PM (#29883372)
Doing this for something like GNU/Linux is simply not practical, _at all_. In what world can a user be expected to do little else that simply install linux? Since you pipe, can I assume you know everything about the kernel tree?

And bad actors work in companies as well. At some point you just have to trust what you are using.

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by caymanjim on Monday January 10, 2022 @05:35PM (#29883845)
People install Linux by picking a distribution to install. The maintainers of the distributions look at the packages they're including. For example, this broken colors package will never end up in any of them, because there are gatekeepers.

It's certainly impractical for every developer to vet every package they use, so much so that almost no developers vet any of the packages they use. What's needed are more gatekeepers. Repos like NPM would be well-served by coming up with mechanisms to support this. Off the top of my head, some sort of "this is safe" consensus, whereby the community can vouch for specific immutable versions of packages, that don't become the default version until they cross a threshhold. Organizations with a history of good stewardship and trusted validation processes could be allowed to skip the vetting step (e.g. things published by groups like the Apache Foundation or even corporations like Microsoft). I'm not arguing that one-man shops shouldn't be able to publish to NPM, just that there should be something like a "--untrusted" flag that's required before unverified updates are installed. And I'm not calling out NPM; every package repo has this problem.

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by toomuchtodo on Monday January 10, 2022 @05:20PM (#29883626)
I agree we’ve built a metropolis on sand, and a large component of solving for this problem is going to be some form of trust and managing that trust (more code reviews with an audit trail of some sort, human gating of code changes using automated risk modeling, etc).
[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by fivea on Monday January 10, 2022 @05:30PM (#29883763)
>>I think you’re being far too kind in your interpretation. If one wishes to stop maintaining, all you must do is nothing.

This sounds like a gross misrepresentation of what happened.

It has been reported that the author of the colors and faker packages announced last year that he was no longer willing to do free work for Fortune500 companies.

He also proceeded to state quite publicly that either companies paid him for his work, or they should fork the project and maintain it themselves instead of taking advantage of everyone else's work.

After a year has passed, the author proceeded to release a couple of major versions that had a more artistic feel.

https://web.archive.org/web/20210704022108/https://github.co...

Source:

https://www.theverge.com/2022/1/9/22874949/developer-corrupt...

These packages are his circus, and his clowns run the act he chooses.

If anything, this update showcases the completely abhorrent security culture in place in these mega-companies, which literally ingest into their product line anything that they can find on GitHub without a shred of due diligence.

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by acdha on Monday January 10, 2022 @05:41PM (#29883938)
> After a year has passed, the author proceeded to release a couple of major versions that had a more artistic feel.

Artistic would be a new color scheme or maybe a “support open source maintainers” message. The accurate description you didn't give is sabotage because he introduced an infinite loop:

https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d1...

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by fivea on Tuesday January 11, 2022 @02:26AM (#29888608)
> Artistic would be a new color scheme or maybe a “support open source maintainers” message.

The author already did that, and complained about fortune500 companies mooching their work without giving anything in return.

The author stated that people should fork the repo if they intended to keep using it.

The author made said statements a year ago. Is a year enough time to take action?

Now the author decided to do a major version release with a protest version of his own work, and that makes him a villain?

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by acdha on Tuesday January 11, 2022 @07:00AM (#29890465)
> Now the author decided to do a major version release with a protest version of his own work, and that makes him a villain?

He did more than that, as noted in the comment you replied to.

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by fivea on Tuesday January 11, 2022 @10:05AM (#29892241)
> He did more than that, as noted in the comment you replied to.

He really didn't. It matters nothing if you feel a commit breaks your code because you not only ignored the author but also failed to perform any sort of due diligence regarding what dependencies you ingest.

I mean, it was a major version bump. People blindly upgrade stuff without any regard about what goes in, and somehow that makes the guy who volunteered his work on a side project a villain?

There are a lot of red flags in this story, but the author of the colors flag ain't one of it.

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by acdha on Tuesday January 11, 2022 @10:41AM (#29892776)
I see you've switched from “he didn't break anything” to “it's the users' fault for not catching what he broke faster”.

Hint: going from 1.4.0 to 1.4.1 is not a major version bump — https://snyk.io/vuln/npm:colors

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by jamesfinlayson on Tuesday January 11, 2022 @02:07AM (#29888485)
Not to mention plenty of people (me at a big company included) used both of these packages as indirectly (as dependencies of dependencies) and had no idea about this until this week.
[ Parent | on HN ]