人気のある Rust (逆) シリアル化プロジェクトである Serde は、そのserde_deriveマクロをプリコンパイルされたバイナリとして出荷することを決定しました。
この動きは、開発者の間でかなりの反発を引き起こしており、これらのバイナリを公開しているメンテナーアカウントが侵害された場合、将来の法的および技術的な影響に加えて、サプライチェーン攻撃の可能性を懸念しています。
Rust パッケージ レジストリ crates.io によると、 serde はその存続期間中に1 億 9,600 万回以上ダウンロードされ、 serde_deriveマクロは 1 億 7,100 万回以上のダウンロードを記録しており、このプロジェクトが広く流通していることを証明しています。
Serde マクロはプリコンパイルされる: オプトアウトする方法はありません
約 3 週間前、アプリケーションで Serde プロジェクトを使用している Rust プログラマーは、何か奇妙なことに気づきました。
「私は Fedora Linux 用の serde のパッケージ化に取り組んでいますが、 serde_deriveの最近のバージョンにはプリコンパイルされたバイナリが同梱されていることに気付きました」と Fedora パッケージング委員会のメンバーである Fabio Valentini は書いています。
「これは私たちにとって問題です。なぜなら、私たちはいかなる状況でも（ファームウェアなどのごくわずかな例外を除いて）プリコンパイルされたバイナリを再配布できないからです。」
Serde は、Rust データ構造で一般的に使用されるシリアル化およびシリアル化解除フレームワークで、 Web サイトによると、これらの操作を「効率的かつ汎用的に」実行するように設計されています。
「Serde エコシステムは、それ自体をシリアル化および逆シリアル化する方法を知っているデータ構造と、他のものをシリアル化および逆シリアル化する方法を知っているデータ形式で構成されています」とプロジェクトの Web サイトには記載されています。一方、「 derive 」はそのマクロの 1 つです。
Valentini 氏はさらに、プロジェクトの管理者に、これらの新しいバイナリが「実際にどのように作成された」のか、また、プリコンパイルされたバージョンを使用するのではなく、バイナリを再作成することが可能かどうかを尋ねました。
Serde の主要メンテナである David Tolnay 氏は、当時、考えられる回避策を示して対応しました。しかし、だからといって誰もが満足しているわけではありません。
この決定がプロジェクトに最適ではなかった理由について開発者からコメントが殺到したことを受けて、Tolnay 氏は GitHub の問題をクローズする前にフィードバックを認めました。
プリコンパイルされたバイナリを出荷することに対する彼の正当な理由は、以下に全文再現されています。
「プリコンパイルされた実装は、 serde_deriveで公開されているマクロを使用するためにサポートされている唯一の方法です。
それに対応するために一部のビルド ツールで実装作業が必要な場合は、誰かが自由にその作業を行うか (私が使用し、大きく貢献しているツールである Buck と Bazel で行ったように)、独自のソース フォークを公開する必要があります。コードを別の名前で作成します。
これとは別に、セキュリティに関する上記の解説に関して、今後の最善の道は、これに関心がある人のいずれかが、ファーストクラスのプリコンパイルされたマクロに関する Cargo または crates.io RFC に投資して、自分に合ったアプローチを確立することです。環境設定; serde_derive は利用可能な場合にはそれを採用します。」
は出版前に追加の質問をトルネイに打診しました。
「最初は .NET の Moq、そして今はこれです。」
Rust開発者の中には、プリコンパイルされたバイナリをオプションのままにして、元の「serde_derive」クレートから分離することを要求する人もいれば、この動きを、物議を醸しているMoq .NETプロジェクトのコード変更が反発を引き起こしたことに喩える人もいます。
あるユーザーは、「プリコンパイル済みの serde_derive バージョンを別のクレートに移動し、デフォルトの serde_derive をソースからビルドすることを検討してください。そうすれば、プリコンパイルされたバイナリの利点を望むユーザーがオプトインして使用できるようになります。」とリクエストしました。
「またはその逆。あるいは、serde_derive にパッチを当てずにソースからビルドできるその他のソリューション。」
「クレートの一部としてバイナリを同梱することは、ビルド時間の短縮という利点は理解していますが、セキュリティ上の理由から、一部のライブラリ ユーザーにとっては実行可能な解決策ではありません。」
ユーザーは、この変更が「独自のライセンスによって事前にコンパイルされたバイナリを再配布することを法的に許可されていない」団体にどのような影響を与える可能性があるかを指摘し、特に政府規制の環境に言及した。
「…最初は .NET の Moq、そして今はこれです」と、オーストラリアを拠点とする開発者 Jordan Singh 氏はコメントの中で述べましたが、後に削除されました。
「カーゴ開発者に機能のサポートを強制するのであれば、これはひどい回避策です。少なくとも、再現可能なバイナリを提供してください。人気のあるクレート/ライブラリの開発者が、ばかげた決定で全員を人質に取るのにはうんざりしています。」
フィラデルフィアを拠点とするドナルド・スタッフト氏は、ソーシャルメディア上で「バイナリの発送」ビジネスに参入するリスクについて警告した。
Rust プログラマの Nathan West (Lucretiel名) は、メンテナ アカウントが侵害された場合に、プリコンパイルされたバイナリによってもたらされるサプライ チェーンのリスクを特に強調しました。
「これがまさに彼らのやり方ではないでしょうか？ serdeの仕組みに対する半ばもっともらしい変更として黙って出荷し、決定に対するすべての批判を断固として無視してください」とウェスト氏は書いた。
「これが*まさに*、このような動きに対して誰もが反射的に反対する理由です。」
「インターネットの信頼は完璧ではありません。私たちは、それが実際に GitHub に投稿しているものであるかどうか * 知りません。だからこそ、私たちは防御の層とプロキシを用意しています。リスクを冒す価値がないため、大ざっぱなクソは拒否されます」 。
技術者の Sanket Kanjalkar 氏は、オプトアウトの方法なしでバイナリを出荷する移行を「 一歩後退」と呼びました。
しかし、Lander と名乗るセキュリティ専門家は、 少し異なる見解を持っています。
「 serde_deriveがプリコンパイルされたバイナリを配布するという Rust のドラマは、ちょっと面白いです」と Lander 氏は書いています。
「一方で、人々の懸念は理解できます。一方で、誰が気にするでしょうか？どうせ、彼らが取り込むすべてのプロジェクトの proc マクロコードや build.rsコードを読んでいる人は誰もいません。オプトアウトするのは良い考えでしょう。」
マクロをプリコンパイルして提供するというプロジェクトの決定に同意するかどうかにかかわらず、ソース コードとソフトウェア バイナリをプロジェクトに組み込む前に定期的に検査することをお勧めします。
情報を提供してくれたMichael Kearnsに感謝します。
Comments