-
Notifications
You must be signed in to change notification settings - Fork 479
Fix npm vulnerabilities #8091
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
base: main
Are you sure you want to change the base?
Fix npm vulnerabilities #8091
Conversation
✅ Deploy Preview for kubernetes-sigs-kueue canceled.
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: pajakd The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
I see, so IIUC the scanner scans the dependencies which are put locally in the node_modules, and by this trick you avoid them being scanned. Is this correct, or more nuanced? Assuming this is correct the alternatives I see:
(2.) might be tedious on our side if we are not using KueueViz internally yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not add this package to the base package.json?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason is that it is imported with the -g flag -- so it should be available system-wide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The -g flag installs it globally, so you can use serve (or /usr/local/bin/serve) as a binary. But it doesn’t matter where you run it.
@mimowo To clarify -- there is no issue with any of the libraries. The thing is that each installed library must be present in the package.json and the package-lock.json So, what is flagged as insecure is any explicit |
|
I see, so rather than calling For example here https://github.com/kubernetes-sigs/kueue/pull/8091/files#diff-afa357502d22dc9bd50e3995c9034a3524903909ba97e5c28e7d86488c5459daL41 we could declare in the package.json cypress as a devDependency and then the |
cmd/kueueviz/frontend/Dockerfile
Outdated
| COPY ./node_packages/package-lock.json /usr/local/node_packages/ | ||
| WORKDIR /usr/local/node_packages/ | ||
| RUN npm install | ||
| ENV PATH="/usr/local/node_packages/node_modules/.bin:${PATH}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can add it on scripts and run it like npm run serve.
+1 Agree |
|
/test all |
| "preview": "vite preview", | ||
| "check-unused": "depcheck" | ||
| "check-unused": "depcheck", | ||
| "serve": "npm run serve" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably you also need to update start.sh.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or another alternative. You can copy binary from node_modules from previous stage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it working without start.sh changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The e2e tests are passing. But do they use the start.sh script? Probably not, so I have to test on the real cluster, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, please 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pajakd @mbobrovskyi it seems this is the last pending thing to do, is it clear what / how to test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mimowo yes, sorry for the delay. I'll test it tomorrow.
EDIT: or some time this week
cmd/kueueviz/frontend/package.json
Outdated
| "depcheck": "^1.4.7", | ||
| "vite": "^7.2.4" | ||
| "vite": "^7.2.4", | ||
| "serve": "^14.2.5" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Serve should be dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Actually, its already there so I claim that this npm install is unnecessary. |
|
sgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please sync this file with cmd/kueueviz/frontend/package.json.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
In our internal mirror of Kueue repository, any build time dependency installation (npm install ${dep}) is flagged as insecure -- there are two such lines in kueueviz frontend. This PR is an attempt to fix those.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?