- rsync メンテナンスは、セキュリティ報告の急増と AI 活用をめぐる論争が重なり、テスト、コードカバレッジ、マルチプラットフォーム CI、セキュリティスキャン、多層防御が必要になった状況である
- 新しい Python テストスイートは既存のシェルスクリプト構造を置き換えるが、設計と検証計画はメンテナーが担い、Claude、Codex、Gemini は反復作業の補助に使われた形である
- 3.4.3 リリースはセキュリティ修正を優先した一方、既存テストや手動テストでは見つからなかった、一部の有効だが特殊なユースケースでリグレッションが発生したリリースだった
- pytest は他のプロジェクトで多用してきたが、rsync テストスイート固有の要件には合わず、別個のアプローチを設計した選択であり、LLM は慎重に使うべきだが有用なツールだという判断である
- 今後の方向は、リグレッションを緩和する 3.4.4 と、大きなセキュリティ変更を含む 3.5.0 の間で決定中であり、openrsync は新しいテストスイートで 98 件中 85 件に失敗している
セキュリティ報告の急増と防御強化
- rsync のメンテナーは最近のオープンソースパッケージ開発者たちと同じく、セキュリティ報告が殺到する状況を経験しており、その多くは AI 生成物だが、慎重で質の高い手動分析も一部存在する
- 報告の増加が深刻になるにつれ、rsync にはより徹底したテストスイート、コードカバレッジ分析、より多くのプラットフォームでの CI テスト、意図的なセキュリティ問題のスキャン、多層防御手法が必要な状態になっている
- メンテナーは引退しており、もっと航海をしたいが、必要な作業量のため複数の AI ツールを使っており、その選択を後悔していないという立場である
Python テストスイートと AI 支援作業
- 既存のシェルスクリプトベースの rsync テストスイートは Python に書き直され、コア設計と検証計画はメンテナー自身が直接担った構成である
- Claude は反復作業に使われ、Codex と Gemini はクロスチェックに使われたのであり、単に「テストスイートを Python に変換してくれ」と丸投げした形ではなかった
- メンテナーはすべての部分を自ら確認し、多くの CI 時間を費やして調整したうえで、CI 待ち時間を減らすため、その後は複数のローカル VM で大半のテストを実行する方式へ移行した
- コミット履歴の
co-authored by claude 表示は、ソフトウェアエンジニアリング作業全体の一部しか表していないという見解である
LLM 論争、pytest の選択、3.4.3 のリグレッション
- LLM は、その仕組みを知っているからといって無価値なツールになるわけではなく、慎重に使うべきだが、現在のソフトウェアエンジニアリングと IT セキュリティ保守の環境では有用だという立場である
- rsync 3.4.3 はセキュリティ問題の修正を優先する方向に意図的に寄せたリリースであり、その過程で有効ではあるが特殊な一部のユースケースが変更の影響を受けた状態である
- 影響を受けたユースケースは既存の rsync テストスイートと手動テストには含まれておらず、GitHub リポジトリの Issue と PR で報告されたリグレッションを順次処理中である
- pytest は他のプロジェクトで多く使ってきたが、rsync テストスイートで必要な作業の一部は pytest では非常に難しいと判断し、独自のテストアプローチを設計した選択である
次のリリースとセキュリティテスト拡大
- セキュリティ報告は引き続き届いており、現在複数の CVE 対応作業が進行中である
- システム開発能力とセキュリティ知識を持つ他の開発者たちも加わっており、その一部は最近の怒りがきっかけで目立つようになった人々である
- 次の選択肢は、一部のリグレッションを緩和する 3.4.4 と、はるかに大きな変更を含む 3.5.0 の間にあり、3.5 は rsync のセキュリティ基準を大きく引き上げるが、変化の規模が大きいリリースである
- 大きな変更セットを迅速に適用するには、rsync のようなソフトウェアに包括的なテストスイートが必要であり、新しいテストスイートの再作成はその必要性から生まれた作業である
- 3.5 リリースには、セキュリティ関連の問題を扱う追加テストが入る予定である
openrsync 比較とコードレビューの要請
- openrsync を特定プラットフォーム向けにパッケージ化しようという流れに対し、新しい rsync テストスイートを openrsync に適用してみてもよいのではないかという反応である
- 実行例は次のコマンドである
./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp
- openrsync は現在 98 件のテスト中 85 件に失敗しており、多くの失敗は openrsync に存在しない機能が原因だが、良い結果とは言えないという評価である
- 怒りをさらにぶつけるよりも、公開されたコードを実際にレビューし、建設的な批判を行うほうが望ましいという要請である
1件のコメント
Lobste.rs の意見
引用を見ると、筆者は航海をしたいと思っている一方で、プロジェクトのメンテナンスにプレッシャーを感じており、LLM を使えばその両方を実現できる解決策があると考えているように読める
引退して航海を楽しみ、そのためにバグを直さなくても構わないし、オープンソースプロジェクトのバグを直さなくても構わない。公開の場でその点を率直かつ透明に示せばよい。昔ながらの言い方をすれば「パッチ歓迎」で十分だ。特に、資金力のある企業がそのプロジェクトに依存しているならなおさらだ
より多くのメンテナーや開発者が、オープンソース保守に LLM の「助け」を使わなければならないというプレッシャーなしに、引退や航海を楽しめるといいと思う。それでも rsync プロジェクトで LLM を試したいなら、それは彼の選択だ。他の人たちが、私を含めて、同意しなくても同じことだ
理由が何であれ、オープンソース開発者を苦しめる人たちは、無料のオープンソースソフトウェアが製品ではなく贈り物だという点を忘れているように思える
外から見ているだけの人たちは、気に入らなければフォークすればいい。Andrew はそのプロジェクトで自分の望むやり方で作業できるし、私たちの論評や意見がどうしても必要というわけでもない
希望が持てる点は、長期的には rsync の保守を引き受ける別の人が現れるかもしれないことだ。Tridge は以前にも新しいメンテナーへ引き継いだことがある
OpenJS Foundation がいくつかのプロジェクトに資金や移行支援を提供し、単独メンテナー体制からチームメンテナンスへ移した事例についての発表を聞いて LWN に記事を書いたが、それは今日公開予定だ。rsync のようなプロジェクトには、こうした支援がもっとずっと必要だ
セキュリティ問題はプレッシャーが大きく、注目度も高く、しかもメンテナーが面白いと感じるプロジェクトの中核から外れていることが多い
メンテナンスには多くの責任が伴い、すべてが楽しいわけではないが、自由・オープンソースのメンテナーがそうしたことまで引き受けてくれるとありがたく感じる。実際にそうする人はあまり多くないように見える
LLM の助けなしでは特定の目標達成コストが高すぎると判断される場合があり、LLM の助けがあれば妥当なコストになることもある
前向きに捉えれば、健全なワークライフバランスを保とうとするオープンソースメンテナーが、LLM で作業量を減らしつつ、望む目標をより達成しやすくなったということだ
切り取って引用した部分は導入部の一部にすぎず、この記事は明らかに慎重でニュアンスを含んだ文脈で書かれており、基本的なオープンソース保守一般についての文章ではない
さらに奇妙なのは、引用文の直前の文脈を省いていることだ。報告が急増したことで rsync の防御ラインを大きく引き上げる必要があり、はるかに徹底したテストスイート、コードカバレッジ解析、より多くのプラットフォームでの CI テスト、セキュリティ問題の探索、防御の多層化手法の追加が必要になった、という話である
このケースでは筆者は引退しているが、他のオープンソースプロジェクトでは、仕事や別の用事を抱えている人たちが同様の業務増加にのみ込まれることもあり得る。正直、このコメントがここまで多く賛成票を集めているのは戸惑うし、善意で書かれたものには感じられない。少なくとも、タイトルだけ見て飛び込んできたコメントよりはわずかにましな程度の、誠意の感じられない反応に思える
嫌がらせを弁護したり容認したりするつもりはないが、この擁護には抜け落ちている理由がある
説明としては、筆者がバイブコーディング向けの設計を行い、生成されたコードをレビューし、コードとチャットボットに習熟していて、バイブコーディングを慎重に扱い、セキュリティと機能リグレッションの間でバランスを取ろうとした、というものだ。もっともらしく聞こえるが、実際にはリグレッションが発生しており、筆者はその理由にまで到達できていない
「AI ツールは単純作業が得意だから、そうした作業を任せた」と言っていたが、そうではない。チャットボットは実際にはコードを書くのが苦手だ。これが核心なのに、筆者はそのこと自体を認識していないように見える
最近になって本当に数字が増えているのか確認できるとよい。リグレッション自体は珍しいものではないし、人々が Andrew を攻撃する口実を探しているだけかもしれないとも思う
筆者は rsync 3.4.3 リリースで一部のユースケースにリグレッションがあったことを認め、そのリリースでは意図的にセキュリティ問題の修正により重点を置き、有効ではあるが特殊なユースケースの一部が変更の影響を受けたと説明している
それらのケースは既存の rsync テストスイートや自分で行った手動テストには含まれておらず、現在リグレッションに対処中であり、GitHub リポジトリに issue や PR として報告してくれた人たちに感謝しているとも述べている。自分のユースケースが影響を受けたなら謝罪し、セキュリティリスクを受け入れるのであれば以前のリリースを使ってもよいとも述べている
「ソフトウェアエンジニアリングの世界はここ数か月で劇的に変わった」「ITセキュリティと報告の殺到の中でソフトウェアを保守する世界はここ数週間で完全に変わった」という話をこの半年ほどずっと繰り返し聞かされていて、うんざりしている
この報告の殺到の原因がLLMなら、解決策としてLLMを持ち出すのは信じがたいほど間違った方向に感じる
それでも、いま人気のある何かを保守するのがひどい仕事になっているだろうという点はすぐに信じられる。もしかすると彼にとっては、限られた計算時間をさらに絞り出すより、ただ身を引いて本当の引退を楽しむのが最善なのかもしれない
人々が主張することの半分でも役に立つツールなら、その有用性は自然に示されるはずだと思う
ただし、Tridgellのような人の話には耳を傾ける価値がある。そしてセキュリティ報告の「洪水」は真剣に受け止めるべきだ。誰が、何が見つけたものであっても、セキュリティ問題はセキュリティ問題だ。だからこの記事は、普段目にするうんざりするような攻勢とは違って感じられる
結局はLLM依存が強まっていく下向きのスパイラルに入るかもしれない
それがなぜ間違った方向なのか？ 誰もLLMを持たないほうがよい、という意味なのか？
LLM補助開発が必ずしも「ゴミのような成果物」になる必要はない
この記事が書かれて共有されたことには感謝している。特に、3.4.4で一部のリグレッションを緩和するか、はるかに大きな変更を含む3.5.0へ進むかで悩んでいるという点が目を引いた
筆者が読んでいるなら、ここでは3.4.4が正しいアプローチに見える。前回のリリースにリグレッションがあった状況で、すぐ大規模な3.5.0に進めば、多くの人は無謀だと見るだろう。人々が違いをより理解しやすくなれば、懸念も和らぐ
新しいテストスイートの中核構造をmasterでまず公開作業しようとしたが、それが怒りを招いたのを見ると悪い考えだったかもしれない、という部分については、透明性を下げたからといって受け止め方や反応が良くなるとは思えない。せいぜい、より大きな反発を先送りするだけだ
openrsyncに新しいrsyncテストスイートを走らせろというのは公平ではない。samba rsyncはプロトコル32で、openrsyncはプロトコル27であり、機能完全性を掲げているわけでもないからだ
MediumとCloudflareとは、混ぜるべきではない最悪の組み合わせだ
https://archive.is/qbyVA
オープンソースのメンテナンスは感謝されにくい仕事だ。Tridgeはテストスイートの技術的負債を修正し、LLMが検出したCVEの洪水に責任ある形で対処しようとしたが、Hyrumの法則にぶつかったようだ。3.4.4計画がまだしもましな選択肢で、結局は押し進めるしかなさそうだ
この問題については両方に気持ちが揺れる。一方では、セキュリティは人が直接コードを書くときにのみ保証できるとも思う。
コードを書いている間はそのコードについて考え、早い段階で誤りを見つけられるからだ。私はコードをレビューするときより、自分で書くときのほうがずっと上手く書ける。レビュー中は自分がすべての行を慎重に考えていないので、多くのことがそのまま見過ごされる。
他方で、嫌がらせが許されないという基本的な事実は別として、Andrew には自分の自由時間に自分のプロジェクトを望むやり方で運営する権利がある。LLM を使いたいなら、私は賛成しないが、それは彼のプロジェクトであり彼の裁量だ。気に入らないなら、自分のバックアップを restic や borgbackup に移すか、rsync をフォークすべきだ。
はっきり言うと、私はバイブコーディング自体に反対しているわけではない。会社では半ば強制的に使わされているし、最近の自分の仕事の大半である退屈で新規性のないグルーコードを書くには、それなりに悪くない。ただ、自由時間には使わない。
rsyncはそれほど適した解決策でもない。ファイル内容が破損したときの復元には役立たないからだ。restic のようなツールのほうがずっと良く、ファイルの以前のバージョンも保持してこのようなケースに対応する。実際、削除も追跡するので、どのファイルがもはや関係ないかも分かる。
私にはアプリケーションセキュリティの経験があり、いくつかのエクスプロイトも見つけられるし、レビューで捕まえることもできる。だが、現在の上位 LLM が「もっと病的なケースを探せ」といった反復を回すほどには上手くない。
あれほど人気のあるソフトウェアでも、自分のコード、使ったライブラリ、代替実装の問題を、あまり苦労せずに見つけてきた。人間が使える時間と執念はまったく比較にならない。
組織全体には、問題を予防・検知・対応するためのセキュリティソフトウェアが広く導入されている。各領域には常に抜け穴があり、やるべきことがさらにある。組織は、完璧ではありえないと分かっていても、まったく改善がないよりはセキュリティ態勢の改善を受け入れることを選ぶかもしれない。LLM がもたらすトレードオフもその一部だ。
このトレードオフは文脈によって変わるが、「すべてのコードは手で書かなければならない」となることはまれだ。
それは rsync のようなサーバーにも当てはまる。作者の言うとおり、より堅牢で回復力のあるものにするための大きなリファクタリングが必要かもしれない。LLM で権限分離の方向にリファクタリングして、より小さい信頼ベースのコードを作れるなら、その範囲外のいくつかのバグは受け入れられるかもしれない。
rsync の具体的な文脈は分からないが、こうしたプロジェクトが通常持つ限られたリソースの中で、作者はプロジェクトとユーザーにとって最善の判断をしているのだろうと思う。
その代わり、rclone には並列性があるので、利用可能なネットワーク帯域をはるかに効果的に活用できる。
それによって起こりうる問題の上限が与えられる。
下限は、私が見つけるか、他の誰かが見つけるか、あるいは別の何か、たとえば LLM が見つけるバグや脆弱性だ。
人が自分で書いた C コード、たとえば rsync をレビューする状況は、この領域で良い位置にあるとは言いにくい。Andrew を非難する意図はまったくない。
航海をしたがっている引退したメンテナーには共感するが、その文脈が根本的に何かを変えるとは思わない。
Tridgell は私たちにどんな作業も負っていないし、引退して航海する自由がある。そうしたいならうまくいってほしい。責任感を持っている点には共感するが、行間を正しく読めているなら、それをある程度負担にも感じているようだ。
しかし rsync は基幹ソフトウェアであり、それをメンテナンスしようとする人は一定の品質基準を守るべきだと思う。メンテナーの仕事が基準に達していないなら、それはミスだ。だからといって嫌がらせを受ける理由にはならない。何かがミスだと言うことは、そのミスをした人が悪いとか、その人に共感していないという意味ではない。
だから問題は、AI コーディングツールが行った作業が基準に合っていたかどうかだ。どんな基準かと言えば、おおむね「この品質でも作業が行われたほうが、行われないよりましなのか」という基準だ。ソフトウェアを改善するなら続ければよいし、悪化させるならやめるべきだ。巧妙な定義だとは主張しないが、正しい定義だとは思う。
私たちには Tridgell に追加作業を要求する権利はないが、事実であるなら「これはユーザーにとって悪化させる」と言う余地はある。
正直、この作業をどう判断すべきかについて完全に整理された考えはまだない。リグレッションがあり、Tridgell はそれを境界ケースだと説明したが、これ以上の文脈がないと、その境界ケースのリグレッションの影響と、潜在的なセキュリティ問題の修正の価値をどう比較すべきか分からない。
「WITHOUT ANY WARRANTY」を持ち出したくなる人もいるだろうが、その条項はここでは無関係だ。これは法的責任の否認であって、職人気質への誇りや最善を尽くすべきだという非法的な要求の否認ではない。このコメントも「WITHOUT ANY WARRANTY」で提供されているが、私がミスをすれば当然批判されうる。
作者がそれを基幹ソフトウェアにしたわけではない。あなたや他の誰かがそれを使うなら、責任はユーザー側にある。ソフトウェアが期待どおりに動かなければ、フォークするか代替すればよい。してはいけないのは、その人にあなたの都合に合わせて動くよう強いることだ。
元のリグレッション報告を見逃した人向けの文脈: https://github.com/RsyncProject/rsync/issues/929
issue 報告は mastodon post のスクリーンショットで、その後に約 300 件を超える論争コメントが続いている。
説明せず、これまでどおりやればいい。嫌う人はこれからも嫌い続ける。
人々がアセンブリを書かなくなった頃から嫌われ始めたし、これからも止まらないだろう。