ハクソク

世界を動かす技術を、日本語で。

NPMがクラシックトークンからの混乱した移行後に段階的な公開を実装予定

138日前原文(socket.dev)

概要

この機能は パッケージ名 や PURL で直接検索できる。 エコシステム名 や PURLタイプ にも対応。 npm や PyPI など、複数のエコシステムをサポート。 検索体験を 効率化 する入力方法を解説。 入力のクリアや 切り替え 方法も紹介。

パッケージ名・PURLによる検索機能

  • パッケージ名 または PURL（Package URL） を入力することで、目的のパッケージへ直接ジャンプ
  • 例: pkg:npm/react@18.0.0 または省略形 npm/react@18.0.0 で npm の react バージョン18.0.0を指定
  • PURL は、パッケージの所在やバージョンを一意に特定するための標準フォーマット

エコシステム・PURLタイプによる切り替え

  • エコシステム名 （例: pypi/, npm/, maven/ など）や PURLタイプ を入力することで、検索対象のエコシステムを切り替え
  • 例: pypi/ と入力すると PyPI エコシステムでの検索モードに変更
  • 切り替え後、スペースを入力することで入力フィールドがクリアされ、新たな検索クエリの入力が可能

効率的な検索体験のための操作方法

  • パッケージ名 や PURL を直接貼り付けて即座に検索・ジャンプが可能
  • エコシステムを指定してから検索することで、他のエコシステムと区別した精度の高い検索が実現
  • スペース入力で検索モードのリセット、再検索がスムーズに行える操作性

対応エコシステム例

  • npm （JavaScript/Node.jsパッケージ管理）
  • PyPI （Pythonパッケージ管理）
  • Maven （Javaパッケージ管理）
  • その他主要なパッケージエコシステム

まとめ

  • パッケージ名 や PURL を活用した迅速なパッケージ検索
  • エコシステム名 入力による検索対象の柔軟な切り替え
  • スペース入力 での入力クリア機能による操作性向上

Hackerたちの意見

現在の形では、信頼できる公開は限られたユースケースにしか適用されません。サポートは少数のCIプロバイダーに限定されていて、新しいパッケージの初回公開には使えず、公開時に必須の2FAなどの強制メカニズムもまだ提供されていません。これらの制約から、メンテナグループは信頼できる公開を普遍的なアップグレードとして扱うことに対して慎重になっています。特に影響の大きいパッケージや重要なパッケージについてはそうです。これは厳密には正確ではありません。PyPIのために信頼できる公開を設計したとき、OIDC IdP（通常はCIプロバイダー）全体に対して汎用的に設計しましたし、新しいプロジェクトを信頼できる公開を通じて作成するための配慮も明示的に含めました（これを「保留中」のパブリッシャーと呼びました）。後の信頼できる公開技術の採用者全員がこれを採用したわけではないのは、残念で理解できることだと思います（パッケージの存在に関するデータモデルや仮定が複雑になるため）。ここでの多くの問題は、GitHub側が自ら引き起こしていると思います。通常のAPI認証情報を完全に削除する決定は非常に攻撃的に感じますし、信頼できる公開の実装とは全く関係ありません。この二つを同じキャンペーンで結びつけることで、ユーザーや統合者にとって不必要に混乱を招いているようです。

└

npmエコシステムには詳しくないので、もしかしたら誤解しているかもしれませんが、ローカル公開（トークン経由）のサポートを削除して、信頼できる公開を使ったCI公開を優先したように聞こえます。それが正しいなら、信頼できる公開がRustに提案されたとき、ローカル公開を置き換えるものではなく、CI公開を強化するためのものだと議論されていたと思います。

└

「現状の形」はNPMの文脈で言うと正確だと思う。PyPiがもっと合理的な道を選んでるのを見るのはいいね。

└

実際には、大手だけが「信頼できる出版者」になれるって感じだね。> 「PyPIの限られたリソースを最大限に活用するために、私たちはPyPIユーザーの間で合理的な使用レベルを持つプラットフォームのみをサポートする予定です。また、サポートされるアイデンティティプロバイダーの運用において全体的な信頼性とセキュリティに高い基準を持っています。実際には、自家製や個人用のIdPは対象外となります。」みんなが「信頼される」ためにMicrosoft (TM) GitHub (R)を使ってアーティファクトを洗浄しなきゃいけなくなるのは、いつになるんだろうね？

└

ここでの多くの痛みは、GitHub側が自分で引き起こしていると思うよ。「Microsoft」って書いてあるのに、長期的に何が起こると思ってたの？その買収があったときのことを思い出すけど、周りでパーティーが開かれてたよね。MSがついにオープンソースを「理解した」って。あと、GitHubのコンテンツをAIに食わせることは気にしないの？

私は非常に多く使われているnpmパッケージをメンテナンスしていて、この状況には本当に神経を使っています。最近のリリースでは、数十のパッケージの中で、手動でpackage-lockやpackage.jsonの変更を読み、すべての依存関係の変更を確認していました。幸い、私たちのコアライブラリには外部依存関係がありませんが、ツールにはたくさんあります。信頼できるパブリッシャーに移行するか、数人のチームメンバーに2FAでローカルに公開させるか、厳しい選択を迫られました。私たちは、何年もレビュー手順を伴う自動化プロセスを持っていたので、信頼できるパブリッシャーを選びましたが、ハッキングの可能性がまだあることは理解しています。だから、今はどのPRにも非常に慎重になっています。信頼できるパブリッシャーを有効にするのは、たくさんのパッケージがあって本当に大変でした。私たちが望んでいるのは、信頼できるパブリッシャーを使いながら、CIベースの公開設定を続けられることです。ただし、その際には人間による2FAのステップが必要です。でも、それは完全な解決策の一部に過ぎません。HITL（人間が介在するプロセス）は、悪意のあるコードの拡散を遅らせることしか保証されていません。実際には、妥協された依存関係からプロジェクトを守ることはできず、広めるのを防ぐこともできません。これらすべては、依然として人間の手に委ねられています。私たちは、依存関係をより良くロックダウンし、分析するためのツールや、公開前にパッケージを分析するためのツールが必要です。また、CIを実行する前にサードパーティのPRを分析し、サンドボックス化するためのより良いツールも欲しいです。今はHITLがあるけど、テストを実行する前に各PRを手動で調査しなければなりません。

ちょっと明確にしておくと、「信頼できる公開」とは逆のベンダーロックインの一種を意味しますか？それに使えるのは一部のCIシステムだけです。

└

はい。自分で設定することはできません。

└

「信頼できる公開」は、OIDCのための専門用語に過ぎません。NPMは、GitHub Actions以外のCI/CDプラットフォームとの連携をサポートすべきです。そうすることで、不正の印象を避けられます。（彼らがまずGHAをターゲットにするのは、ユーザーの大多数がそこにいるからだと思いますが。この技術自体は基本的にプラットフォームに依存せず、相互運用可能です。）

npmが単にCLIを同時に更新していれば、こんなに混乱はなかったでしょう。今でも2FAを使って公開することができないのは、彼らのCLIがそれに対応できないからです。

└

TOTP 2FAを使ったCLI公開は、壊れるまではうまくいってたんだけどね。

公開に2FAを要求したり、信頼できる公開を使うことで、この問題の大多数を防げるはずです。唯一の難しい点は、信頼できる公開を使用しているときに、自分のプルリクエストを承認できないようにすることです。それは2FAを要求することに戻るべきです。

└

CIを使っての公開が不可能になるから、頻繁にリリースするプロジェクトには問題だよね。自己ホストのCIを使ってる場合、信頼できる公開もその問題を解決しないし。

NPM自体が「postinstall」セクションにあるスクリプトをユーザーの許可なしに実行しちゃうのが大きな問題だと思う。これ、他のパッケージマネージャーでは解決済みの問題で、例えばPNPMはユーザーが許可した場合にのみスクリプトを実行して、許可リストをpackage.jsonファイルに保存するんだ。もし依存関係が「postinstall」スクリプトを追加しても、それは実行されないから、ユーザーが実行するべきかどうかを確認できて、攻撃面が大幅に減るんだよね。

└

これって、ターゲットにできるパッケージの数を減らすだけじゃない？例えば、私はpostinstallでHeadless Chromeをインストールする必要があるテストランナーを公開してる。みんな私を信頼して、そのパッケージを許可リストに入れてくれる。だけど、私のアカウントが侵害されて悪意のあるアップデートが公開されたら、みんなが確認もせずに悪意のあるコードを実行しちゃう。今のNPMよりはマシだとは思うけど、まだまだ問題があるよね。

└

「postinstall」に含まれるコンパイルステップを排除するだけで解決できるセキュリティ問題がたくさんある。もっと安全でデバッグしやすく、拡張性のあるライブラリが欲しいなら、純粋なjsで公開すべきだよ（例えばTypescriptじゃなくて）。そうすれば、postinstallの攻撃面がなくなるから。

こういうことを忘れがちだけど、NPMパッケージはほとんどボランティアによって維持されてるんだよね。もし障害を設けたり、余計な仕事を押し付けるなら、報酬を払うべきだよ。オープンソースライセンスには「自己責任で使用すること」って明記されてるし。ほとんどのメンテナは、何をするか指示されずに作れることが大きなモチベーションなんだ。去年、NPMで2500万回ダウンロードされたけど、大きなライブラリに比べたら大したことない。でも、実際に人々が私の作品を使ってくれてるんだ。これに対して、私は正確に$0を受け取ったよ（もしSpotifyやYouTubeのストリームだったら、現実的には約$100,000を見込めたかも）。私は二つのNPMを提案するよ。100%自己責任の非商業的NPMと、著者やメンテナが守るために報酬を受け取る商業的NPM。

└

ここは同意だな。管理側が「何かしなきゃ！」って言って、これを選んだ感じだよね。無料で提供してる開発者に負担を押し付けるのはおかしいと思う。負担は、無料でそのものを使う開発者や企業にあるべきなのに。

└

今日これが導入されたら、強制的に個人情報を晒さなきゃいけなくなるのが嫌だな。

└

NPMは、ホビイストが自分の情熱を探求するためのフレンドリーな場所でいるか、IT業界の重要な基盤になるかを決めなきゃいけない。誰かがNPMにマルウェアをアップロードしたり、いじったりすると、みんなが文句を言ってNPMを責める。NPMがマルウェアのアップロードを防ごうとすると、また文句を言ってNPMを責める。NPMを分割しても状況は変わらないと思う。今のNPMはすでに「100%自己責任」のNPMで、それでも抗議用ソフトがビルドを壊すと文句を言う人がいる。

└

そうそう！オープンソースやフリーソフトウェアの文化が、ただのタダ働きに変わってしまうのが大嫌いだ。初期の頃は、ランダムなオタクたちが助け合って楽しんでたから文化が成り立ってたけど、今はタダ乗りする連中がそれを乗っ取って、自分たちを押し込んでる。彼らは、ソフトウェアにお金を求める開発者を恥じさせることで、文化を武器化してる。多くの企業は、あれこれに毎月何千ドルも使ってるのに、彼らの製品が依存してる重要なライブラリのために一度きりの100ドルのライセンス料を取るのは大変だ。個人的には、「タダで提供して、寄付を乞う」文化は終わってほしい。提供される商業的価値に基づいたバランスを確立する必要がある。例えば、ライセンスはユーザーの規模に基づいて決めたい（非商業ユーザー、小規模商業ユーザー、中小企業、大企業）。数百万ドルの企業がランダムな開発者からタダで利益を得るのはおかしい。

└

障害を設けて余計な仕事を押し付けるなら、私たちに報酬を支払うべきだよ。そうじゃなければ、ボランティアが余分な作業をタダでやらないから、ライブラリが減ることを受け入れるしかない。すでにライブラリが多すぎると言えるから、エコシステムの規模が縮小するのは、逆にプラスかもしれないね。

└

それよりももうちょっと複雑だよ。Node周りのエコシステムはちょっと変だし、NPMがどんな役割を果たしたいのかもはっきりしない。多くの人がNPMのダウンロード数を追いかけてるけど、それが彼らのバリデーションだったり、YouTubeの登録者数やGitHubのスター数みたいなもんなんだよね。そうやって仕事のオファーをもらうんだ。少なくとも彼らはそう思ってるけど、実際にそれが機能してるかは分からない。良いソフトウェアはたくさんあるけど、シグナル対ノイズ比はまだまだ低い。だから、君のソフトウェアを依存関係として含めることでお金をもらいたいな。そうすれば、君のダウンロード数も長期的に増えるし。もちろん、冗談だけどね。でも、実際にそんなことが起こっても全然驚かないよ。結局、GitHubのスターも他のSNSと同じように買えるからね。それが社会的なダイナミクスに変な影響を与えるんだ。

これはレジストリレベルの問題にするべきじゃないと思う。つまり、出版 ワークフローに摩擦を持ち込むんじゃなくて、簡単に解決できる サブスクリプション ワークフローに持ち込むべきだよ。デフォルトで自動更新（ワイルドカードパッチやマイナーバージョン）をサポートしないようにすればいいんだ。インストール時に読み込んだバージョンをインストールするのがデフォルトの挙動にすればいい（npm ciみたいにね）。

└

いや、出版側では助けが必要だよ。私が知っているほとんどの場所はデフォルトで更新してないし、すべてにロックファイルがある。でも、数ヶ月前のnx攻撃は、nxのVS Code拡張が常に@latestバージョンを実行して更新をチェックしてたから起こったんだ。だから、そういうワークフローはいつも愚かだったり、ロックファイルを使う簡単な方法がなかったりするんだよね。だから、npmにももっとセキュリティを強化してほしいな。私の知る限り、npm installでロックファイルを使うのはデフォルトの動作だし、頼まない限りランダムに更新されないはずなんだけど…依存関係を固定するのがベストプラクティスなのは確かだよ。

2FAでの公開がまだうまくいかない。もうレガシートークンを使うことにしたよ。何が悪いのか考えるのは諦めた。

メンテナが報酬をもらえないってコメント、すごく共感する。俺はソロ創業者なんだけど、これらのセキュリティ変更は必要だけど、出荷に本当に摩擦を加えるんだよね。皮肉なのは、信頼できる公開がみんなをGitHub Actionsに押しやることで、リスクを集中させてしまうこと。もしGHAが侵害されたら、その影響範囲はすごく広い。一方で、2FAを使ってローカルマシンから公開するソロ開発者は、むしろ安全だと思う（攻撃面が小さいし、人間が介在してるから）。でも自動化に押しやられてる。俺が見たいのは、信頼できる公開が機能するけど、実際に公開が通る前に2FAの確認が必要な中間地点。自動化も人間のゲートも両方維持するって感じ。記事にあった段階的公開のアプローチはいいステップだね。少なくとも、悪意のあるコードがみんなのnode_modulesに届く前にキャッチできるから。