sindresorhus / meow

🐈 CLI app helper
MIT License
3.53k stars 150 forks source link

Could you help remove the high severity vulnerability introduced by package trim-newlines? #195

Closed paimon0715 closed 2 years ago

paimon0715 commented 3 years ago

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

LitoMore commented 3 years ago

No.

FYI: https://overreacted.io/npm-audit-broken-by-design/

cronon commented 3 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.

ferdnyc commented 3 years ago

@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.

jimmywarting commented 3 years ago

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

ivanoats commented 2 years ago

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? πŸ™πŸΌ

voxpelli commented 2 years ago

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.

sindresorhus commented 2 years ago

I don't plan to backport to meow@3.