Manually execute `ng new` deps postinstall scripts

Aperta
#22,013 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
typescript
Ambito
cli, security

Direzione di ricerca

Inizia esaminando il flusso ng new che esegue automaticamente npm install e determina come vengono gestiti attualmente gli script postinstall. Il lavoro è completato quando viene disabilitata l’esecuzione automatica generale di postinstall, vengono richiamati solo i pacchetti noti richiesti e viene aggiunta una copertura per rilevare le dipendenze postinstall mancanti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
27k
Fork
11.8k
Merge medio
16h 35m
PR unite (30g)
176

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di angular/angular-cli

Tutte le issue di angular/angular-cli

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.