Conversation
This update is to address a security vulnerability allowing potential remote memory exposure on request<=2.68 Details: https://snyk.io/vuln/npm:request:20160119
|
cc @rvagg & @bnoordhuis |
|
LGTM, I guess, but it's not like we use request in a way that makes it susceptible to that vulnerability. |
|
it is not you @bnoordhuis but in case the library is used in other projects (like fsevents) you end in suggesting the vulnerable version in the packages resolution and so possibly injecting that version in who uses you. |
|
You mean because of npm@3 de-duping dependencies? node-gyp accepts a broad range so I don't think it matters as long as other modules don't explicitly depend on vulnerable versions. The same is true of fsevents, any [email protected] satisfies its constraints. Or rather, it satisfies node-pre-gyp's constraints - fsevents itself doesn't depend on request. |
|
ah ok this is a better explanation that i think it is solved. if there is no way to exclude a version ok i think with this clarification any user would be able to check that the right version is used. |
|
I'll go ahead and close, I think we have consensus that no changes are necessary in node-gyp. |
This update is to address a security vulnerability allowing potential remote memory exposure on request<=2.68
Details at: https://snyk.io/vuln/npm:request:20160119