Maintainers shouldn’t be malicious, absolutely, but users should do a bit more than pulling code and running it. Otherwise, it’s curl | bash dressed up with a ci pipeline. How many times does dependabot bump your dependency revisions and no one looks except to ensure tests pass?
And bad actors work in companies as well. At some point you just have to trust what you are using.
It's certainly impractical for every developer to vet every package they use, so much so that almost no developers vet any of the packages they use. What's needed are more gatekeepers. Repos like NPM would be well-served by coming up with mechanisms to support this. Off the top of my head, some sort of "this is safe" consensus, whereby the community can vouch for specific immutable versions of packages, that don't become the default version until they cross a threshhold. Organizations with a history of good stewardship and trusted validation processes could be allowed to skip the vetting step (e.g. things published by groups like the Apache Foundation or even corporations like Microsoft). I'm not arguing that one-man shops shouldn't be able to publish to NPM, just that there should be something like a "--untrusted" flag that's required before unverified updates are installed. And I'm not calling out NPM; every package repo has this problem.
This sounds like a gross misrepresentation of what happened.
It has been reported that the author of the colors and faker packages announced last year that he was no longer willing to do free work for Fortune500 companies.
He also proceeded to state quite publicly that either companies paid him for his work, or they should fork the project and maintain it themselves instead of taking advantage of everyone else's work.
After a year has passed, the author proceeded to release a couple of major versions that had a more artistic feel.
https://web.archive.org/web/20210704022108/https://github.co...
Source:
https://www.theverge.com/2022/1/9/22874949/developer-corrupt...
These packages are his circus, and his clowns run the act he chooses.
If anything, this update showcases the completely abhorrent security culture in place in these mega-companies, which literally ingest into their product line anything that they can find on GitHub without a shred of due diligence.
Artistic would be a new color scheme or maybe a “support open source maintainers” message. The accurate description you didn't give is sabotage because he introduced an infinite loop:
https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d1...
The author already did that, and complained about fortune500 companies mooching their work without giving anything in return.
The author stated that people should fork the repo if they intended to keep using it.
The author made said statements a year ago. Is a year enough time to take action?
Now the author decided to do a major version release with a protest version of his own work, and that makes him a villain?
He did more than that, as noted in the comment you replied to.
He really didn't. It matters nothing if you feel a commit breaks your code because you not only ignored the author but also failed to perform any sort of due diligence regarding what dependencies you ingest.
I mean, it was a major version bump. People blindly upgrade stuff without any regard about what goes in, and somehow that makes the guy who volunteered his work on a side project a villain?
There are a lot of red flags in this story, but the author of the colors flag ain't one of it.
Hint: going from 1.4.0 to 1.4.1 is not a major version bump — https://snyk.io/vuln/npm:colors
The definition of malicious, according to Merriam Webster[0], is the following
>having or showing a desire to cause harm to someone : given to, marked by, or arising from malice
Was the intention here to cause someone harm? What the intention here malice? Which conversely has this definition[1]
>desire to cause pain, injury, or distress to another
Was this their primary motivation? What evidence do we have that is in fact an action driven by malice? In fact, I don't see any, especially after doing roughly 20 minutes of research, I have arrived at the following:
Reading the public history surrounding the maintainer of these projects, the issue trackers of the repositories, and the maintainers own blog, you may come from a different conclusion entirely. If I was to speculate - and mind you, I am speculating, as I don't know the maintainer personally nor do I claim to understand them completely - there is a clear sense of mental strain they are feeling from the burdens here. Being burnt out, feeling taken advantage of, can lead to very real and deep feels of depression and/or other mental challenges (this I speak first hand to), for starters. I think the maintainer - again, speculating here, however evidence does seem to suggest this - is acting from a place of disillusionment, and possibly is resentful of their status in the word, relative to those benefiting from their contributions to open source software. Are they right to feel this way? Maybe, maybe not. However, is this malice? That's the question. Is this actually malicious? All evidence points to no, its not an act of malice. Its an act of someone who is disillusioned, strained, and struggling. I think the most reasonable interpretation given all the evidence is that they are trying to raise some kind of awareness - albeit in ways that I don't think is well communicated, due to the issues I previously highlighted - most likely.
I could be wrong, I'm just following the publicly available evidence and, its a lot more murky than this is an malicious act by a malicious maintainer acting in malice.
And again, this brings up the broader issue around open source maintainability, longevity, the role of consumer and maintainer, and how to build better symbiotic relationships around that, yet we aren't talking about what lead to this event, which I would argue is more important than what happened.
My ask is for nuance in this conversation, where there is seemingly little.
Unless he's gone absolutely bonkers, he's doing this to intentionally cause damage. The reason for it does not matter, as the definition you posted helpfully points out.
Was it malice when maintainers started adding those posinstall scripts asking for funding? which lead directly to the creation of `npm fund`, for instance. Was that also malice?
Given all the evidence we have - I think its murky. That's my point, at the end of the day.
Arguably, I could say that making millions of dollars off an open source library and not contributing back is malice - yet that argument is rarely given the same open and shut approval.
Mind you, this is bigger, IMO, than `faker.js`, this raises questions around open source software as a whole, that are relevant in this case and beyond
There's nuance in this conversation that is missing so far.
In any other context, it is argument against open source existing.
No, because that did not impair use of those libraries whereas this change deliberately broke every program written by someone who trusted him and used his code under the social contract he offered.
Open source maintainer funding and burnout are real problems but betrayal won't make things better. Imagine if you lived in a house with a bunch of roommates who weren't doing their share of the housework — you're entirely within your rights to stop volunteering to clean the toilet but it's crossing a line if you instead modify it to flush up.
This is very much a philosophical question and I doubt we will resolve it here on HN. However if you want to deem this act malicious I beg you to ask your self: To whom is the malice directed towards, who was harmed the most? What does this act tell us about the industry?
I, on the other hand, see this sabotage as a clear act of love from a fellow worker.
I would also strongly question any “fellow worker” explanation since I'm sure the pain will almost universally be felt by the “fellow workers” who have to update things, reassure their security team, or increasingly start justifying their use of open source software.
It certainly wasn't directed at the large corporations, they have many systems in place to mitigate this type of attack. It was directed at everyone else, like fellow open source devs, contractors, hobby developers, students, and small to medium businesses.
The goal simply appears to be chaos and attention.
If you want to get paid, or you require contribution, use an appropriate license. It's not hard.
aws-cli should not be an attack vector, and if it is, AWS engineers are at fault.
This has been posted before, but Marak seems to be mentally unwell right now, which helps explain but doesn't condone his behavior.
https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
Edit to Add: According to this page https://www.npmjs.com/package/faker
The previous version was 5.x.y and the endgame version was 6.6.6
So, which tools defaulted to magically bumping the dependency from 5.x.y to the 6.x.y? Seems like jumping a major shouldn't automatically happen.
Edit: your comment makes more sense now that I see it was talking about faker.js.
https://github.com/aws/aws-cdk/issues/18322#issuecomment-100...
This floating behavior allowed for it to be overridden locally:
https://github.com/aws/aws-cdk/issues/18322#issuecomment-100...
> Was the intention here to cause someone harm? What the intention here malice?
Yes. Removing / archiving the project – not malice. This, however is absolutely malicious:
let am = require('../lib/custom/american');
am();
for (let i = 666; i < Infinity; i++;) {
if (i % 333) {
// console.log('testing'.zalgo.rainbow)
}
console.log('testing testing testing testing testing testing testing'.zalgo)
}
Reasoning about Marak's motivation or intentions does have anything to do with whether his actions were ultimately malicious.
> Its an act of someone who is disillusioned, strained, and struggling.
You might be right, but there were a lot of things he could have done before doing what he did, and when he did act, he did it with the intention of causing people distress, frustration and confusion.
> ...its a lot more murky than this is an malicious act by a malicious maintainer acting in malice.
We're really far down a semantic rabbit hole at this point. Ultimately, adding an infinite loop to a widely used package deliberately and without warning is clearly an attempt to 'cause ... distress to another.' There's no two ways about it. Sure, Marak likely felt under-appreciated, mistreated and taking advantage of by large corporations etc but those possible explanations do not absolve him of blame, or mean his actions were not unequivocally malicious. In the legal system, mitigating factors can lead to a lesser charge or a shorter sentence, but even if they do reduce the severity of the outcome, you're still guilty.
The change has an infinite loop, so it literally breaks any software that uses it.
> If Lodash issued a breaking change...
It's called intent. Did Lodash _intend_ to break users' programs? Probably not. That's for a court to decide. Did this dude intend to break users' programs? The legal system is set up to resolve questions like this, not get fooled by clever gotchas from software developers. Intent matters in the eyes of the law and I'm utterly flummoxed and quite frankly concerned that so many developers don't understand that.
Simultaneously, pulling thousands of double digit layers deep of random-ass dynamic code dependencies is _also_ a bad idea at best, and professional negligence at worst.
The package author can be liable. The people who rely on him can, at the same time, make bad professional choices. Both things can be true.
This act is really no different then a strike. A striking worker is only malicious towards those who unfavorably profits from their labor. Other workers might suffer, but a true worker will stand in solidarity, for direct action is an act of love for the entire working class.
These comments on HN are sending a pretty clear message out... don't open source anything. It is really really unfortunate.
To be fair, Marak seems to be mentally unwell right now, which helps explain but doesn't condone his behavior
https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
If you're using a 3rd party dependency, especially one you aren't paying for, you should expect it to break or disappear at any time.
Some asshole maliciously breaking your stuff: no.
I do not use either colorsjs or fakerjs. I was close since I used the Ruby version of faker that Marak ported into nodejs as fakerjs.
If you agree that this is his library, do you believe what he did is different than a company changing their public API or deprecating them without any notice?
Similarly, if it was a service everyone understands that those require money to operate but there’s no analogous reason to tell people to upgrade to deliberately broken code.
Yeah, you can always just choose a different css-loader > cssnano > svgo > colors depchain, because there's plenty. Dependencies like that empower people great, and we all know what comes with it.
When you're in a hot summer bus, it's immoral to turn off the AC only because it was you who decorated the knob.
> Instead of talking about the role of maintainers, consumers, and what to do about the state of open source software and its longevity, we are instead using this moment to go after the maintainer as if they were doing the equivalent of using their npm packages to inject actual malicious, harmful code on the consumer machines, like a cryptominer.
I agree with all of your points. I would be more sympathetic to the backlash if those affected were paying license holders, but that's not what happened.
It is a privilege to use someone's hobby project that you didn't write for free and with no strings attached.
It isn't a privilege, as far as FOSS is concerned, it's a fundamental right. Whether one pays or not is irrelevant, that code was given to the community and it belongs to the community. No one, not even the author or project maintainer, has the right to vandalize community property regardless of their motives.
And FOSS licenses purposely give away many, if not all, rights typically granted by copyright. If I buy a book and I have the same rights as the author to rewrite and republish that book, and even put my name on it, even to make money on it, then it can be correctly described as being owned by the community rather than owned by the author.
> They chose to depend on the labor of someone who was not compensated for their time or work, which is a privilege.
The developer chose to give away their labor for free, they chose to forego compensation. The FOSS model is clear in considering the ability of the end user to read, modify and redistribute code without limitation to be rights, not privileges. Whether a developer can find a way to make money is orthogonal and incidental. That's a privilege defined by contractual obligation, not a right.
You can have FOSS or you can require developers be compensated for their efforts, but you can't have both. These two concepts are mutually opposed.
>No one is entitled to the developer's time or labor.
No one is entitled to make demands of the developer, but likewise, the developer isn't entitled to make demands of anyone else. As far as the fruits of their labors go, everyone is entitled to whatever they choose to give. That's the whole point of FOSS.
and faker.js seems to be more or less a port of a ruby library which was a port of a perl library.
It was not injecting harmful code onto the machine, it was not an "attack" on anything, in any real sense. I feel all the media is doing so far is raking the maintainer over a fire, instead of asking the question of how did we get here in the first place? Why would a maintainer feel they need to take actions like this? What are they trying to achieve?
Instead of talking about the role of maintainers, consumers, and what to do about the state of open source software and its longevity, we are instead using this moment to go after the maintainer as if they were doing the equivalent of using their npm packages to inject actual malicious, harmful code on the consumer machines, like a cryptominer.
I know it inconveniences everyone, sure, and would I have done this if they were my packages? No, I'd go through a normal deprecation process of announcing its deprecation, archiving the repository, and plainly stating that the package is no longer maintained. With that said, consumers can always choose a different library.
This wasn't malicious, or an attack. It was an update to the package working as the maintainer of the project intended. If lodash issued a breaking change, would that be considered an "attack"? They even followed semver, by bumping the packages to their next major version.
I think this event also served to expose how little organizations have around testing for breaking changes in their dependencies, which may be adding fuel to the issue.
EDIT: this is a plea for more nuance in the conversation. I think there has been an unreasonable amount of haste in passing judgement in this situation, that, after doing even just a little bit of background research, seems to suggest there is more moving parts than meets the surface.