Kommende Breaking Changes bei der Kompatibilität in npm v12

 (github.blog)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • In npm v12 werden die sicherheitsrelevanten Standardwerte von npm install von automatischer Ausführung/Auflösung auf ein Modell mit expliziter Erlaubnis umgestellt; eine Vorabprüfung ist über Warnungen ab npm 11.16.0 möglich
  • Der Standardwert von allowScripts wird auf deaktiviert gesetzt, wodurch preinstall-, install- und postinstall-Skripte nicht ausdrücklich erlaubter Abhängigkeiten sowie implizite node-gyp rebuild-Ausführungen und prepare-Skripte von Git-, File- und Link-Abhängigkeiten blockiert werden
  • Mit npm approve-scripts --allow-scripts-pending lassen sich die Pakete prüfen, die blockiert werden würden; mit npm approve-scripts und npm deny-scripts werden Erlauben und Blockieren festgelegt, danach sollte die erzeugte Allowlist in package.json committed werden
  • Der Standardwert von --allow-git wird auf none geändert, wodurch die Auflösung direkter und transitiver Git-Abhängigkeiten gestoppt wird, sofern sie nicht ausdrücklich mit --allow-git erlaubt wurden
  • Es wird ein Code-Ausführungspfad blockiert, über den .npmrc von Git-Abhängigkeiten trotz Verwendung von --ignore-scripts das Git-Executable überschreiben konnte
  • Der Standardwert von --allow-remote wird auf none geändert, wodurch die Auflösung von Abhängigkeiten über Remote-URLs wie HTTPS-Tarballs gestoppt wird, sofern sie nicht ausdrücklich mit --allow-remote erlaubt wurden
  • Die Standardwerte von --allow-file und --allow-directory bleiben in npm v12 unverändert
  • Zur Vorbereitung sollte auf npm 11.16.0 oder höher aktualisiert, anschließend eine normale Installation ausgeführt und die Warnungen geprüft werden; nur vertrauenswürdige Pakete sollten freigegeben werden, und nach dem Upgrade werden nur noch genehmigte Skripte weiter ausgeführt
  • Zugehörige Dokumentation: npm approve-scripts, npm deny-scripts, allow-scripts config

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
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?