Closed paimon0715 closed 2 years ago
Why not? It doesn't matter whether you like npm audit or not, many people now are having problems with their CI's and you can resolve them in a simple way.
@cronon
Re: the "why not?", have a read over that blog post. It explains it at the end.
In the meantime, I am planning to close all GitHub issues from
npm audit
that I see going forward that donβt correspond to a real vulnerability that can affect the project. I invite other maintainers to adopt the same policy. This will create frustration for our users, but the core of the issue is with npm. I am done with this security theater. Node.js/npm have all the power to fix the problem. I am in contact with them, and I hope to see this problem prioritized.
I have no position on this, but if one does (as it seems @LitoMore does) and if it aligns with Dan Abramov's position, then you refuse these requests not because they are unreasonable or difficult to achieve, but as a protest statement against the current npm audit
functionality. To make the requested changes would give the appearance that npm audit
helped resolve a vulnerability and make code safer, instead of (as I understand Dan/Lito's view) forcing developers to make unnecessary changes (however small) in order to "address" problems that don't actually exist.
The terse, unequivocal rejection of the request isn't my way, particularly. (Then again, as you can probably tell from this comment I have a tendency to overexplain things. Maybe I just like the sound of my own "voice".) Thing is, tho, it's also not my code. So it doesn't matter how I, or you, or anyone else not involved with meow's development would handle it.
I kind of agree with @ferdnyc
sometimes i wish we had a choice and wasn't so dependent on NPM, but soon we will have support for http loader. Then we won't need any package manager anymore...
There are principles and protests, and there are also the existing ~33,500 downstream projects mentioned. It would be great if you just indicated that you can accept a PR that made things work for everyone. Would you be willing to slightly compromise your principles in exchange for making a lot of people happy? ππΌ
You are requesting an update to a six years old version of this module?
In comparison: Node.js LTS releases are only supported for three years.
All in all:
Any project using a 3.x
version of meow
must be extremely outdated (meow@4.0.0
was released almost four years ago) and should generally be avoided.
Remember:
npm audit
won't tell you if a module is safe to use, it will only tell you if it knows that it may be unsafe to use.
Using any six years old module that's six major versions behind the latest version should be very avoided and not be considered safe practice.
Hence patching that old version would serve nothing else than creating a false sense of security.
I don't plan to backport to meow@3.
Hi, @sindresorhus @LitoMore, there is a high severity vulnerability introduced in your package meow:
Issue Description
A vulnerability CVE-2021-33623 is detected in package trim-newlines(<3.0.1,>=4.0.0 <4.0.1) and trim-newlines@1.0.0 is directly referenced by meow@3.7.0. We noticed that such a vulnerability has been removed since meow@6.0.0.
However, meow's popular previous version meow@3.7.0 (6,322,587 downloads per week) is still transitively referenced by a large amount of latest versions of active and popular downstream projects (about 33,521 downstream projects, e.g., imagemin-pngquant 9.0.2, mozjpeg 7.1.0, gifsicle 5.2.0, image-webpack-loader 7.0.1, bugsnag-sourcemaps 1.3.0, @exmg/exmg-dialogs 6.0.4, etc.). As such, issue CVE-2021-33623 can be propagated into these downstream projects and expose security threats to them.
These projects cannot easily upgrade meow from version 3.7.0 to (>=6.0.0). For instance, meow@3.7.0 is introduced into the above projects via the following package dependency paths: (1)
@exmg/exmg-dialogs@6.0.4 β web-component-tester@6.9.2 β polyserve@0.27.15 β polymer-build@3.1.4 β sw-precache@5.2.1 β meow@3.7.0 β trim-newlines@1.0.0
......The projects such as sw-precache, which introduced meow@3.7.0, are not maintained anymore. These unmaintained packages can neither upgrade meow nor be easily migrated by the large amount of affected downstream projects.
On behalf the downstream users, could you help us remove the vulnerability from package meow@3.7.0?
Suggested Solution
Since these inactive projects set a version constaint 3.7.* for meow on the above vulnerable dependency paths, if meow removes the vulnerability from 3.7.0 and releases a new patched version meow@3.7.1, such a vulnerability patch can be automatically propagated into the 33,521 affected downstream projects.
In meow@3.7.1, you can kindly try to perform the following upgrade:
trim-newlines ^1.0.0 β ^3.0.1
;Note: trim-newlines@3.0.1(>=3.0.1 <4.0.0, >=4.0.1) has fixed the vulnerability (CVE-2021-33623)
Thank you for your contributions.
Best regards, Paimon