Manually execute `ng new` deps postinstall scripts

Open
#22,013 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
typescript
Domain
cli, security

Research direction

Start by examining the ng new flow that automatically runs npm install and determine how postinstall scripts are currently handled. Done means disabling the broad automatic postinstall execution, invoking only the required known packages, and adding coverage to detect missing postinstall dependencies.

Written by the indexing model from the issue text.

Description

area: @schematics/angular feature feature: insufficient votes severity6: security

🚀 Feature request

Command (mark with an x)
  • new
Description

Currently, ng new will automatically run npm install which (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 install and 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:

ng-new-app@0.0.0 -> package-a@^1.0.0 -> package-b@^1.0.0

And package-b gets a new postinstall step in v2.0.0. However, package-a may be able to manage the breakage without violating their own public API (or maybe doesn't notice the new postinstall step) and simply bumps to v1.0.1. This would immediately be pulled in to the next ng new command and fail. I think such a scenario would actually be a bad patch release for package-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.

Dominant language
TypeScript
Stars
27k
Forks
11.8k
Avg merge
16h 35m
Merged PRs (30d)
176

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from angular/angular-cli

All issues in angular/angular-cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.