Slash Boxes

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: 0) by Anonymous Coward on Wednesday January 12, @01:19AM (7 children)

    by Anonymous Coward on Wednesday January 12, @01:19AM (#1211984)

    maven is my anti-npm

    Doesn't NPM have a way to specify version ranges or pin a specific version (like an LTS)? Does node really just autoupdate everything? That must be a nightmare, sort of like using Windows 10.

  • (Score: 4, Informative) by NPC-131072 on Wednesday January 12, @01:29AM (1 child)

    by NPC-131072 (7144) on Wednesday January 12, @01:29AM (#1211985) Journal []

    A misfeature in NPM’s design means that as soon as the sabotaged version of colors was published, fresh installs of command-line tools depending on colors immediately started using it, with no testing that it was in any way compatible with each tool. (Spoiler alert: it wasn’t!)

    • (Score: 0) by Anonymous Coward on Wednesday January 12, @02:06AM

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

      Well fuck.

  • (Score: 3, Informative) by Fnord666 on Wednesday January 12, @02:05AM

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

    maven is my anti-npm

    Doesn't NPM have a way to specify version ranges or pin a specific version (like an LTS)? Does node really just autoupdate everything? That must be a nightmare, sort of like using Windows 10.

    NodeJS has the package-lock.json [] file.

  • (Score: 4, Interesting) by vux984 on Wednesday January 12, @02:23AM (2 children)

    by vux984 (5045) on Wednesday January 12, @02:23AM (#1212000)

    Yes. Of course it does. You can pin to range or specific version. I build docker images and production installs using "npm ci" which ensures the version that is installed is the version that was tested and validated and referenced in the committed package-lock.json. You can also "shrinkwrap" with npm and so on. The issue is that most people don't know what the tools can do or how to use them properly. And that includes me...I'm still learning new things. Who isn't?

    The problem is that most people remain ignorant and don't care to get informed. npm install worked on my laptop... deploy to production the same way. That's not a flaw of npm. That's just people who don't know or don't care what they are doing. Eventually it goes boom.

    npm has semantic versioning and conventions around issuing new major versions for breaking changes so if you write code that works with major version 6, it should work 6.1. 6.2, and so on, and npm won't automatically pull 7 without a specific command once you've pulled version 6. Not everyone follows the conventions, but by and large things tend to work well enough most of the time that essentially you do have lots of rope to hang yourself if you simply skip using the deployment and publishing tooling, skip testing and CI, etc.

    • (Score: 2) by Moru on Thursday January 13, @06:09AM (1 child)

      by Moru (1248) on Thursday January 13, @06:09AM (#1212342)

      Apparently the problem also comes from believing that "npm ci" will save their bacon because it locks the versions. However that apparently only locks the versions you specify, not the second level of libraries pulled in by the things you pull in. And if this library pulls in even more dependencies you are sitting there using things four levels deep that you have no clue what it does with your server or your customers computers/phones. It's a disaster waiting to happen. It's enough with a developer getting an offer they can't refuse / get hacked and publish a cryptominer or something worse.

      (I never used npm really because of this fear so don't quote me, this is just what I understood from others using it and getting bitten)

      • (Score: 2) by vux984 on Friday January 14, @05:39PM

        by vux984 (5045) on Friday January 14, @05:39PM (#1212708)

        package-lock.json stores the entire dependency tree with all the actually installed versions, and npm ci recreates a node_modules folder with an identical dependency tree. What you are describing doesn't sound correct.

        However, in general when you publish a *library*, you don't (and shouldn't) shrinkwrap it. So if your lib pulls package^3.1.2, and you publish it, then when a developer adds your package to their project they get the latest version of package v3 not 3.1.2 as a sub-dependency, and that might be what they are talking about? If there is a breaking bug in 3.1.5 then you will get that bug when they add your package that depends on the now buggy package.

        But since this all happens when you add a package to your project, you should have problems in dev/testing; you'll discover and fix it (there are a variety ways -- ranging from overriding your tree to pull the older sub-dependency version to submitting a pull request and getting the problem bug in package 3.1.5 fixed in 3.1.6 and then updating) and when you go to actually publish an application you'll have fully vetted and tested it (right? RIGHT?!), and your application dependency tree is known-good, and then npm ci will replicate that exact tree in production.

        The reason the *libraries* don't generally pin their dependency versions when they are published is to allow for point-release bug fixes to make make it downstream, and to minimize the number of copies of the same library with slightly different versions... you don't really need or want a copy of package@ 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6... to satisfy dependencies when they will all happily work with 1.1.6. (especially in browser apps which are already accused of bloat).

        That said, if you do want to pin everything, there are solutions; you can fork your top level dependencies and shrinkwrap them. And then any pull of those libraries will get you the same (sub)dependency tree that was committed. I'd argue that this is not appropriate or necessary (and even counter productive) for most mainstream packages, but it definitely has it's place.

        All this said, while I do work with it, I don't consider myself an npm expert by any stretch.

  • (Score: 2) by pgc on Thursday January 13, @12:51AM

    by pgc (1600) on Thursday January 13, @12:51AM (#1212262)

    Yes, simply don't use the '~' and '^' .

    But somehow they prefer the package-lock.json file instead.