npm v12で予定されている互換性を壊す変更
(github.blog)- npm v12では、
npm installのセキュリティ関連のデフォルト設定が自動実行・自動解決から明示的な許可方式に変わり、npm 11.16.0以降では警告によって事前に確認可能 allowScriptsのデフォルト値が無効に変わり、明示的に許可していない依存関係のpreinstall、install、postinstallスクリプトと、暗黙的なnode-gyp rebuild、git・file・link 依存関係のprepareスクリプトの実行をブロックnpm approve-scripts --allow-scripts-pendingでブロック対象となるパッケージを確認し、npm approve-scriptsとnpm deny-scriptsで許可・拒否を決めたうえで、生成された allowlist をpackage.jsonにコミットする必要あり--allow-gitのデフォルト値がnoneに変わり、--allow-gitで明示的に許可していない直接・推移的 Git 依存関係の解決を停止- Git 依存関係の
.npmrcが、--ignore-scripts使用中であっても Git 実行ファイルを上書きできてしまうコード実行経路を遮断 --allow-remoteのデフォルト値がnoneに変わり、--allow-remoteで明示的に許可していない https tarball などのリモート URL 依存関係の解決を停止--allow-fileと--allow-directoryのデフォルト値は npm v12 で変更なし- 準備手順としては、npm 11.16.0以降へアップグレードした後に通常のインストールを実行して警告を確認し、信頼できるパッケージのみを承認し、アップグレード後は承認済みスクリプトだけが引き続き実行される形となる
- 関連ドキュメント:
npm approve-scripts,npm deny-scripts,allow-scriptsconfig
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 側ではこれは何のためなんだ？