Left-pad

left-pad事件は、2016年3月22日（米国太平洋時間）に、JavaScriptのパッケージ管理システムであるnpmの公開レジストリから、left-padの作者によって同パッケージを含む多数のモジュールが削除され、世界中でソフトウェアのインストールやビルドに大規模な支障が生じた事件である^[1]。作者は、自身が公開していた別のパッケージ「kik」の名称を巡ってメッセージングアプリKikの運営会社と対立し、npmの運営会社がその名称をKik側へ移管したことに抗議して、全パッケージを削除した^[2]。文字列の左側を文字で埋める（パディングする）わずか十数行の小規模なプログラムであったが、BabelやAtomといった主要なツール群が間接的に依存していたため、広範囲に影響が波及した^[3]。npmの運営会社は作者の意向に反する異例の措置として削除された版を復元し^[4]、その後パッケージの削除を厳しく制限する新方針を導入した^[5]。この事件は、極めて単純な機能まで外部パッケージに頼る依存関係のあり方や、単一の中央レジストリに過度に依存するエコシステムの脆弱性を巡る議論を引き起こした^[3]。

背景

npmはNode.js環境などで利用されるJavaScriptパッケージの配布・管理システムであり、Node.jsの標準パッケージ管理ツールとして広く利用されていた。クライアント側の管理ツール自体はオープンソースである一方、中央公開レジストリは民間企業であるnpm, Inc.が一元的に運営していた^[2]。npmのエコシステムでは、あるパッケージが別のパッケージを利用し、さらにそれが別のパッケージを呼び出すという多層の依存関係が一般的であり、開発者が明示的に導入したモジュール以外にも、大きな間接的依存関係が背後に存在していた^[6]。

「left-pad」は、文字列の先頭（左側）に空白などの指定文字を補い、右詰めの一定長にする機能を提供するパッケージである^[4]。例えば、「369」をゼロ埋めで5桁にする際に「00369」とするような処理を行う^[7]。実装はわずか十数行のコードであったが^[8]、ザ・ヴァージの報道によると、2016年3月時点における過去1か月間のダウンロード数は約255万回に達していた^[9]。

当時Babelは、最新仕様であるES2015のコードを旧来のブラウザでも動作するES5形式にトランスパイルするために広く使われていた。このBabelが依存していたコード行番号付加パッケージ「line-numbers」が、left-padに依存していた^[9]。

事件の発端は、left-padの作者が公開していた別のパッケージ「kik」（開発プロジェクトのセットアップ支援ツール）を巡る名称問題であった。同名のメッセージングアプリであるKikを運営するKik Interactiveは、自社の公式パッケージを同一名称で公開することを望み^[2]、2016年3月11日に作者へパッケージの改名を求めた。作者がこれを拒否すると、Kik側の代理人は登録商標を根拠とする法的措置の可能性を示唆した^[6]。双方の協議が決裂したためnpm, Inc.が介入し、3月18日、レジストリ上の「kik」という登録名の管理権をKik側へ移管する決定を下した^[6]。npm側は、ユーザーがその名称からメッセージングアプリ関連のパッケージを期待すると判断したとし、自社の紛争解決ポリシーに基づく決定であって商標権に関する法的な裁定ではないと説明した^[1]。

npm側の説明によれば、管理権の移管後も過去のバージョンはレジストリに残り、既存の利用者は引き続き取得可能とされ、新管理者は別のバージョン番号で自社パッケージを公開する運用が想定されていた^[1]。しかし、この決定に強く反発した作者はnpmに対し、自身が公開している全パッケージおよびアカウントの削除を要求した。作者がArs Technicaの取材で語ったところによれば、その後npm側から一括削除用コマンドが案内されたという^[2]。

パッケージの削除と復旧

2016年3月22日、作者は抗議としてleft-padを含む自身が所有する273個のパッケージをnpmレジストリから公開取り下げ（unpublish）した^[5]。BabelやAtomなどの著名プロジェクトは、line-numbersを通じてleft-padに間接依存していたため、依存関係の解決に失敗してインストールやビルドが停止する事態となった^[3]。Reactなど他の主要ライブラリも間接的な依存関係から影響を受け、名称移管を求めたKik社内でもビルドが通らなくなる障害が生じた^[6]。パッケージの取得を試みたユーザー側には、レジストリ上にモジュールが存在しないことを示すHTTP 404エラーが返された^[9]。なお、削除されたのはあくまでnpmレジストリ上の公開パッケージであり、ソースコード自体はGitHub上で引き続き閲覧可能な状態にあった^[2]。npmの発表によれば、同日14時30分（太平洋時間）以降、依存プロジェクトで毎分数百件のビルド失敗が観測された^[1]。

削除から10分以内には、事態に気付いた別の開発者が同等機能を持つleft-padのバージョン1.0.0を公開した。しかし、line-numbersがバージョン0.0.3を厳密に要求（ピン留め）していたため、新規バージョンの公開だけでは依存関係エラーを解消できなかった^[1]。この間、Babelの開発陣はline-numbersへの依存を取り除く修正版を急遽リリースして対処した^[9]。

事態の深刻化を受け、npm, Inc.は通常は認めていない「削除済みパッケージの同一バージョンでの再公開」という例外措置を講じ、公式主導でleft-padのバージョン0.0.3をレジストリ上に復元した^[4]。同日16時5分に復元方針を公表し、バックアップからの復旧作業は16時55分に完了した。一連の障害は約2時間半に及んだ^[1]。

また、left-pad以外に削除された272個のパッケージについても、コミュニティによって派生版が登録されたほか、悪意ある第三者が同じ名称で別のパッケージを公開することを防ぐための仮パッケージが配置された^[1]。ザ・ヴァージも、npm側が悪意あるコードの混入を防ぐため、削除されたパッケージ名の確保措置を取ったと報じている^[9]。

対応と反応

npm, Inc.は2016年3月29日、パッケージ公開取り下げに関する規約を改定し、自由な削除を大幅に制限する新方針を発表した。新方針では、公開から24時間未満であれば作者自身による削除を認める一方、同一の名称およびバージョン番号での再公開は一律禁止された。公開から24時間を経過したパッケージの削除には運営への事前申請が必須となり、他に依存しているプロジェクトが存在してエコシステムを損なうと判断された場合は削除が却下され、保守権限の移譲や依存側の修正が促される仕組みとなった。また、全バージョンが削除されたパッケージ名には運営側が保護用のプレースホルダーを配置し、再利用には個別審査を要することとされた^[10]。

作者は削除後のブログ記事において、npmが個人開発者よりも大企業の意向を優先したと感じたことが抗議の動機であったと説明した^[6]。利用者コミュニティに混乱を招いたことには陳謝したものの^[2]、The Registerのインタビューでは「長期的に見ればコミュニティはこの教訓から恩恵を受けるはずだ」と述べ、自身の行動への後悔はないとした^[5]。一方、Kikは作者との交渉ログを公開して企業側の正当性を主張しつつも^[9]、作者に接触した際の文面について謝罪した^[5]。npm側も、一開発者の独断による削除でエコシステム全体が機能不全に陥るリスクを防げなかった点について謝罪を表明した^[10]。

npmの最高技術責任者は、復元は被害の深刻さと広がりを踏まえた前例のない措置であり、軽々しく行ったものではないと説明したうえで、「この措置はnpm利用者のコミュニティ全体の利益を一人の作者の意向と対立させるものであり、我々は多数の必要を選んだ」と述べた^[6]。またnpm側は、作者のコードを「盗んだ」とする批判に対し、left-padはオープンソースのコードであり、他者による再公開を明示的に認めていると反論した^[1]。

議論と影響

本事件は、極めて単純な機能まで外部のマイクロパッケージに依存するモダンな開発手法の是非と、特定の一元管理型レジストリにソフトウェア資産を集中させるリスクについて、開発者の間で議論を巻き起こした^[3]。The Registerは分析記事で、既存コードの再利用には時間の節約や新たなバグの混入防止といった利点があると認めつつも、多くのプロジェクトの安定性が多数の極小パッケージに不必要に依存していると指摘した^[5]。

Ars Technicaは、依存しているコードが予告なく取り下げられ得ることに多くの開発者が不満を抱いていると伝え、npmのGitHub上に「npmを信頼すべきか」と題した投稿が寄せられるなど、運営への信頼が揺らいでいる様子を報じた^[2]。InfoQの報道によれば、作者の行動には賛意を示す声がある一方で無責任だとする声もあったほか、単一のリポジトリに集中して依存することの安全性が問われ、分散型のモジュール配信システムの提案も一部でなされた^[3]。

2017年に発表された小規模パッケージ（trivial package）に関する学術研究は、本事件が、容易に実装できる些細な処理のために外部依存を導入することの問題への関心を高めたと述べている。同論文が開発者88名を対象に行った調査では、小規模パッケージを利用する理由として、よく実装・テストされたコードであることや生産性の向上が挙げられた一方、欠点としては依存関係の増加に伴う負担と、パッケージの消失などによるアプリケーションの破損が最も多く挙げられた^[11]。

また、2022年のTechCrunchの記事は、開発者が政治的主張や抗議を目的として自作ソフトウェアを破壊・改変する「プロテストウェア」（protestware、抗議を意味する protest とソフトウェアの ware を組み合わせた造語）が同年に相次いだことを報じる中で本事件を取り上げ、当時は孤立した抗議に見えた行為が2022年になって再び現れたとして、近年の事例と比較される先行例に位置付けた^[12]。

脚注

関連項目

• peacenotwar

外部リンク

• left-pad - GitHub