npm v12 kündigt Änderungen an, die die Abwärtskompatibilität brechen

 (github.blog)
1 Punkte von GN⁺ 2026-06-11 | 1 Kommentare | Auf WhatsApp teilen
  • Das Standardverhalten von npm install wird auf sicherheitsorientiert umgestellt: Funktionen, die bisher automatisch ausgeführt wurden, funktionieren künftig nur noch, wenn der Nutzer sie explizit erlaubt (opt-in)
  • allowScripts standardmäßig deaktiviert — preinstall-, install- und postinstall-Skripte in installierten externen Paketen werden standardmäßig blockiert; ausgeführt werden nur noch Pakete, die im Projekt ausdrücklich erlaubt sind
    • Skripte, die bisher schon beim bloßen Installieren eines Pakets automatisch liefen, werden unterbunden, um die Angriffsfläche für eingeschleusten Schadcode zu verringern
    • Auch Native Builds mit node-gyp werden blockiert. Dadurch werden selbst Pakete nicht gebaut, die nur binding.gyp haben und kein eigenes Install-Skript besitzen, da npm intern node-gyp rebuild ausführt
    • Ebenso werden prepare-Skripte von Paketen blockiert, die per git, file oder link bezogen werden
    • Verwendung: Mit npm approve-scripts --allow-scripts-pending prüfen, welche Pakete Skripte enthalten → mit npm approve-scripts nur die vertrauenswürdigen erlauben, den Rest mit npm deny-scripts blockieren → die Allowlist wird in package.json gespeichert und sollte daher committet werden
  • --allow-git standardmäßig none — Pakete, die direkt aus Git-Repositories bezogen werden, einschließlich deren transitiver Abhängigkeiten, werden standardmäßig blockiert und nur mit --allow-git installiert
    • Dadurch wird ein Angriffsweg geschlossen, über den .npmrc in Git-Paketen das ausführbare Git-Programm selbst austauschen konnte (ein Problem, das auch mit --ignore-scripts umgangen werden konnte) (npm 11.10.0+)
  • --allow-remote standardmäßig none — Pakete, die über Remote-URLs wie HTTPS-Tarballs bezogen werden, einschließlich transitiver Abhängigkeiten, werden standardmäßig blockiert und nur mit --allow-remote installiert (npm 11.15.0+)
    • --allow-file und --allow-directory ändern in diesem v12 allerdings nicht ihren Standardwert
  • Alle diese Änderungen werden in npm 11.16.0 und neuer zunächst als Warnungen bereitgestellt, damit vor dem offiziellen Release geprüft und reagiert werden kann
  • Der voraussichtliche Veröffentlichungstermin von v12 ist Juli 2026

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-06-11
Hacker-News-Kommentare

  • Ich weiß nicht, wie ich übersehen konnte, dass npm von GitHub übernommen wurde, aber plötzlich ergibt vieles einen Sinn
    Für einen so wichtigen Teil des Node-Ökosystems fällt mir kaum ein schlimmeres Zuhause ein

  • postinstall-Skripte hätten schon vor langer Zeit abgeschafft werden sollen und sind ein Krebsgeschwür in NPM-Paketen
    Viel zu oft werden beim Holen von irgendetwas tief verschachtelte, unkontrollierte postinstall-Skripte zufällig ausgeführt
    Ich weiß nicht, wer das jemals für eine gute Idee gehalten hat

    • Ich glaube nicht, dass ich den Kern der Sorge um Post-Install-Skripte richtig verstehe
      In der Regel führt man den paketierten Abhängigkeitscode ohnehin irgendwann aus, meist mit denselben Rechten wie während der Installation
      Dann kann man diese Setup-Skripte, ob gut oder schlecht, einfach vom Einstiegspunkt npm dorthin verschieben, wo import oder require stattfindet
      Solange nicht das ganze Ökosystem in eine Sandbox-Umgebung wie Deno wechselt, wirkt das bestenfalls wie eine kleine Hürde. Vielleicht ist genau das der Plan
    • Das sollte man auf keinen Fall tun, und es gibt viele sinnvolle Anwendungsfälle
      Das erste Beispiel, das mir einfällt, ist https://www.npmjs.com/package/patch-package
      Hoffentlich führt die aktuelle Hysterie nicht zu solchen unsinnigen Entscheidungen

  • Das dürfte intern bei NPM hunderte Male diskutiert worden sein, seit das vor 10 Jahren öffentlich wurde
    Wegen Shai Halud ist es jetzt zu groß geworden, um es weiter zu ignorieren

    • Ich mag, dass die Geschichte von JavaScript im Grunde wie ein Konzentrat entwicklerartiger Denkweise wirkt
      „Das reparieren wir bald“ wird fast immer zu „Verdammt, jetzt müssen wir es reparieren“
    • Gut, als Nächstes ist Python dran

  • Ich frage mich, ob die aktuellen LTS-Versionen von Node, soweit ich mich erinnere 22, 24, 26, das mitgelieferte npm auf v12 anheben werden, damit sie von diesem Sicherheits-Fix profitieren
    Im Moment enthalten sie alle npm v11

    • Auch früher gab es schon Major-Upgrades von npm in mittleren Node-Releases
      In v18.19.0[1] und v20.10.0[2] wurde npm von 9 auf 10 angehoben
      [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
      [2]: https://nodejs.org/en/blog/release/v20.10.0
    • Man kann das wegen der geänderten Voreinstellung zwar als Änderung der Sicherheitslage sehen, aber den Sicherheits-Fix selbst kann schon jetzt jeder anwenden
      Wie im Artikel steht, muss man nur die passenden Defaults setzen
      Das Beste an dieser Änderung ist, dass mit den neuen Defaults sofort auffällt, welche nervigen Pakete kaputtgehen, wenn neue Entwickler einfach install ausführen und davon ausgehen, dass solche Einstellungen aktiv sind
      Das könnte dazu führen, dass man endlich von der Praxis wegkommt, vorauszusetzen, dass Skripte ausführbar sind

  • Aus dem Artikel geht das nicht ganz klar hervor, aber es scheint, dass die Skript-Allowlist nicht nur global konfigurierbar ist, sondern Freigaben pro Paket unterstützt
    Das dürfte es erleichtern, organisationsweite Regeln beizubehalten, die Skripte nur für bestimmte Pakete erlauben
    Ich frage mich, ob es einen Linter gibt, mit dem man in Package-Manager-Konfigurationen unsichere Defaults dieser Art verhindern kann

    • Reicht dafür nicht grep?

  • Ich frage mich, ob es noch einen Grund gibt, Yarn zu verwenden
    Ich weiß nicht, ob Yarn ebenfalls Schutzmechanismen gegen Supply-Chain-Angriffe implementiert hat
    Bisher kannte ich nur pnpm, daher ist es gut, dass npm nachzieht

    • Natürlich gibt es den
      Die aktuelle Yarn-Version 4.x garantiert in fast übertriebenem Maß deterministisches Verhalten, und man kann im ganzen Team konsistentes Verhalten erwarten
      Funktional gibt es viele kleine Details, und wenn man sich daran gewöhnt hat, summieren sie sich zu einem großen Unterschied
      Das nächste Major-Release soll denselben Weg weitergehen – mit besserer Performance und Funktionen, die bisher nicht möglich waren, weil sie von diesen Performance-Verbesserungen abhängen
      Zur Einordnung: Ich bin der leitende Maintainer von Yarn
    • Ich habe in einem Projekt gearbeitet, das von Anfang an bis v3 Yarn nutzte, extrem langsam, aber es funktioniert
      Schutzfunktionen für die Supply Chain gibt es auch
      Irgendwann konnte ich es nicht mehr ertragen und bin auf pnpm umgestiegen; sowohl in CI als auch auf lokalen Entwicklungsrechnern liefen die Installationen deutlich schneller
      Mit Hilfe eines LLM hat die Migration etwa einen Tag gedauert
    • Ein Unterscheidungsmerkmal ist eine wählbare Installationsstrategie, bei der Pakete nicht nach node_modules entpackt werden, sondern direkt aus komprimierten Archiven ausgeführt werden
      https://yarnpkg.com/features/pnp
      Das ist ziemlich ähnlich dazu, in Java .jar statt eines Verzeichnisbaums mit .class-Dateien zu verwenden
      Allerdings ist es etwas hacky, und die Unterstützung durch Editoren und Tools ist uneinheitlich
      Die Zahl kleiner Dateien ist viel geringer, daher kann es besonders schneller sein, wenn man gezwungenermaßen unter Windows arbeiten muss
      Man kann die Archive auch ins Git-Repository legen und so die Abhängigkeit vom Internet und von Paket-Registern beseitigen
    • Ich weiß nicht, was NPM macht, aber Yarn ist beim Installieren von Abhängigkeiten viel schneller als NPM
    • Wer meinen Kommentar runterwählt, kann die Frage auch einfach beantworten
      Ich weiß es wirklich nicht

  • Ich wusste nicht, dass npm GitHub gehört
    Das erklärt so einiges

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16. März 2020, 571 Kommentare, 1829 Punkte) - https://github.blog/news-insights/company-news/npm-is-joinin...
      Einiges davon liest sich im Rückblick interessant
      Der oberste Kommentar lautete: „Microsoft macht nicht alles richtig, aber die GitHub-Übernahme ist ehrlich gesagt viel besser gelaufen als erwartet. Statt GitHub Microsoft-zentrierte Richtlinien aufzuzwingen, hat Microsoft aus Produktsicht mehr Dinge von GitHub übernommen. GitHub arbeitet weiterhin wie ein separates Unternehmen.“
    • Die Firma NPM stand 2020 kurz vor dem Aus
      Sie hatte Venture Capital aufgenommen, aber kein tragfähiges Geschäftsmodell gefunden
      GitHub hat sie übernommen, um das Ökosystem zu retten, und diese Übernahme hat GitHub selbst kaum großen Nutzen gebracht
    • Die meisten wissen das, aber der eigentliche Grund, warum das so vieles erklärt, ist, dass GitHub Microsoft gehört
      Und Microsoft hat GitHub auf Azure umgezogen
    • Ich wusste, dass es GitHub gehört, aber es ist das erste Mal, dass ich Release Notes direkt im GitHub-Blog sehe statt im npm-Blog

  • Ich frage mich, ob die Allowlist in package.json auf Paketversionen festgenagelt ist oder nur auf Paketnamen

  • Schön zu sehen, dass allowScripts standardmäßig deaktiviert ist
    [blickt auf die Uhr] Das sind also nur 18 Monate, um pnpm zu folgen?

    • In Javas Maven gab es so etwas nie, und ich hatte auch nie das Gefühl, dass es nötig wäre
      Wofür genau ist das im JavaScript-Umfeld gedacht?