Your reported issue is just about the fact that `npx` triggers lifecycle scripts, which is by design.
OP is about the fact that manifest contents of the same package version may differ between package contents and registry and looking at the registry is not sufficient to tell which lifecycle scripts will be triggered for a package.
The deeper issue however reflects the same problem regardless of different manifest contents - npm has no control over validation of scripts, or their execution.
The issue I repeated was just one vector of executing these script attacks, the attached PoC shows how easy it is to create a supply chain attack with npm (you focusing on the npx part is the red herring)
Npm have ignored it for years and now it's getting more common.
That postinstall and other scripts have been a problem for a long time - the PoC for example could be installed via npx, which would then run postinstall which executes another script to steal /etc/password data.
This is not a new problem, you just have another vector.
I came up with a free linter package to try solve it - but no one seemed interested, and here we are 7 later talking about where people are now offering paid services to mitigate it.
Nice tool, but I don't see how it would detect the issue described in the blog post, which is that the manifest uploaded to npm does not match the manifest inside the tarball. The package.json that's presented to npm is never actually downloaded into your node_modules.
The tool was for the toolchain work 7 years ago, maybe if it had continued I've have worked on a bunch of stuff around dependency checking (which I actually did write recently). Like I said I tried to speak up about it then and was shut down by several npm core people so I just moved on instead of spending the energy.
(Everyone seems so focused on the blog post and missing the fact since NPM was created you've been able to manipulate it's postinstall script to install malware - at any level, including npms failure to verify the manifest file)
Comments
I actually did a POC 7 years ago about this - https://github.com/tanepiper/steal-ur-stuff
It was reported to npm at the time, but they chose to ignore it - https://github.com/npm/npm/issues/17724
Your reported issue is just about the fact that `npx` triggers lifecycle scripts, which is by design.
OP is about the fact that manifest contents of the same package version may differ between package contents and registry and looking at the registry is not sufficient to tell which lifecycle scripts will be triggered for a package.
The deeper issue however reflects the same problem regardless of different manifest contents - npm has no control over validation of scripts, or their execution.
The issue I repeated was just one vector of executing these script attacks, the attached PoC shows how easy it is to create a supply chain attack with npm (you focusing on the npx part is the red herring)
Npm have ignored it for years and now it's getting more common.
Sorry if I'm misunderstanding, but how is this the same issue discussed in the article?
That postinstall and other scripts have been a problem for a long time - the PoC for example could be installed via npx, which would then run postinstall which executes another script to steal /etc/password data.
This is not a new problem, you just have another vector.
I came up with a free linter package to try solve it - but no one seemed interested, and here we are 7 later talking about where people are now offering paid services to mitigate it.
https://github.com/tanepiper/npm-lint
Nice tool, but I don't see how it would detect the issue described in the blog post, which is that the manifest uploaded to npm does not match the manifest inside the tarball. The package.json that's presented to npm is never actually downloaded into your node_modules.
The tool was for the toolchain work 7 years ago, maybe if it had continued I've have worked on a bunch of stuff around dependency checking (which I actually did write recently). Like I said I tried to speak up about it then and was shut down by several npm core people so I just moved on instead of spending the energy.
(Everyone seems so focused on the blog post and missing the fact since NPM was created you've been able to manipulate it's postinstall script to install malware - at any level, including npms failure to verify the manifest file)