-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backport non-breaking security-related fixes to v10 #243
Comments
$ npm i make-fetch-happen@10
npm WARN deprecated @npmcli/move-file@2.0.1: This functionality has been moved to @npmcli/fs
added 68 packages, and audited 69 packages in 2s
found 0 vulnerabilities
~/D/n/s/mfh $ npm audit
found 0 vulnerabilities What vulnerabilities? Package-lock entries are not really vulnerabilities as they do not affect what the user will get when they install a module in their own project. |
The issue does not mention anything about vulnerabilities (there are other bugs fixed), but since you brought it up: In the case of A user utilizing lockfiles (yarn,npm,pnpm,shrinkwrap all apply here AFAIK) who are on an existing installation of The latest public release of This is a potential risk for users of packages using |
Typically we don't bump semver ranges in a package.json to clear security vulnerabilities. The semver range allows for the fix, and folks can run their own audits. The v11 bump of http-cache-semantics was not normal. We don't currently plan on backporting fixes to v10 here, given the imminent EOL of node12 and the fact that the semver ranges in v10 allow for an install with no vulnerabilities. I don't know of any other "non-breaking security related fixes" this module got. The file permissions change was a breaking change and can't be backported. Looking at the changelog it's all dependency updates and a change to allow configurable cached headers. |
Maybe you consider the way others use your software misguided. This is, however, a release-blocker for the maintainers of The use there is minimal and either way I'm sure that situation will be resoled somehow, whether through replacing the http library or something else. There are many others who are in similar situations with supported versions still on 12 and 14 with their own reasons why some issue needs fixed and why a |
Looks like we replied on the same time. Thank you for taking the time to explain the stance of the project and considering the issue @wraithgar. |
I'm sorry but maybe I'm not seeing where the issue is, there are a lot of comments sprinkled now through half a dozen repos. If there are package declarations in v10 that have engines declarations that are out of band with the engines declaration in this module that's actionable. I don't see that as the case currently and that is one of the things we check during our CI via template-oss "check engines" step. |
Is there an existing issue for this?
Current Behavior
make-fetch
v10
is exposed to several issues through its dependencies. (#210, among others).make-fetch
v11
fixes these, but breaks compatibility with Node.js v12 through bumps ofcacache
(#184)minipass-fetch
(#186), andssri
(#187).Expected Behavior
While Node.js v12 is EoL as of 2022-04-30, several ecosystem packages still indicate support for it in their mainline versions.
Releasing a non-breaking backport 10.x release addressing security issues and subdependency deprecation (to reasonable extent) would be very helpful and provide protection for users who are yet to update (perhaps because they are using node-gyp...).
It would also make it more straightforward for lagging dependent packages to make the move off Node 12 themselves.
Steps To Reproduce
n/a
Environment
n/a
The text was updated successfully, but these errors were encountered: