SoylentNews is people
SoylentNews
from the with-great-responsibility-comes-great-LOLability dept.
From Bleeping Computer
Users of popular open-source libraries 'colors' and 'faker' were left stunned after they saw their applications, using these libraries, printing gibberish data and breaking.
Some surmised if the NPM libraries had been compromised, but it turns out there's much more to the story.
The developer of these libraries intentionally introduced an infinite loop that bricked thousands of projects that depend on 'colors and 'faker'.
The colors library receives over 20 million weekly downloads on npm alone, and has almost 19,000 projects depending on it. Whereas, faker receives over 2.8 million weekly downloads on npm, and has over 2,500 dependents.
But the target of this action wasn't the end user - but the big corporations...
[...] The reason behind this mischief on the developer's part appears to be retaliation—against mega-corporations and commercial consumers of open-source projects who extensively rely on cost-free and community-powered software but do not, according to the developer, give back to the community.
In November 2020, Marak had warned that he will no longer be supporting the big corporations with his "free work" and that commercial entities should consider either forking the projects or compensating the dev with a yearly "six figure" salary.
"Respectfully, I am no longer going to support Fortune 500s ( and other smaller sized companies ) with my free work. There isn't much else to say," the developer previously wrote.
Privacy Policy: We don't track anyone except on this site, so DNT requests aren't relevant and are ignored. We don't collect any personally identifiable information from you except your email address, which: you can change at any time, never has to be real in the first place, is only used to contact you if necessary or requested, and we share with nobody.
(Score: 2, Funny) by Anonymous Coward on Wednesday January 12, @02:02AM (13 children)
These apps are configured just to fetch whatever from wherever and execute it? Don't the app developers have to qualify and release a new version before that happens??
(Score: 4, Funny) by Fnord666 on Wednesday January 12, @02:09AM (8 children)
Unfortunately, many build pipelines and tools will grab the most recent version of a package by default. With continuous integration being a thing, builds can happen multiple times a day. This can be prevented by either locking the particular version of a package using the build tool or having a local package repository that the build pipeline points to and not copying new packages into that repo until they have been vetted.
(Score: 4, Funny) by PiMuNu on Wednesday January 12, @10:53AM (7 children)
The whole point of continuous integration is to support continuous testing. So a test server somewhere gets "bricked".
(Score: 0) by Anonymous Coward on Wednesday January 12, @08:35PM (1 child)
Testing... waaahaaahahahahaaha...
oh wait, you're serious?
(Score: 1, Funny) by Anonymous Coward on Wednesday January 12, @11:02PM
Everybody has a testing environment. But strange as it may sound some people are lucky enough to have a production environment.
(Score: 2) by Fnord666 on Friday January 14, @04:37AM (4 children)
If it didn't cause any of the tests to fail, would it go unnoticed?
(Score: 2) by PiMuNu on Friday January 14, @10:38AM (3 children)
Yes, but at least main workflows should be in any reasonable test setup...
(Score: 2) by Fnord666 on Friday January 14, @02:32PM (2 children)
What I meant was that if I introduce new code that does something nefarious but doesn't brak any existing functionality, would it be detected by automated tests? Test driven development, for example, results in tests that will detect changes that break existing functionality, but it won't detect any added functionality. I'm also not sure that source code analyzers, especially static ones, pull in and verify included libraries.
(Score: 2) by PiMuNu on Friday January 14, @03:02PM (1 child)
True. It doesn't seem to be what is happening here (where the new code is just locking up everything downstream).
Are you suggesting bad people can get into the code base and start doing Evil things downstream by manipulating a commonly used (but poorly supported) library?
(Score: 2) by Fnord666 on Friday January 14, @08:54PM
Yes. Either the library changes hands or a developer's account get compromised for example. Evil code gets pushed to the repository and automagically picked up by ACME's build pipeline without anyone validating the new version. Everything is code reuse these days where the first thing developers do is see if there's a library available to do whatever they need so they don't have to do it themselves. Depending on where they are working this code might come from some dodgy web site hosted who knows where.
(Score: 0) by Anonymous Coward on Wednesday January 12, @05:12AM (2 children)
Well they shouldn't and yes the app developers should qualify explicit version dependency as a good practice. But many don't, some don't know better, some are so tightly wound by their PHB to deliver, deliver, deliver by last week that all the good engineering practice goes out the window. The latter is very common in my neck of the woods and its not just 1 company its almost a local culture so not like you can just switch job.
(Score: 1, Insightful) by Anonymous Coward on Wednesday January 12, @12:38PM (1 child)
Package management for programming libraries is fundamentally broken. The process should be more akin to linux package managers where development is in a testing repo but releases are manually reviewed and signed by an independent maintainer after they're tagged. This stunt was mostly harmless [github.com] but the next one may not be.
(Score: 0) by Anonymous Coward on Saturday January 15, @10:44PM
Of course he knew nobody was going to pay him to work on it - "why buy the cow when you can get the milk for free", right?
But that whole free model has always had a cost to the developer. So not surprised that someone has said "fuck it, I've warned everyone, now they can just fuck off."
He doesn't owe the users anything, same as the users don't owe him anything. Reciprocity at work. You got something for free and it doesn't work? Aw, you're entitled to a full refund of what you paid.
Still not happy? You can always hire a developer. But the real problem here is WTF are people downloading a javascipt library 20 million times a week for? If your business is reliant on free javascipt libraries you're already fucked.
(Score: 2) by pgc on Thursday January 13, @01:05AM
Yes, they are