Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Wednesday January 12, @01:05AM   Printer-friendly
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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Funny) by Anonymous Coward on Wednesday January 12, @02:02AM (13 children)

    by Anonymous Coward on Wednesday January 12, @02:02AM (#1211991)

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

    Starting Score:    0  points
    Moderation   +2  
       Insightful=1, Funny=1, Total=2
    Extra 'Funny' Modifier   0  

    Total Score:   2  
  • (Score: 4, Funny) by Fnord666 on Wednesday January 12, @02:09AM (8 children)

    by Fnord666 (652) Subscriber Badge on Wednesday January 12, @02:09AM (#1211994) Homepage

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

    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)

      by PiMuNu (3823) Subscriber Badge on Wednesday January 12, @10:53AM (#1212065)

      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)

        by Anonymous Coward on Wednesday January 12, @08:35PM (#1212204)

        Testing... waaahaaahahahahaaha...

        oh wait, you're serious?

        • (Score: 1, Funny) by Anonymous Coward on Wednesday January 12, @11:02PM

          by Anonymous Coward on Wednesday January 12, @11:02PM (#1212236)

          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)

        by Fnord666 (652) Subscriber Badge on Friday January 14, @04:37AM (#1212604) Homepage

        The whole point of continuous integration is to support continuous testing. So a test server somewhere gets "bricked".

        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)

          by PiMuNu (3823) Subscriber Badge on Friday January 14, @10:38AM (#1212648)

          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)

            by Fnord666 (652) Subscriber Badge on Friday January 14, @02:32PM (#1212668) Homepage

            Yes, but at least main workflows should be in any reasonable test setup...

            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)

              by PiMuNu (3823) Subscriber Badge on Friday January 14, @03:02PM (#1212673)

              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

                by Fnord666 (652) Subscriber Badge on Friday January 14, @08:54PM (#1212762) Homepage

                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?

                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)

    by Anonymous Coward on Wednesday January 12, @05:12AM (#1212036)

    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)

      by Anonymous Coward on Wednesday January 12, @12:38PM (#1212083)

      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

        by Anonymous Coward on Saturday January 15, @10:44PM (#1213022)
        This stunt was yet another warning that will be ignored. The guy warned everyone in November of 2020 - 14 months ago - to either fork it or pay him to work on it.

        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

    by pgc (1600) on Thursday January 13, @01:05AM (#1212265)

    Yes, they are