Repository navigation
Manually execute ng new deps postinstall scripts聽#22013
Description
Activity
One other point to consider is that I think this would only help for the automatic
npm installinng new. Any subsequentnpm installexecutions would be just as vulnerable as normal (and are the vast majority of installs). We could generate a project withignore-scripts, which would mitigate this issue for followingnpm installruns, but we also want to have a hook to execute allowlisted, legitimatepostinstallusages (such as ESBuild). If the user is directly invokingnpm install, we have no means of directly invokingpostinstallfor legitimate packages. Also users could add new packages withpostinstallin the future which we can't know about in advance.Ideally there would be some kind of feature for allowlisting
postinstallpackages in NPM which Angular could use to curate our own set of transitive dependencies, but I'm not aware of such a feature. As it stands the impact of this change would be relatively low since it only applies tong new, not applications after the initial scaffolding.Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.
Find more details about Angular's feature request process in our documentation.
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
馃殌 Feature request
Command (mark with an
x)Description
Currently,
ng newwill automatically runnpm installwhich (if the user has not disabled it), automatically runs all postinstall scripts. This can be a vulnerability since any compromised package in the NPM dependency graph could add a postinstall step to install malware on developer machines.Describe the solution you'd like
We could reduce the attack surface by disabling postinstall on the automatic
npm installand then manually invoke the postinstall for a known set of required packages. Only 3 packages currently use postinstall steps, so limiting execution to just those would significantly reduce the attack surface for a potential supply chain attack.One possible concern is for dependencies which add a required postinstall step in the future. We can pretty easily add a test to make sure we aren't missing any postinstall steps from our transitive dependencies, though this inherently breaks abstraction somewhat. Adding a postinstall step is (somewhat debate-ably) a breaking change, so any package which adds one in the future should require a major version bump where we have an opportunity to allowlist it.
The one edge case I can think of is if we have:
And
package-bgets a new postinstall step inv2.0.0. However,package-amay be able to manage the breakage without violating their own public API (or maybe doesn't notice the new postinstall step) and simply bumps tov1.0.1. This would immediately be pulled in to the nextng newcommand and fail. I think such a scenario would actually be a bad patch release forpackage-a, since adding a required postinstall step is fundamentally a breaking change. We would rely on NPM package maintainers to make the right semver-compatible decisions for a somewhat nuanced case, but this is probably better than the alternative.