Arch Linuxは現在、マルウェアインシデントが制御下にあると信じている：1,500以上のパッケージ

ユーザーにはインストールする前に必ずレビューすることが重要だって何度も警告されてる。 そのスタンスは再評価すべきだと思う。Arch Linuxの開発者たちは素晴らしい仕事をしていて、私は彼らに感謝してるから、彼らを批判するつもりは全くないよ。でも、ここに簡単な解決策は見当たらないけど、最近のサプライチェーン攻撃が増えてる中で「ユーザーに警告する」時代はもう終わった気がする。何か他のコントロールがあれば、少なくとも問題を軽減できるかもしれないね。もしかしたら、公開前にピアレビューや猶予期間を設けるといいかも？

ruaや他の似たようなCLIを使えば、AURからパッケージをインストールする前に簡単にレビューできるし、同じコンピュータで銀行取引をしてるなら、依存してるソフトウェアをレビューしない理由はないよ。 ユーザーはどんなレビューをすればいいの？場合によっては、npmを依存関係として追加してatomic-lockfileをインストールしたり、他の場合ではbunを追加してjs-digestをインストールしたりしてたみたい。これは主に低使用の孤立したパッケージに対する大規模な攻撃で、メンテナンスが引き継がれたり、別のユーザーが新しいバージョンをアップロードしたりする（それ自体が非常にシンプルで、目立たず、監視も少ないプロセス）。多くのパッケージはNode.jsとは全く関係がなかったから、各パッケージについて十分な知識があってnpmが何かを知っているユーザーなら、PKGBUILDの各行をレビューしてインストールスクリプトを確認すれば、その異常に気づくかもしれない。でも、Node.jsに関連する正当なAURパッケージもnpmを使ってるし、時にはnpm installも使うからね。ユーザーはArchlinuxのビルドシステムの違い（例えば、build()とインストールスクリプト）を理解するために十分な知識が必要だし、インストールするAURパッケージのPKGBUILDやインストールスクリプト、パッチをすべてレビューしなきゃいけない。実際にnpmやbunを使っているパッケージについては、正当な使い方とそうでない使い方を知るために十分な知識が必要で、妥協された依存関係についても最新の情報を持っている必要がある。しかも、これは特に隠されていない大規模な攻撃を考慮しているんだ。攻撃はもっと見つけにくくできるかもしれない。AURパッケージを安全にレビューするようユーザーに求めるのは、実際にはビルドプロセスや上流パッケージのプログラミング言語だけでなく、Archlinuxのビルドシステムのすべての詳細を完全に理解するよう求めているように思える。これをどうやって学ぶかは、私が見る限り、実質的なガイダンスがない状態でやらなきゃいけない。AUR自体やそのウィキのページは、ユーザーがPKGBUILDやインストールスクリプトを注意深くレビューするべきだと警告するだけで、何を探すべきか、どうレビューすればいいかについての具体的なガイダンスは全くない。警告は、助けようとする試みというよりも、むしろ責任回避のように感じる。そうなると、AURが実際に提供しているものは、上流パッケージをインストールすることと何が違うの？提案された「安全な」AURの使い方は、ユーザーにとって直接上流をインストールするのと同じくらいの労力や知識が必要な気がするし、パッケージを作ることすら同じくらいの労力がかかるかもしれない。ここにはLLM分析の余地があるかもしれないね：Opus 4.8、Kimi latest、そしてQwen3.6 27Bは、私のテストで現在の悪意のあるパッケージのラウンドをすぐにキャッチする。でも、やる気のある攻撃者はそれを難しくしたり、危険にしたりできる。ユーザーは、リスクを減らすために上流パッケージをインストールさせることもできるし、pacmanで管理したいなら、リスクを減らしながらパッケージを生成させることもできるかもしれない。

こんなに多くのパッケージに感染させるなんて、まだ驚きだよね。でも、AURがどう動いてるのか、正直よくわからない。誰でもアクセスできる人が何でも更新できるの？パッケージには、貢献をチェックするオーナーがいるわけじゃないの？

不変のシステムファイル、デフォルトでユーザー・ローカルにパッケージをインストールすること（管理者権限を必要としないようにする）、そしてコンポーネントやプログラムにできるだけ少ない権限を与えることの組み合わせは素晴らしい議論だと思う。これに関しては、不変のディストロ、Wayland、Flatpakにいくつかの要素があるけど、まだ目立つ穴が残ってる。最大の問題は、サンドボックスがパッケージフォーマットに結びついていることだと思う。サンドボックスとアクセス権限はシステムレベルでのことにすべきで、任意のバイナリが簡単に抜け道を通れないようにするべきだ。これだけでは問題を完全に解決するわけじゃないけど、影響範囲を大幅に制限して、ディストリビューションのユーザーをあまり魅力的なターゲットにしないようにできると思う。

"どうやってレビューするの？何かをインストールする前に、コードの一行一行を読むの？バイナリパッケージなら、どうやってそれをするの？インストールするものすべての再現可能なビルドを作るの？ソースディストロに移行するの？これをユーザーに押し付けるのは現実的じゃないよ。常識の余地はあるけど、ユーザーを責めるのは馬鹿げてる。

AURはArchのLinuxディストロとしての大きな利点としていつも高く評価されてたのを思い出すけど、残念ながらその便利さには代償も伴ってる。パッケージのメンテナになるのに必要なのは、孤児としてフラグを立てて、元のメンテナが休暇中で反応しないのを2週間待つだけで、バン！攻撃者がメンテナに割り当てられて、スパイシーなアップデートを出せるようになるなんて、狂ってるよ。

これは素晴らしいけど、結局実行不可能なアドバイスだね。最初は良さそうに聞こえるけど、よく見てみると馬鹿げてる。人間が一生のうちに読めるコードなんて、世の中にはもっとたくさんあるよ。君自身が今動いてるコンピュータのソースコードの1%も読んでないんじゃないかな。これって、コンピュータを使うのをやめたってこと？ 何が起こっても信頼できるの？

言うのは簡単だよね。こんなに人気のあるディストリビューションなのに、公式リポジトリじゃなくて非公式リポジトリ（AUR）にどれだけのものがあるかに驚いてる。

私にとって、このトレードオフは価値がないね。Linuxに切り替えたのは、Windowsユーザーみたいにウェブサイトに行って「ダウンロード」をクリックしてプログラムを更新するためじゃないから。君が言ってるpacmanラッパーは本当にクレイジーだね。

typoquatting まさに完璧なデモだね！