Deleting it would have been less offensive because deleting it would simply have caused his code to stop executing on other people's machines altogether. What he did instead was execute malicious code (albeit a relatively benign malice) on the computers of people who previously trusted him.

Deleting the package is within his rights. Modifying the package to be abusive may technically (legally) be within his rights but is certainly not ethical, and 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, and it's not obvious to me that a DOS attack should be treated differently.

> 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.

is it his right? to sabotage downstream code in revenge for not being paid for work he willingly took on knowing full well that he may never be paid?

legality is defined at the behest of societal needs. if society says something legal should be made illegal, or vice versa, then it will be.

GitHub/Microsoft chose to do the right thing for the society in the short term. in the long term, choosing a less stupid library update policy will benefit everyone AND let authors do all the "non-harmful" malevolent stuff they want.

as if this wasn't a single-point denial of service attack...

we are slowly (far too slowly) learning that our assumptions that all developers are benevolent is incorrect, and it's going to take another 2-5 instances of this kind of attack before people really start to understand why and see the danger of simply using libraries at all; especially in ecosystems like NPM where almost no one writes a single line of code on their own if it can instead be pulled in as a library dependency. this attitude is the exact opposite of a secure code approach and until people learn this, and learn it well, this kind of attack will continue, and the time between the attacks will gradually shorten.

> to sabotage downstream code in revenge for not being paid for work he willingly took on knowing full well that he may never be paid?

Some consumers of his project chose to use his 3rd party dependency in their code for free knowing full well that it could disappear or break at any time, and yet they still chose not to mitigate those risks they chose to take on.

yes, that is the other half of the coin: don't run code if you don't know what it does.

an extreme version of that: don't use libraries at all.

I am trending more and more to this extreme as I age, because people aren't learning their lesson, and the npm ecosystem keeps biting them over and over...

"we are slowly (far too slowly) learning that our assumptions that all developers are benevolent is incorrect, and it's going to take another 2-5 instances of this kind of attack before people really start to understand why and see the danger of simply using libraries at all"

I agree, but at the same time if we had this mindset earlier; open source probably wouldn't have caught on as quickly. Maybe it wouldn't have become mainstream?

Honestly, it is kind of surprising we've gotten this far assuming that basically all open source maintainers aren't malicious

Unfortunately I don't think that 2-5 instances of this will produce any change.

We've seen more than that number of actual malicious package takeovers in the last couple of years and it has produced basically no real change.

heck I did a talk describing this kind of attack 6 years ago and I found prior instances when researching that talk...

Should your users have control over the code you publish under your name?

Because that is the precedent we are setting here.

Did he own this code? Colors.js had plenty of other contributors, and there was no CLA involved.

github user "DABH" actually had more lines of code than marak did: https://github.com/Marak/colors.js/graphs/contributors

npm and github both have terms of service that you agree to when you choose to distribute something over those systems. npm in particular has had a long policy of unrolling malicious changes to the registry of packages ever since left-pad.

If the responsibility lies with the maintainer, then the responsibility lies with the maintainer.

It’s not just a random personal repo on GitHub. It has a long documentation published on NPM describing the intention of the module. It is advertised as being something it now clearly and deliberately is not.

Some would even call it a genuine fraud. Doesn’t matter if you paid for it or not, there are plenty of free services in meatspace that can be compared. Free quote of bathroom renovation - plumber changes all your locks when you look away while doing the inspection.

Now should consumers be more careful about situations like this, yes. Can this guy expect to claim any rights after a move like this, no.

Why are you bringing up modifying his code? I haven't seen any indication that anyone did that.

Changing the metadata around a npm-stored package is something that npm should have every right to do. Same for changing the metadata about a GitHub project. Neither the npm registry entry nor the GitHub project settings are the copyrighted code.

I mean, for almost every mainstream open source license, the answer to that is a pretty definitive "yes, they can", right? The most stringent of them require things like attribution and open source the modifications, neither of which seem like requirements that Github/NPM would have any qualms with following.

But does GitHub/NPM have the right to modify his code and publish it under his account/his name? I doubt that is legal.

The MIT license doesn't require NPM to list marak as the publisher of the NPM package, as long as they still obey the license's requirements.

Besides, the NPM Terms of Service are almost certainly broad enough to permit NPM to publish a modified version of a package or to delete a package.

And all of the contributors to his code?

What if he had done nothing more than create the repo and the community did all of the legwork? Is it still his right to delete all of their work?

Yes, it's his repo after all. If I let you grow flowers in my garden, it's still my right to burn it all down.

Otherwise, a multi-owner org should be used, or we need new concepts (like changes to repositories signed by multiple contributors.)

But with contributors, it's literally not his to "own", in terms of the actual work. Copyright law says roughly that you own the characters you type, unless you assign it to someone else.

The guy who actually wrote more of colors.js (by lines of code) than marak actually got npm to nuke the offending releases: https://github.com/Marak/colors.js/issues/317

right now they are reviewing a request to change the npm target to his repo

To write and merge code to Marak's version DABH has its own copy so your question makes no sense.

Marak could decide to make his repo disappear it doesn't make the local or hosted repos of other contributors disappear. It seems that github managed to distort your mind into thinking that git was no longer a decentralized cvs.

I don't get your point.

The repo, gh/npm accounts and such are just metadata and metadata of metadata, which is hosted and distributed based on the terms of service of gh/npm. The thing that matters most is what the npm project points to, since it is relied on by other packages and apps.

The only thing this guy "owns", according to the law, is the copyright for the part of the codebase he wrote. Not that it matters much since it is MIT licensed.

> The thing that matters most is what the npm project points to, since it is relied on by other packages and apps.

And it doesn't really matter that much because the NPM people can decide to make it point somewhere else wherever they want, or people can decide to create a new package name on NPM and use that new name on their package.json file.