What a lovely surprise for a Monday morning.
We use the JS AWS SDK v2 and discovered it as waves failed to deploy. If you’re about to deploy anything new to production best double check you’re not affected.
3 Likes
lock files should avoid this problem, at least until you bump versions in the lock file
2 Likes
Open source is like
- I don’t give people free candy => It’s fine
- I give people free candy => You’re awesome
- I stop giving people free candy => It’s fine. Thank you for your contributions.
- I poison it then give people => ?!!
2 Likes
Yeah, after reviewing all our setup I think we’re ok pretty much everywhere. I incorrectly stated the JS AWS SDK v2 was affected. Seems to be only the CDK - so we’re still not sure what’s causing the waves deploy to fail.
yeah, its not like these packages from that users where rocket science… really embarassing behaviour.
2 Likes
This story is pretty crazy. Not sure if this is the same guy but seems to be.
The commit where he breaks things is an interesting and sometimes funny read
1 Like
Some sources said it was the same guy. The problem is there are many people who think he has rights to poison/malicious his packages. What is wrong with the people.
Almost as cringe as the twitter mods
Well, if they are his packages he can do what ever he wants with them, the license is explicit that there are no guarantees. If you haven’t payed for it or have some other contract there is nothing you can do, nor do you have any right to demand anything.
This has been a security and ethical issue with FOSS that has been raised from quiet early days that malicious code could be inserted. When it comes to malicious things inserted we had recently a major institution trying to do that to Linux Kernel.
Then we had the left pad fiasco and so on. So this is an ongoing issue. Another is financing for FOSS.
I have looked into this a bit further and there is more to it than that he just woke up one day and decided to do this.
The following article gives a bit more background:
In short he did all the right things that are being told to open source developers. He developed a library that became popular, he then created a service to monetize it and make it even easier to use. Then came a corporation, took his service, copied it and made it free (while actually using his CDN) and so on, effectively driving him out of business. From other things that I have gathered he got into financial troubles this year with his house burning down. So I think the main focus was faker.js and color was just to bring attention to this, but I think given everything what I have seen he is not in a good mental state.
If the intent was to get attention to this, then it worked perfectly. In a bad way, but at the same time I don’t know about any other way that a developer would be able to get attention from corporations. Reaction of some of the people and my personal experience with maintaining FOSS are really making me reconsider my future involvement in anything FOSS.
Moral of the story: take care of your dependencies (don’t forget nested dependencies), test when you update your dependencies and support FOSS packages that you depend on if possible (this especially applies for companies).
4 Likes
Well, if they are his packages he can do what ever he wants with them, the license is explicit that there are no guarantees. If you haven’t payed for it or have some other contract there is nothing you can do, nor do you have any right to demand anything.
100% percent agree, he even got locked out from Github and NPM.
It goes further than. Apparently NPM even manipulated the package to “fix” the problem.
This is where things really get messed up in my opinion, also quiet a turn from the left pad fiasco. I will have to make some hard changes for any of my future works and in using these services.
I believe what happened is ultimately in his favor, it shows how FOSS developers work goes unthanked. Self hosting seems the way to go nowadays.
From what I have seen, I don’t think he is in a clear enough state of mind. But it got the point across to those willing to hear it, though it might have just been preaching to the choir. Sadly I don’t think much is going to change, if anything, to the better.
1 Like
This involves a number of things:
-
License of the code - both the owner and end user “agrees” to that license
-
Terms and conditions of the platforms: versioning, distribution, etc. - owners, maintainers, forkers, developers agree to the terms of these platforms on sign-up.
- ownership of code
- distribution rights
- access to the platform
- Name of package - who has the rights to the name of a package? Can npm revoke “ownership” of a package name?
@storyteller I used the wrong word. Yes, he has rights to do whatever he wants. But lots of people think other companies used those packages deserve it. They think he did the right thing.
Well, that is the problem with this case. I would say that he did and did not. I think breaking faker was a legitimate defense. Breaking colors not, but at the same time it was probably the only way to get notice.
Either way as @rjdavid pointed out this includes multiple of things. It has also (again) revealed shortcomings in software architectures when it comes to dependencies, so I think part of the anger directed at him is due to the fact that it is easier than to admit that they got schooled about inadequacies of their dependencies management.
For example in Meteor I do believed that there was a part that used colors, but I have changed that to chalk after doing a due diligence and choosing chalk because it was used in other parts of Meteor and had more activity among other things. So we did not get into this problem. Even if colors remained this issue would still not affect Meteor as any changes to Meteor need to go through the full testing suite which would not have passed.
Some people seem to be on the opinion that if the author of an npm package has not signed a document explicitly stating that they will not intentionally publish malicious code in their packages, then in fact they have every right to do so and use their position as a package author to intentionally break software using those packages. Along the same line, people often tend to have a very black and white interpretation of the law. Let me assure you, this line of reasoning would not get you very far in a court of law.
A couple of centuries ago a school of thought existed that tried to remove all ambiguity from law by trying to codify law as essentially a series of explicit if statements. That of course failed miserably. Life is too complex for that. The modern approach is mostly the opposite. The written law provides foremost a set of guiding principles (general values, if you will, starting from constitutions) and it is up to the judge to solve individual cases under these.
Against such background, civil law, at least in most western countries, has some catch-all general stipulations that are meant to apply almost everywhere. One of these is a stipulation that parties to civil relationships must always act in “good faith.” Another is a principle of “reasonability.” These obligations do not need to be referenced in documents that create rights and obligations, they apply regardless. In other words, you don’t need to explicitly stipulate in an agreement that the other party needs to act in good faith, such obligation arises from the law directly (although for various reasons sometimes this is mentioned in agreements).
If a popular npm package is used by many apps downstream and the package author, using their write access to the package, intentionally publishes malicious code to break those apps, then this can in no way be seen as acting in good faith. Some of these apps can be mission critical and breaking these can cause a lot of damage in hard cash. The particular developer in this case would have a really tought time explaining to a judge why the bailiff is not entitled to sell his house to compensate at least a fraction of these damages to some plaintiff.
The legal way for the developer to express his wishes here would have been to make his code closed sourced and try to sell directly to individuak buyers (probably not practical) or just change the terms of their license and then sue infringing parties (again, probably not practical). The solution that he chose is simply illegal and opens himself up to lawsuits.
So a general principle for us all - let’s just try to act in good faith.
PS. I was an attorney for over a decade, doing mostly civil litigiation.
7 Likes
I am lucky enough to be using a package-lock.json. Is there any known way in which the lock file would not protect against this kind of update? For instance if it had been a patch semver bump rather than major?
I also use renovate that created a PR for the faker@6.6.6 upgrade that had build and test workflows failing, so it would not have been automerged. To prevent future update attempts, in renovate.json you can add
{
"packageRules": [
{
"matchPackageNames": [
"faker"
],
"enabled": false
}
]
}
1 Like
Indeed the situation seems to be involving a lot of contradictory principles:
- The author of the library acted in revenge (and in general, seems to be in a vulnerable mental state)
- The library is released under a “no liability” license
- One could argue the license says nothing about versioning: while you cannot be liable for a specific version of your software, can you be liable for sabotaging the versioning system by abusing trust you gained with one version of the software to push another version?
- NPM probably has some sort of code of conduct which places sabotage in the “bad” category
- All of the chaos could have been avoided (and thus deprive the author with the possibility of this kind of revenge) with proper dependency management.
Not sure these can be put on a Manichean scale. It’s a though job to make a judging decision. Certainly not mine.
It looks like the community picked it up.
I always thought open source is an extremely resilient code base. You just don’t know, who and when it will be forked and revived. Some say NPM should not promote the latest version, but personally, I think it is a good way to catch things like that, quickly. With so many fresh eyes downloading the latest, it is just a matter of time that someone will catch and fix the issue, and the hope is that the damage is not as severe for those new projects. Meanwhile, production projects can hold a bit until the field is clear before moving forward.
With regards to the author, while I don’t approve of his actions, I do hope for an easier way for open source maintainers to get money for their work. I mean with all the promises of digital coins, micropayments, web3, and smart contracts, one would assume the dev community would manage to find a way around this by now.
Most importantly, I think mental health and tech (especially coding) definitely need more studies and research. There are many stories of brilliant programmers suffering from mental issues, it seems systematic, yesterday I was reading the story of the creator of TampleOS, a tragic story. Coding is a relatively new field, who knows what those long hours of spitting logic against complex problems do to the mind coupled with financial and social challenges.
4 Likes