npm installのデフォルト動作が セキュリティ重視 に変わり、これまで自動実行されていた機能は今後 ユーザーが明示的に許可した場合のみ（opt-in） 動作するようになるallowScriptsのデフォルト値は off — インストールする外部パッケージに含まれるpreinstall・install・postinstallスクリプトはデフォルトでブロックされ、プロジェクトで許可したパッケージだけが実行される- パッケージをインストールするだけで自動実行されていたスクリプトを止め、悪意あるコードが入り込む余地を減らすための変更
node-gypのネイティブビルドもブロック対象となるため、binding.gypだけがあり別途 install スクリプトを持たないパッケージでもビルドが止まる（npm が内部的にnode-gyp rebuildを実行するため）- git・file・link で取得するパッケージの
prepareスクリプトも同様にブロックされる - 使い方:
npm approve-scripts --allow-scripts-pendingでどのパッケージがスクリプトを持っているか確認 →npm approve-scriptsで信頼するものだけを許可し、残りはnpm deny-scriptsでブロック → 許可リストはpackage.jsonに保存されるためコミットする
--allow-gitのデフォルト値はnone— Git リポジトリから直接取得するパッケージ（そのパッケージがさらに引き込むものも含む）はデフォルトでブロックされ、--allow-gitで許可しないとインストールできない- Git パッケージ内の
.npmrcによって Git 実行ファイル自体を差し替えられていた経路を塞ぐもの（--ignore-scriptsを使っても突破されていた問題）(npm 11.10.0+)
- Git パッケージ内の
--allow-remoteのデフォルト値はnone— https tarball のようなリモート URL から取得するパッケージ（推移的依存を含む）はデフォルトでブロックされ、--allow-remoteで許可しないとインストールできない (npm 11.15.0+)- ただし、
--allow-file・--allow-directoryについては今回の v12 でデフォルト値は変更されない
- ただし、
- 上記の変更はすべて npm 11.16.0 以降でまず警告として提供 され、正式リリース前に事前点検と対応が可能
- v12 のリリース予定時期は 2026年7月
1件のコメント
Hacker Newsのコメント
npmがGitHubに買収されたことをどうして見落としていたのかわからないが、急にいろいろ腑に落ち始めた
Nodeエコシステムのこれほど重要な一部が収まる場所として、これよりひどい家はなかなか思い浮かばない
https://github.blog/news-insights/company-news/npm-is-joinin...
「取り込み、拡張し、消滅させる」だ
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
postinstall スクリプトはずっと前に廃止されているべきだったし、NPMパッケージのがんのような存在だ
何かを取得すると、深くネストされた制御不能な postinstall が無作為に実行されることがあまりに多い
いったい誰がどの時点でこれを良いアイデアだと思ったのかわからない
たいていの場合、パッケージ化された依存コードはどうせどこかの時点で実行するし、普通はインストール工程と同じ権限で実行する
なら、こうした設定スクリプトは良くも悪くも、エントリーポイントを npm から
importやrequireが起きる場所へ移すだけだエコシステム全体がDenoのようなサンドボックス環境へ移行しない限り、せいぜい小さなつまずきにしか見えない。それが計画なのかもしれないが
すぐ思いつく例として https://www.npmjs.com/package/patch-package がある
今のヒステリーがこういう無意味な決定につながらないことを願う
この件は10年前に公になって以来、NPM内部で何百回も議論されてきたはずだ
Shai Halud のせいで、もう無視するには大きくなりすぎた
「そのうち直します」は、ほぼ常に「くそっ、もう直さなきゃ」になる
現在のLTS版Node、記憶が正しければ22、24、26について、このセキュリティ修正の恩恵を受けられるようバンドルされた npm を v12 に上げる予定なのか気になる
今はどれも npm v11 を含んでいる
v18.19.0[1] と v20.10.0[2] で npm 9 から 10 へ上げた
[1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
[2]: https://nodejs.org/en/blog/release/v20.10.0
記事にある通り、適切な既定値を設定すれば終わりだ
この変更のいちばん良い点は、既定値が変わることで、新しい開発者がただ install を実行しただけでこうした設定が有効だと勝手に期待する厄介なパッケージが即座に壊れるのを目にすることだ
たとえば、スクリプトが実行可能であることを前提にする慣行をやめさせられるかもしれない
記事だけでは明確ではないが、スクリプトの許可リストはグローバル設定ではなくパッケージごとの許可をサポートしているようだ
特定パッケージにだけスクリプトを許可する組織単位のルールを維持しやすくなりそうだ
こういう形でパッケージマネージャー設定の危険な既定値を防ぐのに使えるリンターがあるのか気になる
grepで十分では？まだYarnを使う理由があるのか気になる
Yarnもサプライチェーン攻撃を防ぐ保護機構を実装しているのだろうか
これまでは pnpm しか知らなかったが、npm も追随したのは良いことだ
最新のYarnリリースである 4.x は過剰なくらい決定的な動作を保証していて、チーム全体で一貫した動作を期待できる
機能面では小さなディテールが多く、慣れてくると積み重なって大きな違いになる
次のメジャーリリースでも、より良い性能と、その性能向上に依存してこれまで実装できなかった機能で同じ方向をさらに押し進める予定だ
参考までに、私はYarnのリードメンテナーだ
サプライチェーン保護機能もある
結局我慢できず pnpm に移行し、CI とローカル開発マシンの両方でインストールがずっと速くなった
LLM の助けを借りて、移行には1日ほどかかった
node_modulesに展開せず圧縮アーカイブから直接実行する方式だhttps://yarnpkg.com/features/pnp
Javaで
.classファイルのディレクトリツリーではなく.jarを使うのとかなり似ているただし少しハッキーで、エディタやツールの対応はまちまちだ
小さなファイルの数が大幅に減るので、やむを得ず Windows で作業しなければならないなら特に速いかもしれない
アーカイブを git リポジトリに入れることもできるので、インターネットやパッケージレジストリへの依存をなくせる
本当に答えを知らない
npm が GitHub の所有だとは知らなかった
それでいろいろ説明がつく
時間が経ってから読むと興味深いものもある
最上位コメントは「Microsoft が何でもうまくやるわけではないが、GitHub 買収は正直予想よりずっとうまく進んだ。GitHub に Microsoft 中心の方針を押し付けるのではなく、Microsoft のほうが製品面で GitHub のやり方を多く取り入れた。GitHub は今でも別会社のように運営されている」という内容だった
ベンチャー投資は受けていたが、持続可能な事業モデルを見つけられなかった
GitHub がエコシステムを救うために買収し、この買収が GitHub に大きな利益をもたらしたわけでもほとんどない
そして Microsoft は GitHub を Azure に移した
package.jsonの許可リストはパッケージのバージョンまで固定するのか、それともパッケージ名だけを固定するのか気になるallowScriptsの既定値が無効なのは良いことだ[時計を見る] 18か月遅れで pnpm を追いかけている感じか？
JavaScript 側ではこれは何のためなんだ？