Apply npm hardening + npm audit fix - #27614
Conversation
| # to detect and report malicious releases. | ||
| # To override for an urgent update: npm install <pkg> --min-release-age=0 | ||
| min-release-age=7 | ||
|
|
| "check": "prettier --check src/*.mjs tools/*.mjs --ignore-path src/pthread_esm_startup.mjs" | ||
| }, | ||
| "allowScripts": { | ||
| "esbuild": false |
There was a problem hiding this comment.
Does this disallow esbuild? Is that not covered by the strict-allow-scripts=true blanket prohibition?
There was a problem hiding this comment.
It fixes a warning that we're relying on the default.
npm warn install-scripts 1 package has install scripts not yet covered by allowScripts:
npm warn install-scripts esbuild@0.27.2 (postinstall: node install.js)
|
From the CI failures it looks like emsdk is not shipping npm new enough? |
CI error for reference: When I installed the latest emsdk (6.0.8), it pulled in node 24.19 + npm 11.19. The logs from my machine: |
|
Oh I see whats happening. The CI windows machine end up using I'm not sure what the best solution here ... the idea is that emsdk users can have their own version node in their PATH but emscripten internally will always use the emsdk node. I think mabye we could have bootstrap.py use the emsdk version node rather than one in the PATH... |
|
The node version requirement was my biggest concern. I'm not opposed to nudging people to update EOL releases, but I'm also not handling frontline tickets on this update breaking their build. Node 21 from the CI was last updated 2 years ago and is EOL (source: https://nodejs.org/en/about/previous-releases ). I'd assume that a lot of people use the bundled emsdk when building a project with emscripten. As far as bootstrap.py, I'm slightly less familiar with all of the code paths, but I don't know if we're going to run into version mismatch trouble with something like this from tools/link.py: |
|
boostrap fix is in #27617 |
When `EMSDK_NODE` is present in the environment, prepend its directory to `PATH` before running bootstrap actions. By default, emsdk avoids prepending its own node binary to `PATH` if a system node is already present in `PATH`. However, bootstrap actions (such as `npm ci`) may fail if the system node is an older incompatible version or lacks npm. See: emscripten-core#27614
|
Would you prefer that I merge that into my branch to test, or wait until that PR gets merged? |
|
The latter |
When `EMSDK_NODE` is present in the environment, prepend its directory to `PATH` before running bootstrap actions. By default, emsdk avoids prepending its own node binary to `PATH` if a system node is already present in `PATH`. However, bootstrap actions (such as `npm ci`) may fail if the system node is an older incompatible version or lacks npm. See: emscripten-core#27614
When `EMSDK_NODE` is present in the environment, prepend its directory to `PATH` before running bootstrap actions. By default, emsdk avoids prepending its own node binary to `PATH` if a system node is already present in `PATH`. However, bootstrap actions (such as `npm ci`) may fail if the system node is an older incompatible version or lacks npm. See: #27614
3 participants
This locks down npm to only take packages that are over a week old and disables scripts, both of which are best practices against the recent Shai-Hulud tree of supply chain attacks.