-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Fix vulnerability in tar < 4.2.2 #3598
Comments
We are standing by for now, waiting for a new |
I could use some help here. Vulnerabilities keep getting reported for transitive dependencies of Test case:
update to latest devel:
Edit diff --git a/src/package.json b/src/package.json
--- a/src/package.json
+++ b/src/package.json
@@ -49,7 +49,7 @@
"log4js": "0.6.35",
"measured-core": "1.11.2",
"nodeify": "^1.0.1",
- "npm": "6.4.1",
+ "npm": "6.9.0",
"object.values": "^1.0.4",
"request": "2.88.0",
"resolve": "1.1.7", Install dependencies:
Verify the output of npm audit (showing only the parts reletive to
|
Looks like there is this PR on npm that will bump node-gyp to >= 4.x (which deps on safer tar): npm/cli#198 Can etherpad-lite just force resolution of tar to a safe version until npm cli is more better? That's what this repo did: https://github.com/vaadin/magi-cli/pull/95/files#diff-b9cfc7f2cdf78a7f4b91a753d10865a2R36 UPDATE: err.. package.json 'resolutions' is a yarn thing, but there is an npm lib you can use to use it. https://stackoverflow.com/questions/52416312/npm-equivalent-of-yarn-resolutions npm hasn't had a PR merged for 3 months so might be worth something like that to remove the hard dependency on that team. https://github.com/npm/cli/tree/release-next |
Wow. Thanks @gobengo, nice sum up. I did a quick check (install only) using npm-force-resolutions, and But this is so ugly I am still doubtful:
At least, thanks to your analysis, we now know that we are at the mercy of the npm team, and this is insane. |
I agree it's not ideal. Ideally everyone upstream would fix all the things right away. But by that logic I wouldn't be typing this. :)
True. But we also can't know it's functionally correct even if npm team fixes something. Just because the npm repo gets code in it, that doesn't mean it's functionally correct. The only way to know if something is (our opinion of) 'functionally correct' is to test the functionality. Is there a smoke test in etherpad-lite already we can use to verify our dep on npm? If not, what could that test consist of?
I noticed this when trying to dig in. I actually couldn't
Sure. There can always be new vulnerabilities in dependencies. But that's not a unique critique to this particular way of resolving some of them. If we never run More constructively, it seems like you have an implicit policy that all What I would do: Either
This is indeed tricky. Thanks for doing what you can! |
An updated version of |
…e repo. This change reverts c4918ef, and basically negates what was done for #3396, but aligns better with current practices in the nodejs ecosystem. Pragmatically speaking, this will allow users, if they want, to use npm-force-resolutions (https://github.com/rogeriochaves/npm-force-resolutions) to manually fix security vulnerabilities. We had a problem for that (see #3598), and - given the fragmented nature of the nodejs ecosystem - it is reasonable to expect more issues like that one, so it's better to be prepared. Closes #3659.
npm audit
reports a bad vulnerability intar
< 4.2.2. It has been reported since April 5th.Etherpad-lite isn't using tar directly though. The dependency chain is
npm > npm-lifecycle > node-gyp > tar
.So we need to wait for the chain to publish new versions with the dependencies fixed:
(This issue is just for tracking the progress of updates in the dependencies chain.)
The text was updated successfully, but these errors were encountered: