またもサプライチェーン攻撃発生！crates.ioはエコシステムのあり方を再考すべき時ではないか

まあ理屈はわかるけど、これってワークフローの刷新にかかる資本とか、監査の運用コストに関係してる話かな？あと、Linuxディストリビューションごとのパッケージマネージャーはどうやってそういう作業をこなしてるんだろう？予算がもっと大きいのかな（Linuxディストロがどう経済を回してるのかよく知らないんだけど）。Rustを使ってる大企業がこういう動きに関心を持つことはあると思う？

予算がもっと大きいのかな（Linuxディストロがどう経済を回してるのかよく知らないんだけど）。

Debianには開発者とメンテナー合わせて約1,200人のアクティブな貢献者がいるんだよ。
ちなみにcratesチームは6人だ。

気合でコード書く「バイブコーディング」を極めれば、その数字なんて実質同じようなもんよ！（皮肉）

「バイブコーディング」で突き進むなら、そもそもセキュリティなんて気にしてないだろ。

待って、お前らセキュリティなんてあったの？ #ミーム#

気合いを入れてコードを書けば、自分で自分をサプライチェーン攻撃することだってできるぞ！いや、待てよ...

まさにOPが求めてたツールって感じだね。
しかもMozilla製とは、いいじゃん！

これが脇道に逸れたワークフローのままだと、Debian stableみたいに広く普及することはないだろうね。だから穴もたくさん残る。あと、最後のリリースが2024年って…これってもう機能完結してるってこと？

脇道に逸れてるとは思わないよ。僕が知る限り、Googleみたいなところが依存関係を検証するのに使ってるはずだし。

あと、それが機能完結とみなされているとしても驚きはないね。

crates.ioでの最後のリリースは4ヶ月前だよ。

ありがとう、GitHubのリリースしか見てなかった。

私の理解が合ってるか確認させて：

cargo-vetの認識だと、依存関係が受け入れられるようになるのは基本的に2通りだよね。信頼できる誰かが監査したか、自分で監査したかのどちらか。つまり、このシステムは「自分が信頼できる監査ソースの数」と「その人たちのレビュー能力」がボトルネックになるってことだよね。ってことは、マイナーなライブラリ群が網羅されることは一生ないんじゃないかな。

何か見落としてる点はある？

公平に言わせてもらうと、それは解決策とは呼べないけど、何もしないよりはマシだよね。

もう少し冷静に議論しよう。

今回の件が特に大きな影響を与えなかったのは事実。
crates.ioのチームが現状、こうした問題に十分対処するリソースを持っていないのも事実。

でも、今の状況がいつ大事故になってもおかしくない綱渡り状態であることもまた事実なんだ。

完璧な解決策があるわけじゃないけど、この問題を矮小化するのはやめようぜ。

そうとも言えるし、そうでもない。レジストリにはセキュリティのための仕組みが色々とあるし、外部企業が公開レジストリをスキャンしまくってるから、何でもないようなcrateを使って『様子見』をしてることが多いんだ。何が網をくぐり抜けて、何が引っかかるのかをテストしてるのさ。攻撃者は何が通過できるのかを把握したら、次は有名だったりダウンロード数の多いcrateに対して同じ手口を仕掛けてくるってわけ。

これは表面積の問題なんだよね。パッケージの一つが人気のあるリポジトリに紛れ込んだ瞬間、すぐに大きな問題になり得る。しかも、それが意図的じゃない場合もある。悪意のある人間が、実際に重要なバグを修正するPRを送ってきて、ついでに例のパッケージを紛れ込ませたら？ そしてレビューで見過ごされたら？ 全然あり得ない話じゃないよ。

Rustをプロダクションで使う機会が増えるほど、C言語に対してネットで言われるほどの劇的な改善があるとは思えなくなってきた。C++と比較しても、言語仕様が肥大化し続けている現状ではトントンか、それ以下かもしれない。先行言語が抱えていたエコシステムの課題は、Rustでもそのまま続いているしね。結局のところ、依存関係が深すぎて全容を把握するのが非常に困難という問題が解決されていない。Cargoで解決しているわけではなく、せいぜい隠蔽しているだけで、ある意味その方が厄介だ。ビルドシステムの拡張をRustで書くのがCMakeより進化しているとも思わないしね。Spackのように、まともな依存関係ソルバーを実装したエコシステムツールの方がよっぽど役に立つ。今なら自分の全プロジェクトで、完全に管理されたエコシステムを簡単に構築できるし。プロジェクトの各バージョンから要件を切り離せるから、新しいパッケージがリリースされた時の破壊的変更にも対応できる。Rustだと、コード自体に問題がなくても依存関係側の変更でビルド不可になるケースがあるし、リリースソースにロックファイルが含まれていないと本当に詰む。

あと、AIによる粗悪なコンテンツが蔓延しているのも痛いね。技術の世界が、何をしているのか分かっていない人たちが吐き出したゴミで溢れかえっているよ。

[削除されました]

笑った。君と一緒に低評価を食らいに来たよ。誰かがより良いエンジニアリングのために踏ん張らなきゃいけないからな。

その髪色、最高だ！自分はハゲちまったから、髪でおしゃれを楽しめる人たちを羨ましく思いながら生きていくよ :)

Rustという言語は、メモリ安全性だけじゃなく、CやC++と比べても圧倒的に優れているよ。

確かにエコシステムには欠点もある。でも、世の中で最も忌み嫌われているビルドシステムと言ってもいいCMakeよりは、Cargoの方が100倍マシだ。それに、ソースからのビルドを嫌ってディストリビューションのパッケージマネージャーに頼りたくないという意見があったとしても、結局今のモダンな言語は全部この方式に落ち着いているわけで、そっちの方が圧倒的に楽だからだよ。問題がないとは言わないけど、それらはRust特有の悩みってわけじゃない。

このモデルを採用している他のエコシステムに対する愚痴は消しちゃったけど、Cargoだけじゃないのはその通り。でも、『みんなやってるから』っていうのはレミングの論理だし、説得力があるとは思えないな。CMakeが一番恐れられてるのは、単に一番使われているからだよ。同じようにCargoのbuild.rsもひどいものだと思うけど、今のところは苦しみの種になるようなものが少ないだけ。CMakeはCargoがやることの半分しか担ってないし、YAMLを使うSpack（こっちにも問題はあるけど）や、Pythonを採用したConan（これはまあ、選択肢の一つとして）みたいなものもある。ビルドシステムってのは基本的にどれもクソだよ。誰も関わりたくないけど、誰もが抱える問題を解決しなきゃいけないんだから。ビルドシステムをよく扱う身としては、一番恐ろしいのはBazelだね。Mesonは基本CMakeと変わらないけど、Pythonへの依存があるのが個人的に好きじゃない。CMakeはソースからビルドすれば非常にシンプルなツールチェーンで済むし、依存関係のほとんどをベンダーとして取り込める。Boost buildやAuto toolsを挙げれば、CMakeが夢のように思えるよ。うまく書かれたCMakeとCargoはほとんど同じで、ターゲット、ターゲットタイプ、依存関係の記述になる。CMakeは他にもインストールの場所やCpackの構成も聞くけど、すべてが常に静的とは限らないからね。それ以外はツールチェーンの指定が全てだよ。Cargoは楽で、基本的にシンプルなオプションがあるソースが一つだけ。CMakeは10種類以上の言語の奇妙な仕様や、複数のコンパイラなんかを扱わなきゃいけない。でも、そのほとんどは別ファイルのツールチェーンで完全にカスタマイズできる。本当に例外的な場合を除いて、CMakeでif文や関数を多用する必要なんて滅多にないよ。まあ、例外的な場合にはbuild.rsが必要になるのと同じようなものさ。

いや、CMakeが現状こうなってるのはC++のエコシステムに慣習がないからだよ。慣習がない以上、ユーザーが調整しなきゃいけない設定項目を山ほど用意するしかないんだ。他のビルドツールを使ったとしても結局同じ問題にぶち当たるよ。どのエコシステムも、かろうじて耐えられるレベルのツールしか持ってないってことじゃないかな。

言語が広く使われるようになった後にビルドシステムを作る場合は特にそうだよね。Rustの開始当初からCargoが利用できたというのは非常に大きなアドバンテージだよ。RustプロジェクトをビルドするのにみんながCargoを使っているわけだから。

CMakeの設定項目はほとんどコマンドラインかツールチェーンファイルで操作すべきだ、というのが私の主張なんだ。Cargoも同じことをやっているけど、依存関係に対してかなり独善的な見方をしているから隠蔽されているだけだよ。そうじゃない場合は build.rs に醜いコードを書かなきゃいけない。だから実際には「優れている」わけじゃなくて、ほとんどのRustプロジェクトがCargoと付き合うためのコストを払っているに過ぎないんだ。

要するに、Cargoは問題を「解決」しているわけじゃなくて、ほとんどのプロジェクトから悩みの種を隠しているだけなんだ。Cargoという象牙の塔の外で作業したい人にとっては、結局同じ苦しみをすべて引き受けなきゃいけないんだよ。

ビルドツールの本質的な複雑さはどれも大差ないよ。Cargoが使いやすくてシンプルなのは、強力な規約に基づいているからだね。依存関係はcargoから、バイナリはsrc/main.rs、ライブラリはsrc/lib.rsにある、といった具合に。そういう規約がないと、cmakeみたいに何千もの細かい設定を指示しなきゃいけなくなる…まあ、Rustのコンパイラはプロジェクト内のファイルを自動検知できるからcmakeよりはマシだけどね。CやC++のコンパイラにはそれができないから。

とはいえ、規約の範囲外に出ると途端に厳しくなるのは確か。まあ、それが規約の存在意義でもあるんだけどね。

実際、RustにはCargo以外のビルドツールを使うユーザーにとって厄介な点が一つある。CargoはRustプロジェクトをビルドするための公式レイヤーであって、それより下の階層（コンパイラのCLIとか）は実装詳細とみなされているんだ。だから、いつでも仕様が変わる可能性がある！実際にはそんなこと滅多にないけどね。

っていうか、RustのstdlibはCのstdlibより大きいし、Cargoは単に依存関係を扱いやすくしただけだよ。Cで依存関係が少なく見えるのは、(a)動的リンクのせいで依存関係が見えなくなっている場合があるのと、(b)依存関係を追加するのがあまりに面倒すぎて、自分で書くかコードをコピーした方がマシっていう理由が大きい。「ツールを使いにくくする」のが解決策とは思えないな、たとえ実際には多少の効果があったとしても。Cargoは単調な作業を減らしているだけで、根本的な問題に悪影響を与えてるわけじゃない。

Cargo.lockファイルをコミットしないのは開発上の悪手だし、それに対する解決策はすでにある。

AI生成のゴミについては同意。中身をチェックせずに、危ない依存関係を紛れ込ませたAI生成のPRが混ざるリスクは相当なものだし、いつ大きな事件が起きてもおかしくない。

a)は半分正解だけど、SpackやNix、あるいはRustのエコシステムを上から制御するようなパッケージマネージャーが何とかしてくれるはず。b)についてはa)の解決策を見てみて。あと経験上、Rustの非OSSコンポーネントを扱うのもめちゃくちゃ大変だよ。

君の言う通りだね。特に本格的な開発において、標準ライブラリが充実しているのは時間短縮にもなるし、本当に助かる。ソフトウェアの選択肢や自由度が高いのは良いことだけど、ソースコードと作者が信頼できて、車輪の再発明をしなくて済むという安心感の中で構築できるのはやっぱり最高だよ。

stdに詰め込んだからといって、魔法のようにそれを検証するためのリソースが増えるわけじゃないからね。

年齢制限（age cutoff）の設定はいつ安定版（stable）で使えるようになるの？

さあね :)

特定の機能にしっかりした期限が設けられることはまずないから、「6週間から8週間で」って言いたくなるね^1。

RFCは承認されたから、進捗を追いたいなら Tracking Issue をフォローしておくといいよ。Cargoの主要なコントリビューターの一人がすでに対応を引き受けていて、すでに作業用のブランチもあるみたいだし。

今すぐその機能を使いたいなら、cargo-cooldown っていうCargoプラグインで使えるらしいよ。

^1 Jeff Atwoodへの敬意を込めて。

これセキュリティに関連する部分だから、チームとして優先度上げて対応したほうがいいと思う。プロセスがどうなってるかは全くわかんないけどね。

優先順位を上げるべきという点には同意するけど、チームは主にボランティアで運営されているんだ。だから、優先順位を上げる唯一の方法は、誰かが自ら進捗のために働きかけることしかないね。

もしやる気があるなら、プロジェクトは歓迎するはずだよ。ヒントが必要なら rust-lang Zulip や cargo contributor's guide をチェックしてみて。さらに、Issueを見た感じだと ehuss や waihanglo にコンタクトを取ってみて、どう協力できるか聞いてみるのがいいかも。

もっと早く進捗させる別の方法は、企業（または自分自身）に開発者を雇ってもらって、フルタイムでその問題に取り組んでもらうことだね（資金調達ページ を参照してみて）。

確認してみるよ、ありがとう。

もしそうしたいなら、プロジェクトは助けを歓迎するよ

それ、自分でも試した？僕の経験だと、rustcやclippyへのコントリビュートは簡単だったけど、cargoへのコントリビュートは不可能に近かったよ。

Cargoに最小待ち時間を実装したとしても、みんな揃って14日に設定するだけだよ。コミュニティが変更をチェックする時間を確保するため、なんて言いながらね。結局14日間は誰も中身を確認しないし、審査なんて行われない。問題が解決されたんじゃなくて、先送りにされただけ。しかも発見までの猶予期間が14日増えるだけさ。この解決策はただのチキンゲームで、問題を他人に押し付けて誰かが何とかしてくれるのを待ってるだけだね。

僕が挙げた2つのポイントに対して、そんなに丁寧な返信をくれて嬉しいよ（皮肉だけどね）。

念のため、提案を全体的な文脈で理解してもらえるように伝えておくと、Cargoにはすでに評価目的でバージョンを公開するための慣習があるんだ。

リリース候補を公開するなら、Cargo.tomlのバージョンにハイフンを使ってプレリリース識別子を追加すればいい。よくあるパターンはこんな感じ：[stackoverflow]
• 0.1.1-rc.0 (リリース候補0)
• 0.1.1-rc.1 (リリース候補1)
• 0.1.1-beta.0 (ベータリリース)
• 0.1.1-alpha.1 (アルファリリース)

プレリリースバージョンはCargoによって自動的にインストールされることはない。ユーザーがCargo.tomlで明示的にその識別子を指定してオプトインする必要があるんだ。

これによって、ユーザーが誤って不安定なバージョンを取り込むことを防ぎつつ、テストしたい人にはテストできる環境を提供できる。安定版リリースの準備ができたら、-rc サフィックスなしでバージョン 0.1.1 を公開すれば、それがユーザーに届くデフォルトのバージョンになる。

だから、セキュリティ上の懸念がある場合にプレリリース版を公開することを妨げる理由は何もない。その後、有志の魔法のようなツールでバグが見つかれば、同じコミットハッシュを使ってリリース版を公開すればいいわけだ。

既存の慣習を利用もせずに、中途半端で練り込みの足りない解決策を持ち出しても、エコシステムに遅延と不確実性を増やすだけだよ。問題を先送りにして、誰かが解決してくれるのを待ちながら時間を無駄にするようなものだからね。

ポイントは新しいコードに潜む潜在的なバグを避けることじゃなくて、意図的に悪意を持った更新を押し付けてくる乗っ取られたクレートを回避することだよ。
攻撃者が悪意のあるアップデートを公開するとして、わざわざプレリリースバージョンなんて使わないでしょ。

そうやってセキュリティベンダーがスキャンする時間を作って、マルウェアを検知したという実績で名声を稼ごうとしてるだけじゃないの。

この機能が入るとこれらのベンダーへのキャッシュフローが減るから、面倒なことになるかもね。

最初の対策として、最小経過時間の構成設定がCargoに導入されつつあるね。公開からX時間や日数が経過していないクレートは使わないように設定できるやつ。

クレートの公開者が任意でアップデートの「理由」を設定できるようにして、そのメタデータをcrates.ioで配布してくれると嬉しいかも。だって、もし新しいバージョンがセキュリティ修正のためのものなら、設定した最小期間とか関係なくすぐに調査したいからね。

「理由」なんてものがあっても、悪意のある連中には何の意味もないよ。

だからこそ、その場でアップデートするんじゃなくて「精査」するべきだって言ったんだよ。Cargoの最小時間を設定するくらい用心深いなら、悪意のあるやつがフラグを立てたタイミングでアップデートして、その用心深さを自ら台無しにするようなことは避けるべきでしょ。

今回のケースならcargo auditを使ってみたらどうかな？

うまくいけば、依存関係にセキュリティアップデートがあって「アップグレードすべきだ」って教えてくれるよ。cargo auditに自動修正させるか、手動で対応して設定済みのx日間の遅延を上書きすることもできる。

もちろん、これらはメンテナ本人や他の誰かがcargo auditにセキュリティ上の問題や修正を報告してくれることが前提だけどね。

君が提案してたやり方と手間は変わらないと思うけど、修正内容と「理由」を一緒に通知できる分、こっちのほうがスマートだと思うよ。

cargo-cooldownの試みは、Cargo本体 で実装が進められているよ。

https://www.reddit.com/r/rust/comments/1tmfteq/another_supply_chain_attack_and_cratesio_needs_to/onmi0ew/

それらは初心者の試みかもしれないし、もっと巧妙な攻撃者が『何が網にかかって、何がそのまま通り抜けるのか』を確認するための偵察かもしれない。結局、僕たちが知ることができるのは、運悪く（あるいは運良く）網に引っかかったものだけなんだから。

それと、AIが依存関係だとハルシネーションを起こしそうなパッケージ名を登録しようとする試みかもしれないね。

これはテストなんだよ。最初は無害な『攻撃』で偵察して、警戒心を解かせようとするんだ。（君もやられたわけだね）。その後で、もっと巧妙で成功率の高い本番の攻撃がやってくるのさ。

目的はトップレベルの依存関係にこっそり紛れ込ませることじゃない。何か役に立つライブラリに追加して、依存関係の依存関係として潜り込ませるほうが近いかな。

Underhanded C code contestと（短命に終わった）Underhanded Rust code contestを紹介したいんだけど、これを見ればいかにして疑われないようにマルウェアを忍び込ませるか、さらには悪意がないかのように見せかけてバグとして紛れ込ませるのが可能かってことがよくわかるはず。

https://www.underhanded-c.org/

https://web.archive.org/web/20180316095107/http://blog.community.rs/underhanded/2017/09/27/underhanded-results.html

だから、特定の攻撃がダメだったとしても、他の攻撃手法は非常に巧妙になり得るってことだよ。

こういう攻撃の狙いは、まさに「バイブコーダー（雰囲気だけでコードを書く人）」たちをターゲットにすることなんだよ。プロジェクトでAIエージェントに依存関係を何でもかんでも使わせながら、それがなぜ必要なのか、どうやって検証すべきかといった知識を一切持っていないような人たちね。結局、一番狩りやすいところを狙ってるってわけ。

権限の高いレビュアーアカウントが乗っ取られたとして、どうしてそれが気づかれないなんてことがあり得るの？信頼されたレビュアーなら、自分が標的になりやすいことを理解していて、それに応じて脅威モデルもアップデートしているはずでしょ。

まあ仮に、すごく優秀な攻撃者が信頼されたレビュアーを気づかれないように乗っ取ったとして、さらにレビュー済みのパッケージまで気づかれないように改ざんできたとしよう。それって今と全く同じ状況じゃん！むしろ今のほうが、信頼できるレビュアーすら存在しない分、乗っ取られたパッケージがスルーされる可能性が確実に高いんだよ（誰もレビューを仕事にしてないんだから）。だから今の状況のほうが、信頼されたレビュアーを置く場合よりも実際に「悪い」と言えるんじゃない？

追記：みんなの警戒心が薄れて、結果的に乗っ取られたパッケージがスルーされやすくなるリスクはあるかもしれないね。もしかしたら。でも現実問題として、コミュニティがやってるパッケージの精査って、専門家チームが仕事としてやるレベルに達してるのかな？

自動的に調査を実行できるような、分散型の信頼の輪（web-of-trust）システムを構築して検証を行うというのは、大きな前進だね。

真の「レビュー」っていうのは、レビューを投稿するための何らかのプロセス、例えばレビュアー本人やその雇用主を認証するような仕組みが必要なんじゃないかな。

それはまさに「cargo vet」がやっていることだね。

各企業が独自のプライベートレジストリを持つべきだと言ってるのか、それとも誰かが立ち上がって、検証済みパッケージの「プライベート」レジストリを作り、企業にアクセス権を販売すべきだと言ってるのかよく分からないけど、もし後者なら君に同意するよ。