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