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.
Wow!
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.
No there isn't. What there is however is the actual contract of the repo (MIT License):
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Listen, open source is about freedom, and the author is perfectly within his rights to freely change HIS OWN REPO as he wishes. Just as anyone is within his rights to freely FORK THE REPO.
This is open source.
No, it's not.
The idea that you can waive the implied warranty of fitness for a particular purpose covers good faith mistakes or omissions. It doesn't cover intentional misrepresentations or excuse blatant fraud and criminality. For instance, if you sneak in a ransomware package, it's not "all good folks" because "there's no warranty, it's my repo and you can munch on my nuggets."
The author offered something to the community on certain terms and made certain representations. The author then decided that they had sellers remorse, and instead of acting like a professional adult who realized they made a poor investment (and finding a new maintainer), they threw a tantrum and decided to try and stick it to "the man" by violating the representations they previously made to the community as a whole.
This was petty, petulant and in bad faith. Does it rise to the level of criminality? It might, IANAL though. Nobody's going to go after them because it was more immature than truly harmful.
There was a time where we'd say "yes, this is cool. I'll use it" and we moved on. Now you can't publish something online without an army making frankly toxic demands on your time because they feel there is something wrong with what you made.
The attitude you are displaying right now is the one that birthed CoCs and the various other straitjackets that we use these days because folks have lost the ability to tell a toxic community to go jump in a lake when they make demands they shouldn't. And it is a shame, because the permissive and open climate is what makes open source: If you don't like it, you fix it.
Asking you not to intentionally break a package you know 20,000+ products rely on as a result of your representations hardly seems like a toxic demand on their time. They hadn't committed to the project in over three years. All they had to do was continue not committing to it.
Asking them to find a new maintainer or not intentionally wreck other people's work that relies on it isn't a toxic demand, it's asking for a modicum of respect.
I'm not saying you have to keep building sandcastles, im saying if you decide to stop for whatever reason its not a toxic demand to ask you not to knock over 20,000 other sandcastles on your way out - out of spite.
This feels like a clear case of stupid games -> stupid prizes.
Then the OP decided to make a new change for his own castle.
"Draw a vulgar expression on the front door."
Which 20,000 people blindly copied and then have the audacity to complain about.
[edit] To be honest you're not even advocating for a coherent model of open source software. Should everybody consuming every library fork it in case the author throws a tantrum? That hardly seems workable. The author didn't just stomp on big company sandcastles, the author knocked over everyone's. Every pet project, every startup getting off the ground.
For what? Sellers remorse. Author wrote something and gave it away, then regretted giving it away. Sorry.
Yes you should always fork open source projects critical to your project that are not mirrored somewhere safe, you never know when they may be inadvertently deleted, that's just common sense.
For dependencies, simply pin your versions and put library upgrades through a code review, that way no unknown code enters your system. Or just wait a couple days after a new release, the shit will hit the fan from all the incompetents.
> That hardly seems workable
Right, no one wants to do the work.
> For what? Sellers remorse. Author wrote something and gave it away, then regretted giving it away. Sorry.
For what? Buyers remorse. You blindly pulled code without looking at it, then regretted pulling it. Sorry.
These are all solid recommendations but don't excuse shit behavior on behalf of certain poor participants in the ecosystem. Which it seems you're super eager to do for some reason.
> Right, no one wants to do the work.
I mean so far it looks like one guy lol.
> For what? Buyers remorse. You blindly pulled code without looking at it, then regretted pulling it. Sorry.
We're talking about this guy's motivations not that of the consumers.
Why not? You are excusing the incompetence of everyone affected by this.
I won't edit my comment above except to note what the original parent comment was:
" The author committed malware to a package many relied on, that they had not made a commit to in 3 years. My point is not that the author committed a ransomware package but that the idea there is a blanket waiver of warranties that covers whatever you wish it to is trivially falsifiable."
The definition of malware for the record is:
... software that is specifically designed to disrupt, damage, or gain unauthorized access to a computer system.
I suspect not, because they would be sued into the dirt for breech of contract and shortly find themselves out of business. In fact I believe the customers could even sue for specific performance and force the seller to actually execute the contract as committed.
It's not that I hold free software to a higher standard, I hold folks to the standard they committed to. The author had big sellers remorse, upset that they had offered this software free of charge. I'm sorry, we all make decisions we regret. If they didn't want to maintain it anymore they could have found a new maintainer. Instead they decided to mess with the computers of people who accepted their representations.
https://9to5google.com/2015/04/10/nexus-5-nexus-7-bricked-an...
To their credit they stood behind it. Mine was repaired, FREE (October 2015)
But here's the real context on Point A since you don't want to actually look into it further and most outlets aren't going to bother doing it either. Once Google realized what was happening, well, it kept happening. They were pushing these OTA updates in some cases with 0 user intervention. Not to mention you're taking the comments out of order. That specific commenter had his device bricked multiple times. Why don't you quote that part of his dialogue?
Maybe you should ask why devices would be bricked in the same way multiple times?
Some anecdata: When Garmin bought Navionics they cancelled everyone's paid lifetime licenses, pushed updates demanding logins (worse in this case than others because 99% of the places you'd use their software have shitty internet, so an intermittent login wall is a bit crippling even if it were free) and monthly subscriptions, and hounded every negative review saying that they were doing it for the users' own good. Could a person sue for $19.99 and not have corporate lawyers juggle you between headquarters in Kansas and Italy? Maybe, but it's a pain in the ass for minimal gains.
After thinking about it for a while, I think that you are right, there is an implicit social contract when using open source software, and a part of this contract would be to expect the maintaining people to provide the best quality software they can create.
But the thing about contracts is that they work between multiple parties, and not just the maintainer(s) and some void. And consumers of the library didn't do their due diligence, that is, supporting the code that they rely on.
So you don't even know what happened?
There's an infinite loop after it finishes printing garbage. It's an unquestionably harmful change.
Also, you know how you prevent non-commercial use?
https://github.com/Marak/colors.js/blob/master/LICENSE
-
I don't get it, Marak is clearly having some sort of episode*, and people are bending over backwards to rationalize the result as if there's some clear connection between his intent and his actions.
How many people realize he made those anti-commercial comments two years ago. Right now it actually seems like his comments were more political than financial.
* I don't mean that in a backhanded way, based on his history and his recent comments I think this is someone who needs help regardless of his actions on NPM*
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.
No. You use what they wrote because they allowed you to. It is not then their responsibility what you do with it or how things inconvenience you. It is up to the user to vendor the dependencies and make sure everything works the way it should.
> The difference is merely a matter of degree.
In the same way that using your front door to break someone's nose on purpose and someone skinning their knee on an unfortunately placed step in your garden is different degrees of assault, sure (i.e. it's not and the only way in which it is is pedantic and not useful).
There is also no obligation for you to use or distribute newer versions, even if you are NPM.
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.
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.
> 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.
To be clear they do not owe us to produce good code, or to keep producing code, or to produce the code we want; it is remarkably close to charity giving: the developer/mantainer is donating their work/code to the community.
Just like charity you should not give poisoned gifts.
The kid that gave homeless people oreos with toothpaste filling wasn't charitably offering food to someone in need, he was maliciously offering them a "poisoned" gift.
The author published the packages to a public registry with the expectation that the code would be run by others, it was not just a random github project, it literally invited others to run the code by being registered on npm.
The author explicitely offered no warranty on the code, but distributing malware is both illegal and against npm ToS.
Being an open source developer does not put you above ethics.
The only thing that would change this would be if some third party was mirroring their code on npm without the author consent.
The colors library has an infinite loop and you shipped that version to your end users? That's on you. Test and pin your dependencies. Not doing so is the true offense. Be upset with AWS and the likes who will run unvetted third party code on your machine.
Also note that an infinite loop is not malware. Implying such is insane. Are you now going to call every piece of crashing software malware?
I believe this is akin to not driving dangerously on the road. There is obviously a social contract. This what living in a society is all about. Just because someone can do something doesn't mean we can't expect otherwise.
His work benefited from the work of many other people who also released open source software. That not only includes the packages that he released, of which he had other contributors, some of which actually wrote more of the package than he did (colors.js) as well as packages that he more or less did a direct port from (faker.rb and CPAN::faker). He also benefited from the entire npm/node ecosystem.
People have every right to be pissed.
Completely agree.
But the key concept that keep avoing is malicious intent.
Let's make an analogy in a completely different topic: Are (D)DoS attacks wrong? do people owe us not to (D)Dos our machines?
On one hand we connected our machines to the internet and declared ourself as ready to accept incoming traffic; on the other hand spinning up a bot army to render said machines unsusable is not nice.
Is it correct to say that you should have some kind of (D)DoS pretection on your services? yes. Is it also correct to say that people should refrain from crapping on other people stuff? also yes.
Getting back on topic; there is possibly a solid case to argue that this was not criminal (as no unauthorized "access" happened) but as much as open source volunteers should be more appreciated the "don't intentionally damage stuff with the SOLE intent of damaging stuff" is something expected of any human regardless of their social position.
Yes, if you attack infrastructure that you do not have permission to test. Here people downloaded code, ran it on their own infrastructure (or worse: shipped it to their users!) and were surprised this code did not do what they expected.
So, the only malicious actors here are those who shipped the package to their end users. Not the developer, they did not ship the code to anyone. They simply released a new version that other people chose to download and include in their own work.
To be clear, it's a total dick move and I don't support it at all, but the real blame should go to those who blindly download such code and run or redistribute it.
We need better tools to prevent things like this from happening again because nobody is ever going to audit the 2000 dependencies of every new create-react-app release.
The open source developer didn't run anything on your machine. You ran it on your machine. The developer published code. Others blindly pulled the update, and that propagated.
Why would I be thankful for that?
If you slap me, should I be thankful that my nose wasn't broken?
If your business or development practices depend on pulling a bunch of packages from NPM or other sources un-audited and so forth - especially straight into production! - you need to seriously rethink things. You got off relatively light, this time, if you were impacted by this.
When they set their dependency versions to 'latest', that's exactly what they are doing.
at least that seems to be quite common in the npm/js world.
They did. They chose not to pin their dependency versions, so this is their clear explicit choice. They also chose not to test their dependency updates before pushing it through to their end users, pure negligence by e.g. AWS who was affected by this.
Yes, they did. Have you read the article ? That's how npm works: it always pulls the latest version.
You can't use tools you don't understand and blame someone else if it doesn't work as you expect it to.
No, it pulls the specified version.
The affected packages fixed it by removing the leading carpet in the version specifier, which was designed to allow patch version bumps for things like security fixes.
He literally abused the versioning system designed to allow security fixes by introducing a breakage and disguising it as a non-breaking change.
Do I really think he's a jerk? No, I think he's unwell. Previous headlines, lots of conspiracy theory posting recently, now this. He needs help.
Do I think this is an attack? We call other exploits attacks. The shoe fits. This was a deliberately hostile act.
Why are they drinking from someone else's well? Someone with "a sizeable past history of jerkdom"?
If you can check the water - nay, if you can copy the water and check it, and create an identical well from that water so that said jerk may never interfere with it again - then the "victims" have no one to blame but themselves.
If he had poisoned other people's wells you might have a point. He didn't, in the same way that poisoning the water I keep in my fridge is not an attack on anyone else. Why do you trust the water in my fridge without checking it?
Because the well said "free water". And in some cases it's not even them taking water from that well, but other people who they asked to bring them tea (third party libraries).
> Someone with "a sizeable past history of jerkdom"?
Do you really dig through the internet history of every maintainer of every package you ever used?
No, because that would be impossible but I do try to check the libraries I use to the best of my ability, the same with browser extensions I install. I even read the ingredients on things I buy. Sometimes I read the instructions on drugs I'm prescribed.
The perfect is the enemy of the good, after all.
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.
I wonder if GitHub/NPM even have the legal rights to modify the code you publish, depending on your license.
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.
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.
Why is that? Do NPM package managers not create a lock file that is a text file anyone can peruse?
apps generated via create-react-app have more than 2000+ transitive dependencies.
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
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?
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.
It's more like, "I let some random guy do whatever he wants to my garage door and he decides to brick 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.
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?
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
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.
Who has done this? Can you point to it?
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.
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.
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.
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.
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...
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?
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...
Because that is the precedent we are setting here.
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.
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.
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.
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.
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?
Otherwise, a multi-owner org should be used, or we need new concepts (like changes to repositories signed by multiple contributors.)
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
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.
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.
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.
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.
I think it's more akin to lacing the M&Ms than simply swapping out for sprouts. He pushed a deliberate denial of service with the express purpose of causing harm to as many others as he could. Even joked about it in the ticket system. Knowing full well his purported target of large corporations have layers of systems in place such that would be unaffected.
I do sympathize with him, but his actions have made him appear extremely troubled, vindictive, and callous. The OSS community may yet forgive, but he shut a lot of private sector doors permanently.
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?
I think we just need to assume all of them are bad actors and review our dependencies (yes, unlikely to happen in practice given limited resources but that's a problem for someone else to solve).
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.
None as far as I can see.
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.
Again, if Marak is going to rely on technicalities, I don't blame npm for treating him with as much good faith as he treated his users.
Can you actually point to any code - or any package contents at all - that they changed?
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.
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.
You can't just update your extensively used code to add some ransomware or virus and be let off the hook because you warned users in a text file. The legal system will check what did you know and what your intentions were.
In this case, not that the author did a bad attack, but it's still a jerk move when the intention was uniquely to disrupt others and break things.
law
EDIT: At lest in some places.
Except for that he didn't just delete the code. He added malicious code that without warning broke applications at runtime, most likely disproportionately affecting small projects that lack rigorous dependency controls.
Companies can change their revenue model, but they don't get a blank check to do anything they want. See Toyota's recent blow-up with the key fobs as a counterpoint to your argument. It's one thing to phase out support for an old product. It's quite another to yank out the rug from under people without warning, and companies don't get a pass on that anymore than this guy should.
https://sugarclub.sugarcrm.com/engage/b/sugar-news/posts/sug...
Since he's been acquired in the past, he could also make it into a SAAS play. He has the connections, skill and experience.
Otherwise, he can just walk away like everyone else. Maliciously changing code to break people's stuff is uncalled for. If he wanted to charge people from the start, then maybe he shouldn't have used the MIT license for his code? If you want more restrictions on usage, choose a more restrictive license.
On a related note, the developer in question is not well mentally which helps rationalize what he did
https://www.qgazette.com/articles/more-charges-possible-for-...
"A team of NYPD investigators and FBI agents found potassium nitrate, which is used in fertilizer, metal containers, fuses and other bomb-making materials in the crate, along with printed bomb-making and survivalist materials and a book on how to make a bomb scattered throughout the home, the source said."
“'The chemicals separately are what they are, but taken together they can assemble an explosive device,' NYPD Dep. Commissioner of Intelligence and Counterterrorism, John Miller, said. 'There were books about military explosives, booby traps and other things.'"
The real question is whether you believe as a maintainer you have the right to do whatever you want to your code while in the knowledge that others will run it.
The emphasised part is important. I have zero issue with people writing malicious code purely out of academic curiosity but if you write in with the intention of that code propagating, as this author had done, your actions become far less sympathetic.
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
> 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
> 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
-
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.
First you wrote a rant that promptly got flagged before I even had to read it... now you're putting words I didn't say into my mouth.
Are you just incapable of having a mature conversation about this subject?
-
It's becoming a little clearer what kind of mentality it takes to defend how the creator of colors handled this situation. Some of us are able to both:
- understand the frustration of feeling your work is unappreciated.
- realize there are better ways to show frustration than proverbially flipping over the table.
I mean I've literally defended this guy, Marak, before on this website, when people tried to jump to conclusions about his alleged 'bomb making'
But this is ridiculous. It's gone past compensation even, he's ranting about GamerGate and stuff and using broken packages to make political statements.
That's not a mature or effective way to do anything except yes... get yourself banned from multiple platforms for breaking the ToS you signed up for in the first place and leveraged to even get the kind of reach you have.
Plenty of SaaS providers end up using GPL code as if it was MIT since no distribution = no virality.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
> 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.
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?
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.
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.
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.
Does that mean corporations have no responsibility? No. But it's also the case that we live in a society and your ability to wreak havoc because you can shouldn't be empowered.
a maintainer breaking backwards compatibility is not malicious.
The faker.js code is intended to be malicious, and thus should be treated differently to another project which might break your code in other ways. Because it's not about breaking code, it's about the maliciousness - the same would still apply if the faker.js trojan is more hidden, and thus was not discovered (e.g., they embed a crypto-miner into the library and extract compute resources secretly from those who use it).
> attack (plural attacks)
> An attempt to cause damage, injury to, or death of opponent or enemy.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?
which seems like very much akin to what they are doing now.
To add, unused/squatted npm package names regularly get reassigned[2].
0: https://www.npmjs.com/package/colors
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.
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.
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.