> Modifying the package to be abusive may technically (legally) be within his rights but is certainly not ethical

Of course it's not ethical. But, publishing whatever code he wants under his name, under his projects, is well within his rights.

We are setting the precedent that users can modify the code you've published under your own name, if they don't like what you've done with it.

That is not acceptable. My users should not have hegemony over my project. They can decide to fork, they can decide not to use it. But under no circumstances should they be able to edit my project under my name.

Because that's also unethical.

> I'm not even convinced that it was legal. Had he modified the package to install a Bitcoin miner instead of just breaking apps, I suspect he'd be breaking the law.

I really doubt this. People are choosing to run his code, and choosing to update to whatever new code he publishes, regardless of the contents.

It's not like he's forcefully installing his code on anyone's machine. By enabling automatic updates of his package, developers have implicitly granted him permission to run whatever he would like on their machine.

Unethical, sure. But perfectly legal.

Most people had no idea they even use colors.js as it’s used by some dependency of some dependency. For example, anyone installing AWS CDK afresh would be unable to deploy their infrastructure - it uses colors.js, which blocks the CPU as soon as it’s require’d deep in the stack. With that rug pull, the library author intended, designed, and successfully accomplished a Denial of Service move against all those people.

> Most people had no idea they even use colors.js

Why is that? Do NPM package managers not create a lock file that is a text file anyone can peruse?

yeah, it's just nobody reads every package in that file.

apps generated via create-react-app have more than 2000+ transitive dependencies.

That is a design problem of npm and really the nodejs dev community in general.

They (you) are Blaming the dev because inherent design flaws in their development methodology.

People have been pointing out this problem with npm for years and years

> Most people had no idea they even use colors.js

Isn't that the problem? That they were running a lot of code from unpaid contributors without any guarantees (as said explicitly in the license) and then blaming those contributors when something breaks?

Yes, it's a huge problem. But the author here is absolutely at fault for this attack.

If I leave my garage door wide open all night and a bunch of stuff gets stolen, I'll kick myself for stupidity and vow not to do it again. I'll also call the police and hope they find the perpetrator, because there was a theft.

It is true that we as a profession need to drastically rethink our approach to dependencies and also that this author acted unprofessionally and should be condemned for his actions.

> If I leave my garage door wide open all night and a bunch of stuff gets stolen

It's more like, "I let some random guy do whatever he wants to my garage door and he decides to brick it."

> We are setting the precedent that users can modify the code you've published under your own name, if they don't like what you've done with it.

Not users of your code, platforms you distribute on, and that precedent has been rolling forward for a while now, it's not new. Even so, I don't approve of GitHub's ban, but that doesn't mean I have to endorse the author.

> People are choosing to run his code, and choosing to update to whatever new code he publishes, regardless of the contents.

This line of reasoning would suggest that the authors of malware that requires affirmative action to start running (download an exe, open a PDF, whatever) are clean and clear legally because the victim chose to run their code. How is this any different than a malicious EXE sitting on a server somewhere waiting to be downloaded? It can't just be that the victims in this case ought to have known better, because the victims in most cases of malware ought to have known better.

> are clean and clear legally because the victim chose to run their code

If you take a knife from my kitchen and use it on yourself that is not my fault.

If you ask me for a tissue and I provide you with a knife and tell you it's a tissue, then I have some responsibility.

Ultimately, in either case, why were you not more careful?

I mean to strain the analogy it's more like feeding someone a sandwich and then having the ability to transmute the sandwich into a knife once they've already eaten it.

Did he meta-program that infinite loop? I haven't bothered to read the code… like everyone else :-D

For me the question is was the new (breaking) functionality announced when the package was updated. It appears to me it was thus I find no issue.

This is different then software announcing on the next release they will include ads or even a crypto miner as part of revenue generation

As long as the change is announced then there is no ethical issues and if you as the dev or user fail to read the updates of your depencacy tree well that is a failing on your part

> I really doubt this. People are choosing to run his code, and choosing to update to whatever new code he publishes, regardless of the contents.

Not sure that's true. The fraudulent element there would be the clear and intentional misrepresentation. If the package were represented as a Bitcoin miner, that's one thing. However, representing it as color and styling for your terminal and then mining with it, that seems illegal. Would love a lawyer to weigh in.

> We are setting the precedent that users can modify the code you've published under your own name, if they don't like what you've done with it.

Who has done this? Can you point to it?

The correct approach would be to allow changes like this to be pushed to _new_ versions but to lock pre-existing versions in place. The alternative is this weird world where the platforms themselves have spooky editorial control over every package and could step in at any time and lock out the maintainers (sounds a lot like SourceForge).

The "alternative" is exactly what Linux distros like RHEL and Debian do. They have editorial control over every package and often make changes the original developers don't like. It seems to work fairly well as long as you don't insist on following the latest version.

One mental model is that Linux distros are really just curated package repositories, with all the upsides and drawbacks that come with that. Especially regarding their dogmatic insistence that across the entire repository there's only a single (or at most several) versions of any given library

Aren't developers always using the same version and blindly downloading and running malicious code doing the same thing, running a single version?

Only those were harmed. And by harmed it was just really a bunch of tests runs failing, I guess no production workload was impacted by that jerk move.

Right, but my point is this code, in and of itself, really isn't malicious. It's only malicious in the context of "version XYZ used to do X, now it does Y". If you make versions indelible, you eliminate the potential for this to blow up as an issue.

To be clear, you can't edit an existing published version of a package on NPM, nor can you delete packages (havent been able to for 5 years-ish).

> Modifying the package to be abusive may technically (legally) be within his rights but is certainly not ethical

Sorry to play devil's advocate here, but who are you to say that the future vision of faker isn't some text being sent repeatedly to the console? One man's feature is another man's DoS attack, and while it's clear here, there are plenty of scenarios just like this where there is no obvious solution. We should just let maintainers do what they want with packages (other than install viruses or crypto-miners), but we shouldn't let them pull or modify old versions. Otherwise everything becomes like SourceForge where the platform itself can "editorially" decide to take over projects for financial gain whenever they feel like it and that behavior becomes normalized.