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.
(Score: 2) by Moru on Thursday January 13 2022, @06:09AM (1 child)
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 2022, @05:39PM
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.