Live data from Hacker News

Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

bleepingcomputer.com

181–190 of 1001 posts

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#181
post #74

It's a bit wild that the sum total money spent on salaries for engineers handling potential problems stemming from this or defending against the possibility in the future could probably have covered paying the maintainer a living wage many times over.

Living wage? haha, more like 100 peoples living wage.

In America, most unskilled software developers make somewhere in the $80k to $140k range. A living wage is around $20k for absolute bare minimum essentials. Skilled devs still get around $200k.

Point is, maybe 10 people. And that’s if you like ramen.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#182

Earlier quoted context omitted.

Except if they have reason to believe the code was uploaded with the permission of the copyright holder. The they have gotten the right for npm to distribute the source code in context of npm.

> The they have gotten the right for npm to distribute the source code in context of npm. There is absolutely no copyright or publishing right transfer that takes place when one "publishes" a package on NPM (or on Github). None. The original author is absolutely entitled to a DMCA takedown notice and NPM would have to oblige him.

[deleted]

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#183
Recent and related:

Important NPM package colors from Marak causing console problems at the moment - https://news.ycombinator.com/item?id=29861560 - Jan 2022 (1 comment)

Creator of faker.js pushed an update of colors.js which has an infinite loop - https://news.ycombinator.com/item?id=29855397 - Jan 2022 (1 comment)

Marak adds infinite loop test to popular colors.js - https://news.ycombinator.com/item?id=29851065 - Jan 2022 (7 comments)

Marak's GitHub account suspended after he erased his faker project - https://news.ycombinator.com/item?id=29837473 - Jan 2022 (53 comments)

Faker.js Erased by Author - https://news.ycombinator.com/item?id=29822551 - Jan 2022 (2 comments)

Popular JavaScript package “Faker” replaced with message about Aaron Schwartz - https://news.ycombinator.com/item?id=29816532 - Jan 2022 (3 comments)

Faker.js Has Been Deleted - https://news.ycombinator.com/item?id=29806328 - Jan 2022 (9 comments)

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#184

Earlier quoted context omitted.

> The they have gotten the right for npm to distribute the source code in context of npm. There is absolutely no copyright or publishing right transfer that takes place when one "publishes" a package on NPM (or on Github). None. The original author is absolutely entitled to a DMCA takedown notice and NPM would have to oblige him.

You can't legally retract opening up software source code under most if not all popular open source licenses.

It is indeed all, even if you ignore the "popular" qualifier. If a license could be unilaterally revoked, it would fail to meet the Open Source Definition for that reason.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#185

Earlier quoted context omitted.

> What exactly does colors do? A picture is worth a thousand words → https://i.imgur.com/inxA7Pg.png The library inserts ANSI escape sequences [1] between the text you want to colorize in order to, well, colorize it ¯\_(ツ)_/¯ Many people are obsessed with colors in the Terminal, and so, they reach out to libraries like this. They exist in every major programming language ecosystem, even though colorizing text is as s…

Why wouldn't everyone roll their own solution? Doesn't seem to be a huge thing to me, but I could be wrong...

> Why wouldn't everyone roll their own solution?

JS devs will do anything to avoid this.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#186

GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724

This is not the way.

Github doesn't have the right to tell someone what to do with their own code. The only right thing to do in this situation is to fork the repositories and fix the situation on the npm side. Github doesn't get to ban this guy because he took a dump in his own backyard.

EDIT: I suppose the literal DoS attack in the code probably puts him squarely in the "malicious behaviour" category which then gives github the right to do this.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#187
Yikes, it's one thing to stop development of somethign but another to intentionally do damage to thousands of people, big companies and small one person webdev shops alike. This guy probably can't be sued because of opensource, but he should be shunned in the future by open source advocates and just the public in general. Why would anyone hire him unless it's to run an antifa/right-wing website?

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#188
Some people find this too rough, but the reality is: do not license something as MIT or any free license if you are not happy with commercial users benefiting from your work.

Simple as that. None of them are under any obligation to pay, maintain, promote, or not clone your project.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#189
post #17

So people learned basically nothing from leftPad.js ?

What were they supposed to learn? "Don't have dependencies"?

Control your dependencies, don't make them control you.

Pin dependendency versions, don't allow auto-upgrade. And cache your dependencies locally for as long as you depend on them.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#190
post #43

Earlier quoted context omitted.

To resolve such issues the central maven repo, for example, makes artifacts immutable when you publish them

This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything.

You're never going to be able to prevent that at a technical level. You can prevent it with workflow, though: 1) sync packages locally and build from those versions; 2) peg to a specific version and don't auto-update; 3) deploy to a test environment and not directly to production.
Post reply on HN