34 ms·

I take issue with the title of this article. This was not an attack. The project's author committed a change to his own open source project, which he had every

I take issue with the title of this article. This was not an attack. The project's author committed a change to his own open source project, which he had every right to do. Was that an asshole move, and did he lose all credibility in the OSS community? Yes, absolutely. But it was not an attack. In fact, I also take issue with GitHub / Microsoft taking over the package and am very worried about the precedent that sets, regardless if their motives this time appear to be entirely selfless.

spankalee 5y ago
Just because the package owner had implicit permission to run code on other people's machines, doesn't mean that this wasn't an attack. A postal carrier may have a key to a building to deliver mail, but if they use it to turn on all the faucets and leave the doors open, it's an attack.
- xvector 5y ago
  It's still his project. He could have deleted it for all I care, it's his every right. I wonder if GitHub/NPM even have the legal rights to modify the code you publish, depending on your license.
  - saghm 5y ago
    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.
    - xvector 5y ago
      But does GitHub/NPM have the right to modify his code and publish it under his account/his name? I doubt that is legal.
      - jffry 5y ago
        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.
  - naikrovek 5y ago
    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.
    - xvector 5y ago
      Should your users have control over the code you publish under your name? Because that is the precedent we are setting here.
      - fault1 5y ago
        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 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.
        yifanl 5y ago
        If the responsibility lies with the maintainer, then the responsibility lies with the maintainer.
  - lolinder 5y ago
    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.
    - xvector 5y ago
      > 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.
      - lolinder 5y ago
        > 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.
  - spankalee 5y ago
    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.
  - Too 5y ago
    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.
  - ratg13 5y ago
    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?
    - xvector 5y ago
      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.)
      - fault1 5y ago
        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 https://github.com/Marak/colors.js/issues/317 right now they are reviewing a request to change the npm target to his repo
        prmoustache 5y ago
        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.
        fault1 5y ago
        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.
- jzb 5y ago
  He didn’t, though. People signed up to a distribution method to run the code and just assumed future updates would be okay. He didn’t push the code to them, they pulled it.
  - lolinder 5y ago
    He did what he did knowing full well that people would end up downloading and running that code. By your same reasoning you could argue that websites distributing malware aren't pushing viruses to people, people are coming to them and pulling the virus onto their computer.
  - PragmaticPulp 5y ago
    People didn't actively go seek out a new version. He intentionally abused semver to disguise it as a safe update, when it was not. I know it's popular in programming/infosec to blame the victim for trusting anyone, but you can't deny that this it's common behavior among many (though not all) projects to use the caret prefix when specifying dependencies because you trust the package maintainer to honor the semver agreement.
    - shepherdjerred 5y ago
      It's his project. It's a free, open-source project. What does the maintainer owe us? Absolutely nothing. > I know it's popular in programming/infosec to blame the victim for trusting anyone, but you can't deny that this it's common behavior among many (though not all) projects to use the caret prefix when specifying dependencies because you trust the package maintainer to honor the semver agreement. Be thankful that all he did was spam the console. It could have been something more malicious. Updating dependencies without auditing source code is a very common practice, but that doesn't mean it's not the victim's fault. It is unrealistic to audit the insane amount of source that our projects are built on, but that is the exact tradeoff that we're making in exchange for the productivity of not building libraries ourselves or paying for those libraries. Open source is something that we're gifted not something that we're owed. If you disagree, then feel free to either use exclusively proprietary software where you can have expectations of the maintainer, or build all of the functionality that you need by yourself.
- deleted 5y ago
  [deleted]
- kristjansson 5y ago
  A package isnt even implicit authorization to run arbitrary code on other peoples machines. It’s authorization to run a specific, known version of your code, preferably one that others are also using without incident. That’s the whole point of TFA: this is a design flaw in NPM, a package author shouldn’t be able to have the impact this event did, regardless of how popular their package is.
- alar44 5y ago
  That's exactly backwards. He wasn't granted permission to run code on other people's machines, he granted other people the right to run his code on their machines! Wow!
  - stickfigure 5y ago
    There is a social contract in the world of open source. The author violated it. If he exploited trust to steal private crypto keys, we'd have no trouble calling it an attack. The difference is merely a matter of degree.
    - alar44 5y ago
      Merely a matter of degree? There is a chasm between stealing data and printing nonsense to stdout. That's like saying getting all your limbs cut off is technically a flesh wound and the only difference between that and a papercut is the degree of the wound.
      - irfanka 5y ago
        Well... yes. That's exactly what "degree" means.
        krageon 5y ago
        Yes, but you wouldn't use it in this manner in a good-faith conversation.
    - ratg13 5y ago
      This still leaves the elephant in the room: who decides when this line has been crossed?
      - toxik 5y ago
        Intent is what matters, was it meant as an attack - and it kind of was but Joe Developer Schmoe really just got caught in the crossfire of some guy who watched Mr. Robot one time too many. To answer your question directly, I think the jury’s still out and it will depend on the repercussions. So far it seems to have been a nuisance at worst.
- hackmiester 5y ago
  Microsoft may have the right to host and distribute this person’s code, but if they use it to take over the package and make decisions on the author’s behalf, it’s an attack.
ozfive 5y ago
Agreed on all points. People are quick to jump on someone especially when they work really hard on something and then give it away for free. Companies turn around all of the time and change their revenue model and nobody says a thing. It's their right. The guy still had the rights to do whatever he likes with the software he wrote for free. All the assholes vilifying him are shilling for corporations that didn't want to pony up to help this guy continue his work. His actions were pretty drastic, but remember he owns the rights. If he wants to delete what he owns he's in his rights and corporations better take note. You use something for free that you don't own and have no intention of compensating the people behind it you only have yourself to blame when those people rage quit. There is no real argument against this without looking like a freeloading dick.
- BoorishBears 5y ago
  You don't get to have it both ways: If you go by the spirit of things tanking a package and Github/MS/npm taking over to undo that is fair game. Even if it's not literally a virus, obviously damaging basic functionality to make a statement is not a sustainable practice for NPM to continue functioning If you want to go by the letter and what legal rights someone has: https://docs.npmjs.com/policies/conduct https://docs.npmjs.com/policies/conduct > The Service administrators reserve the right to make judgment calls about what is and isn't appropriate in published packages, package names, user and organization names, and other public content. Package that violates the npm Service's Acceptable Use rules including its Acceptable Content rules will be deleted, at the discretion of npm. https://docs.npmjs.com/policies/open-source-terms https://docs.npmjs.com/policies/open-source-terms > Your Content belongs to you. You decide whether and how to license it. But at a minimum, you license npm to provide Your Content to users of npm Services when you share Your Content. That special license allows npm to copy, publish, and analyze Your Content, and to share its analyses with others. npm may run computer code in Your Content to analyze it, but npm's special license alone does not give npm the right to run code for its functionality in npm products or services. > When Your Content is removed from npm Services, whether by you or npm, npm's special license ends when the last copy disappears from npm's backups, caches, and other systems. *Other licenses, such as open source licenses, may continue after Your Content is removed. Those licenses may give others, or npm itself, the right to share Your Content with npm Services again.* https://github.com/Marak/colors.js/blob/master/LICENSE https://github.com/Marak/colors.js/blob/master/LICENSE - Seriously, why are people so adamant about defending this? We're all part of a giant ecosystem that relies on everyone being "a freeloading dick" in your eyes. Colors wouldn't have its audience without its creator being a "freeloading dick" and expecting NPM to serve it millions of times for free. NPM relies on a JS ecosystem propped up by "freeloading dicks". "Freeloading dick" is such a dumb characterization of what it really is: Expecting FOSS creators and maintainers to be somewhat cognizant of the ecosystem past the tip of their nose.
leshenka 5y ago
What swims like a duck and quacks like a duck
lovich 5y ago
> In fact, I also take issue with GitHub / Microsoft taking over the package and am very worried about the precedent that sets, regardless if their motives this time appear to be entirely selfless. Is there more on this? This is the first I’ve heard about this npm package being modified which I would have just ignored as regular npm problems, but hearing that GitHub took over someone’s repo sounds crazy. Does their ToS claim to override copyright or something?
- judge2020 5y ago
  They supposedly took over the npm packages[0,1], not the github.com repos. npm is a system where you push archives as package versions, it doesn't do its own pull from a github repo or otherwise. To add, unused/squatted npm package names regularly get reassigned[2]. 0: https://www.npmjs.com/package/colors https://www.npmjs.com/package/colors 1: https://www.npmjs.com/package/faker https://www.npmjs.com/package/faker 2: https://docs.npmjs.com/policies/disputes#definitions https://docs.npmjs.com/policies/disputes#definitions
- jffry 5y ago
  I do not think NPM altered a package, they unpublished the nonfunctional/infinite-loop version, so that the prior, functional, version (pushed by marak) becomes the "latest" version again
  - gigel82 5y ago
    Yes, that is a very dangerous precedent. This isn't like the leftpad issue where someone stole credentials from the project owner. This is the project owner himself publishing a new version of his project.
    - fault1 5y ago
      Nobody stole creds off the project owner in the left-pad incident. npm chose the needs of the many rather the few in that incident: https://twitter.com/seldo/status/712417370686365697 https://twitter.com/seldo/status/712417370686365697 which seems like very much akin to what they are doing now.
dimgl 5y ago
I don't agree with the general sentiment on this. This seems like a blatant attack to me. He went out of his way to deliberately sabotage all of the projects that depended on his. I have a few open source libraries (admittedly, not very popular) and I'd never do this. Even if I am giving the project out for free with an MIT license and are not liable for any damages.
- gigel82 5y ago
  I'd never do this either. You and I have different ethics than this guy. We're all in agreement that's a total asshole move and no-one would be trusting him again in the OSS community, that's not in contention. However, even assholes have rights. Didn't you ever play with neighborhood kids who take their toys and ruin everyone's fun just because they're losing? Total assholes, but still it's their shit and they can take it if they want to. It's like me keeping a bowl of M&Ms at my desk at work to snack and let people grab a few when they pass by too, but I go on a diet and replace them with brussel sprouts one day. Don't act all butt-hurt that you're not getting your free sugar, it's my bowl and I'll put whatever I want in it.
  - stickfigure 5y ago
    If the guy had installed keyloggers, or formatted drives, would you still say he's within his rights?
  - TedDoesntTalk 5y ago
    > no-one would be trusting him again I keep seeing people write this. But how would you ever know if one of your projects depended on a future package he maintains? Do you really track the authors of all packages you use against a shit list? And what if he just uses another name?
    - jzb 5y ago
      And there’s the real problem: a shit ton of people/orgs don’t know what’s in the software they use/ship, and just expect people to DTRT for free, forever.
zarzavat 5y ago
A trojan distributed through NPM is still a trojan. It matters not whose code it was but the intention to do harm.
- waynesonfire 5y ago
  is it a "trojon" when a maintainer decides to break backwards compatibility with their next release and breaks your code? how is this any different? Did you miss the bit in the license that states, "THE SOFTWARE IS PROVIDED "AS IS"? when you decide to incorporate code with no guarantees into your project, you get what you get. Marak is a hero in my view to the open source community. The cost of free software is that there is nobody to point a finger at. Acts like this show-case that being able to point a finger at someone is worth something. And, maybe corps that use open-source software will begin to address this "risk" and maybe this outcome will benefit the open source community. The "AS-IS" part is a big problem and is addressed through funding. Where, exactly what IS gets negotiated for a price.
  - zarzavat 5y ago
    If it had deleted files, or extracted user password data and uploaded it to pastebin you would agree it's a Trojan, yes? Your license agreement is not going to save you from the feds if you write code like that. So we are arguing where the line is. From what I understand, having not run the code myself, he wrote code that put the system into an infinite loop, i.e. he intentionally caused a hang. That crosses the line in a clear way, for me.
    - dathinab 5y ago
      Then it would be a crime in more or less any country. Now the question is if it's hanging intentionally?(Software as-is) license only helps so much. Think the answer for this is not clear cut. Without question a line was crossed. I mean sure there are endless problems about how npm handles things, but it's more nounced. Like e.g. you needing to go out of your way to lock dependencies instead of it being some form of defaultish behaviour is a problem. People distributing CLI tools without having strict dependency locking is a even bigger problem/no-go. And this showing how careless some people are when it comes to distributing software is probably the most interesting thing.
sigzero 5y ago
Of course it was an "attack". Is doesn't matter that he owned his own packages. He knew exactly what he was doing with his changes and the effect it would have on projects that relied on his.
- datenarsch 5y ago
  It's his project. It's your fault if you blindly trust random 3rd-party code on the internet and have your mission-critical software depend on it.
  - dathinab 5y ago
    > It's his project. If you publish software you have responsibilities and no "provided as-is" clause can fully free you from it. Especially if you do so with the intention to cause harm. > It's your fault if you blindly trust random 3rd-party code on the internet and have your mission-critical software depend on it. The problem is not to "rust random 3rd-party code on the internet" but the "blindly" part. Like never ever deploy without locking dependencies and testing any new dependencies before updating the lock and preferable even give the changes/diff a shallow review. I think anyone providing programs (instead of libs) installed though npm (or "blind" untested CI builds for releases) is as much a problem as the one who caused the problems this time. Maybe even more as they also open the door for other more malicious attacks.
    - deleted 5y ago
      [deleted]
    - gigel82 5y ago
      > If you publish software you have responsibilities and no "provided as-is" clause can fully free you from it. Especially if you do so with the intention to cause harm. Says who? I can publish whatever the heck I want to my project and unless you and I have a contract that clearly defines expectations and resolutions, you're SOL.
      - 5y ago
sam0x17 5y ago
> The project's author committed a change to his own open source project, which he had every right to do. Indeed, and it goes beyond this. I think the real implication is that software published on NPM and similar networks isn't truly free and open source, in the sense that the platform owner can and will step in and make editorial changes without the knowledge or consent of the software maintainers.
- spankalee 5y ago
  What changes did they make to the code? None as far as I can see.
  - sam0x17 5y ago
    The maintainer's intended release was text spamming the console. They replaced it with the old faker. This is changing the maintainer's code.
    - Macha 5y ago
      > https://github.com/Marak/colors.js/blob/5152d16f22789d66e107275e006f88517641ed18/LICENSE https://github.com/Marak/colors.js/blob/5152d16f22789d66e107... So can you point me to where this license says you cannot modify this code? Or that by accepting distribution of one version of this code, you are obligated to distribute future versions? You can't hide behind "The license doesn't say he has to play nice, so you can't complain about him not playing nice", then say it's unfair that npm don't go behind their license and TOS obligations to host his spite version.
      - sam0x17 5y ago
        Because they are interfering with _his_ distribution of the code. They are free to distribute it separately and make changes in those cases, but instead they are essentially re-writing history without the knowledge of the package owner, and for reasons that are largely editorial and, I think, unprecedented. They are interfering with his right to distribution, essentially. I know that in a slimy, technical way, you are correct, but I think it is relevant if at the end of the day it is practically impossible to distribute code without some unauthorized third party modifying it in transit, essentially. The implication is we need to start running our own git servers.
zamalek 5y ago
> I take issue with the title of this article. The author wasn't mentioned in the title at all: "colors attack." Names have to come from somewhere. The article is about some hypothetical future antagonist that puts a hack/bitcoin miner in their widely adopted package, or something. "Colors attack" is just the name of, effectively, the CVE.
nhoughto 5y ago
yeah i don't see it as an attack and was very surprised Github suspended his account, less so that NPM unpublished the package. It is easy to think of these platforms as unbiased repositories, but as soon as something is deemed 'wrong' suddenly you need to think what the criteria is for that decision, who makes the decision and how? Where is the line? Is an infinite loop is the line? Updating a package to display random text without an infinite loop is crossing the line too? Who decides what _my_ OSS library is allowed to do? Can I update it just to add a banner asking for donations? How is that functionally different to random text other than intent?
kristjansson 5y ago
He had two things: (1) the right to make and publish a change to a project he controlled and (2) a mechanism (npm and its ecosystems versioning practices) to have his changes run on thousands of machines. Making changes via (1) is not an attack. Leveraging (2) to cause ‘damage’ is without question an attack, even if the damage is just burned CI minutes and even if the victims’ comically poor practices bear some (most) of the responsibility.
tacone 5y ago
I regard that as an attack, specifically a denial of service. Whether he had the right to do so doesn't matter much, he voluntarily broke other people's apps. Btw, I'd say that he for sure has the right to write purposely broken code, but probably not to push it on npm (it depends on npm TOS, though). If it was for me, I would just suspend his npm account and keep distributing the existent code, since the license allows to do so.
hnlmorg 5y ago
I think "attack" still best describes the move even if it was an indirect attack (ie he poisoned his own code then others ran it). The intention was to create a denial of service "bug" as a protest and given it was deliberate I don't think the term "bug" is sufficient. But you're right it wasn't a direct attack and I'm inclined to also agree that it wasn't intended to be malicious (though not all attacks are). > In fact, I also take issue with GitHub / Microsoft taking over the package and am very worried about the precedent that sets, regardless if their motives this time appear to be entirely selfless. Yeah, I agree with you here.
pawelmurias 5y ago
They own the sites, they are allowed to get rid of some fuckwit.

spankalee 5y ago

Just because the package owner had implicit permission to run code on other people's machines, doesn't mean that this wasn't an attack. A postal carrier may have a key to a building to deliver mail, but if they use it to turn on all the faucets and leave the doors open, it's an attack.

xvector 5y ago
It's still his project. He could have deleted it for all I care, it's his every right. I wonder if GitHub/NPM even have the legal rights to modify the code you publish, depending on your license.
- saghm 5y ago
  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.
  - xvector 5y ago
    But does GitHub/NPM have the right to modify his code and publish it under his account/his name? I doubt that is legal.
    - jffry 5y ago
      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.
- naikrovek 5y ago
  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.
  - xvector 5y ago
    Should your users have control over the code you publish under your name? Because that is the precedent we are setting here.
    - fault1 5y ago
      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 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.
      - yifanl 5y ago
        If the responsibility lies with the maintainer, then the responsibility lies with the maintainer.
- lolinder 5y ago
  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.
  - xvector 5y ago
    > 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.
    - lolinder 5y ago
      > 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.
- spankalee 5y ago
  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.
- Too 5y ago
  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.
- ratg13 5y ago
  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?
  - xvector 5y ago
    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.)
    - fault1 5y ago
      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 https://github.com/Marak/colors.js/issues/317 right now they are reviewing a request to change the npm target to his repo
      - prmoustache 5y ago
        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.
        fault1 5y ago
        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.
jzb 5y ago
He didn’t, though. People signed up to a distribution method to run the code and just assumed future updates would be okay. He didn’t push the code to them, they pulled it.
- lolinder 5y ago
  He did what he did knowing full well that people would end up downloading and running that code. By your same reasoning you could argue that websites distributing malware aren't pushing viruses to people, people are coming to them and pulling the virus onto their computer.
- PragmaticPulp 5y ago
  People didn't actively go seek out a new version. He intentionally abused semver to disguise it as a safe update, when it was not. I know it's popular in programming/infosec to blame the victim for trusting anyone, but you can't deny that this it's common behavior among many (though not all) projects to use the caret prefix when specifying dependencies because you trust the package maintainer to honor the semver agreement.
  - shepherdjerred 5y ago
    It's his project. It's a free, open-source project. What does the maintainer owe us? Absolutely nothing. > I know it's popular in programming/infosec to blame the victim for trusting anyone, but you can't deny that this it's common behavior among many (though not all) projects to use the caret prefix when specifying dependencies because you trust the package maintainer to honor the semver agreement. Be thankful that all he did was spam the console. It could have been something more malicious. Updating dependencies without auditing source code is a very common practice, but that doesn't mean it's not the victim's fault. It is unrealistic to audit the insane amount of source that our projects are built on, but that is the exact tradeoff that we're making in exchange for the productivity of not building libraries ourselves or paying for those libraries. Open source is something that we're gifted not something that we're owed. If you disagree, then feel free to either use exclusively proprietary software where you can have expectations of the maintainer, or build all of the functionality that you need by yourself.
deleted 5y ago
[deleted]
kristjansson 5y ago
A package isnt even implicit authorization to run arbitrary code on other peoples machines. It’s authorization to run a specific, known version of your code, preferably one that others are also using without incident. That’s the whole point of TFA: this is a design flaw in NPM, a package author shouldn’t be able to have the impact this event did, regardless of how popular their package is.
alar44 5y ago
That's exactly backwards. He wasn't granted permission to run code on other people's machines, he granted other people the right to run his code on their machines! Wow!
- stickfigure 5y ago
  There is a social contract in the world of open source. The author violated it. If he exploited trust to steal private crypto keys, we'd have no trouble calling it an attack. The difference is merely a matter of degree.
  - alar44 5y ago
    Merely a matter of degree? There is a chasm between stealing data and printing nonsense to stdout. That's like saying getting all your limbs cut off is technically a flesh wound and the only difference between that and a papercut is the degree of the wound.
    - irfanka 5y ago
      Well... yes. That's exactly what "degree" means.
      - krageon 5y ago
        Yes, but you wouldn't use it in this manner in a good-faith conversation.
  - ratg13 5y ago
    This still leaves the elephant in the room: who decides when this line has been crossed?
    - toxik 5y ago
      Intent is what matters, was it meant as an attack - and it kind of was but Joe Developer Schmoe really just got caught in the crossfire of some guy who watched Mr. Robot one time too many. To answer your question directly, I think the jury’s still out and it will depend on the repercussions. So far it seems to have been a nuisance at worst.
hackmiester 5y ago
Microsoft may have the right to host and distribute this person’s code, but if they use it to take over the package and make decisions on the author’s behalf, it’s an attack.

ozfive 5y ago

Agreed on all points. People are quick to jump on someone especially when they work really hard on something and then give it away for free. Companies turn around all of the time and change their revenue model and nobody says a thing. It's their right. The guy still had the rights to do whatever he likes with the software he wrote for free. All the assholes vilifying him are shilling for corporations that didn't want to pony up to help this guy continue his work. His actions were pretty drastic, but remember he owns the rights. If he wants to delete what he owns he's in his rights and corporations better take note. You use something for free that you don't own and have no intention of compensating the people behind it you only have yourself to blame when those people rage quit. There is no real argument against this without looking like a freeloading dick.

BoorishBears 5y ago
You don't get to have it both ways: If you go by the spirit of things tanking a package and Github/MS/npm taking over to undo that is fair game. Even if it's not literally a virus, obviously damaging basic functionality to make a statement is not a sustainable practice for NPM to continue functioning If you want to go by the letter and what legal rights someone has: https://docs.npmjs.com/policies/conduct https://docs.npmjs.com/policies/conduct > The Service administrators reserve the right to make judgment calls about what is and isn't appropriate in published packages, package names, user and organization names, and other public content. Package that violates the npm Service's Acceptable Use rules including its Acceptable Content rules will be deleted, at the discretion of npm. https://docs.npmjs.com/policies/open-source-terms https://docs.npmjs.com/policies/open-source-terms > Your Content belongs to you. You decide whether and how to license it. But at a minimum, you license npm to provide Your Content to users of npm Services when you share Your Content. That special license allows npm to copy, publish, and analyze Your Content, and to share its analyses with others. npm may run computer code in Your Content to analyze it, but npm's special license alone does not give npm the right to run code for its functionality in npm products or services. > When Your Content is removed from npm Services, whether by you or npm, npm's special license ends when the last copy disappears from npm's backups, caches, and other systems. *Other licenses, such as open source licenses, may continue after Your Content is removed. Those licenses may give others, or npm itself, the right to share Your Content with npm Services again.* https://github.com/Marak/colors.js/blob/master/LICENSE https://github.com/Marak/colors.js/blob/master/LICENSE - Seriously, why are people so adamant about defending this? We're all part of a giant ecosystem that relies on everyone being "a freeloading dick" in your eyes. Colors wouldn't have its audience without its creator being a "freeloading dick" and expecting NPM to serve it millions of times for free. NPM relies on a JS ecosystem propped up by "freeloading dicks". "Freeloading dick" is such a dumb characterization of what it really is: Expecting FOSS creators and maintainers to be somewhat cognizant of the ecosystem past the tip of their nose.

leshenka 5y ago

What swims like a duck and quacks like a duck

lovich 5y ago

> In fact, I also take issue with GitHub / Microsoft taking over the package and am very worried about the precedent that sets, regardless if their motives this time appear to be entirely selfless. Is there more on this? This is the first I’ve heard about this npm package being modified which I would have just ignored as regular npm problems, but hearing that GitHub took over someone’s repo sounds crazy. Does their ToS claim to override copyright or something?

judge2020 5y ago
They supposedly took over the npm packages[0,1], not the github.com repos. npm is a system where you push archives as package versions, it doesn't do its own pull from a github repo or otherwise. To add, unused/squatted npm package names regularly get reassigned[2]. 0: https://www.npmjs.com/package/colors https://www.npmjs.com/package/colors 1: https://www.npmjs.com/package/faker https://www.npmjs.com/package/faker 2: https://docs.npmjs.com/policies/disputes#definitions https://docs.npmjs.com/policies/disputes#definitions
jffry 5y ago
I do not think NPM altered a package, they unpublished the nonfunctional/infinite-loop version, so that the prior, functional, version (pushed by marak) becomes the "latest" version again
- gigel82 5y ago
  Yes, that is a very dangerous precedent. This isn't like the leftpad issue where someone stole credentials from the project owner. This is the project owner himself publishing a new version of his project.
  - fault1 5y ago
    Nobody stole creds off the project owner in the left-pad incident. npm chose the needs of the many rather the few in that incident: https://twitter.com/seldo/status/712417370686365697 https://twitter.com/seldo/status/712417370686365697 which seems like very much akin to what they are doing now.

dimgl 5y ago

I don't agree with the general sentiment on this. This seems like a blatant attack to me. He went out of his way to deliberately sabotage all of the projects that depended on his. I have a few open source libraries (admittedly, not very popular) and I'd never do this. Even if I am giving the project out for free with an MIT license and are not liable for any damages.

gigel82 5y ago
I'd never do this either. You and I have different ethics than this guy. We're all in agreement that's a total asshole move and no-one would be trusting him again in the OSS community, that's not in contention. However, even assholes have rights. Didn't you ever play with neighborhood kids who take their toys and ruin everyone's fun just because they're losing? Total assholes, but still it's their shit and they can take it if they want to. It's like me keeping a bowl of M&Ms at my desk at work to snack and let people grab a few when they pass by too, but I go on a diet and replace them with brussel sprouts one day. Don't act all butt-hurt that you're not getting your free sugar, it's my bowl and I'll put whatever I want in it.
- stickfigure 5y ago
  If the guy had installed keyloggers, or formatted drives, would you still say he's within his rights?
- TedDoesntTalk 5y ago
  > no-one would be trusting him again I keep seeing people write this. But how would you ever know if one of your projects depended on a future package he maintains? Do you really track the authors of all packages you use against a shit list? And what if he just uses another name?
  - jzb 5y ago
    And there’s the real problem: a shit ton of people/orgs don’t know what’s in the software they use/ship, and just expect people to DTRT for free, forever.

zarzavat 5y ago

A trojan distributed through NPM is still a trojan. It matters not whose code it was but the intention to do harm.

waynesonfire 5y ago
is it a "trojon" when a maintainer decides to break backwards compatibility with their next release and breaks your code? how is this any different? Did you miss the bit in the license that states, "THE SOFTWARE IS PROVIDED "AS IS"? when you decide to incorporate code with no guarantees into your project, you get what you get. Marak is a hero in my view to the open source community. The cost of free software is that there is nobody to point a finger at. Acts like this show-case that being able to point a finger at someone is worth something. And, maybe corps that use open-source software will begin to address this "risk" and maybe this outcome will benefit the open source community. The "AS-IS" part is a big problem and is addressed through funding. Where, exactly what IS gets negotiated for a price.
- zarzavat 5y ago
  If it had deleted files, or extracted user password data and uploaded it to pastebin you would agree it's a Trojan, yes? Your license agreement is not going to save you from the feds if you write code like that. So we are arguing where the line is. From what I understand, having not run the code myself, he wrote code that put the system into an infinite loop, i.e. he intentionally caused a hang. That crosses the line in a clear way, for me.
  - dathinab 5y ago
    Then it would be a crime in more or less any country. Now the question is if it's hanging intentionally?(Software as-is) license only helps so much. Think the answer for this is not clear cut. Without question a line was crossed. I mean sure there are endless problems about how npm handles things, but it's more nounced. Like e.g. you needing to go out of your way to lock dependencies instead of it being some form of defaultish behaviour is a problem. People distributing CLI tools without having strict dependency locking is a even bigger problem/no-go. And this showing how careless some people are when it comes to distributing software is probably the most interesting thing.

sigzero 5y ago

Of course it was an "attack". Is doesn't matter that he owned his own packages. He knew exactly what he was doing with his changes and the effect it would have on projects that relied on his.

datenarsch 5y ago
It's his project. It's your fault if you blindly trust random 3rd-party code on the internet and have your mission-critical software depend on it.
- dathinab 5y ago
  > It's his project. If you publish software you have responsibilities and no "provided as-is" clause can fully free you from it. Especially if you do so with the intention to cause harm. > It's your fault if you blindly trust random 3rd-party code on the internet and have your mission-critical software depend on it. The problem is not to "rust random 3rd-party code on the internet" but the "blindly" part. Like never ever deploy without locking dependencies and testing any new dependencies before updating the lock and preferable even give the changes/diff a shallow review. I think anyone providing programs (instead of libs) installed though npm (or "blind" untested CI builds for releases) is as much a problem as the one who caused the problems this time. Maybe even more as they also open the door for other more malicious attacks.
  - deleted 5y ago
    [deleted]
  - gigel82 5y ago
    > If you publish software you have responsibilities and no "provided as-is" clause can fully free you from it. Especially if you do so with the intention to cause harm. Says who? I can publish whatever the heck I want to my project and unless you and I have a contract that clearly defines expectations and resolutions, you're SOL.
    - 5y ago

sam0x17 5y ago

> The project's author committed a change to his own open source project, which he had every right to do. Indeed, and it goes beyond this. I think the real implication is that software published on NPM and similar networks isn't truly free and open source, in the sense that the platform owner can and will step in and make editorial changes without the knowledge or consent of the software maintainers.

spankalee 5y ago
What changes did they make to the code? None as far as I can see.
- sam0x17 5y ago
  The maintainer's intended release was text spamming the console. They replaced it with the old faker. This is changing the maintainer's code.
  - Macha 5y ago
    > https://github.com/Marak/colors.js/blob/5152d16f22789d66e107275e006f88517641ed18/LICENSE https://github.com/Marak/colors.js/blob/5152d16f22789d66e107... So can you point me to where this license says you cannot modify this code? Or that by accepting distribution of one version of this code, you are obligated to distribute future versions? You can't hide behind "The license doesn't say he has to play nice, so you can't complain about him not playing nice", then say it's unfair that npm don't go behind their license and TOS obligations to host his spite version.
    - sam0x17 5y ago
      Because they are interfering with _his_ distribution of the code. They are free to distribute it separately and make changes in those cases, but instead they are essentially re-writing history without the knowledge of the package owner, and for reasons that are largely editorial and, I think, unprecedented. They are interfering with his right to distribution, essentially. I know that in a slimy, technical way, you are correct, but I think it is relevant if at the end of the day it is practically impossible to distribute code without some unauthorized third party modifying it in transit, essentially. The implication is we need to start running our own git servers.

zamalek 5y ago

> I take issue with the title of this article. The author wasn't mentioned in the title at all: "colors attack." Names have to come from somewhere. The article is about some hypothetical future antagonist that puts a hack/bitcoin miner in their widely adopted package, or something. "Colors attack" is just the name of, effectively, the CVE.

nhoughto 5y ago

yeah i don't see it as an attack and was very surprised Github suspended his account, less so that NPM unpublished the package. It is easy to think of these platforms as unbiased repositories, but as soon as something is deemed 'wrong' suddenly you need to think what the criteria is for that decision, who makes the decision and how? Where is the line? Is an infinite loop is the line? Updating a package to display random text without an infinite loop is crossing the line too? Who decides what _my_ OSS library is allowed to do? Can I update it just to add a banner asking for donations? How is that functionally different to random text other than intent?

kristjansson 5y ago

He had two things: (1) the right to make and publish a change to a project he controlled and (2) a mechanism (npm and its ecosystems versioning practices) to have his changes run on thousands of machines. Making changes via (1) is not an attack. Leveraging (2) to cause ‘damage’ is without question an attack, even if the damage is just burned CI minutes and even if the victims’ comically poor practices bear some (most) of the responsibility.

tacone 5y ago

I regard that as an attack, specifically a denial of service. Whether he had the right to do so doesn't matter much, he voluntarily broke other people's apps. Btw, I'd say that he for sure has the right to write purposely broken code, but probably not to push it on npm (it depends on npm TOS, though). If it was for me, I would just suspend his npm account and keep distributing the existent code, since the license allows to do so.

hnlmorg 5y ago

I think "attack" still best describes the move even if it was an indirect attack (ie he poisoned his own code then others ran it). The intention was to create a denial of service "bug" as a protest and given it was deliberate I don't think the term "bug" is sufficient. But you're right it wasn't a direct attack and I'm inclined to also agree that it wasn't intended to be malicious (though not all attacks are). > In fact, I also take issue with GitHub / Microsoft taking over the package and am very worried about the precedent that sets, regardless if their motives this time appear to be entirely selfless. Yeah, I agree with you here.

pawelmurias 5y ago

They own the sites, they are allowed to get rid of some fuckwit.