Debian、再現可能なパッケージの提供を必須化

 (lists.debian.org)
1 ポイント 投稿者 GN⁺ 5 시간 전 | 2件のコメント | WhatsAppで共有
  • Debian リリースチームは、forky サイクルの中間時点で 再現可能なパッケージ の提供を決定
  • 移行ソフトウェアが、reproduce.debian.net で再現できない 新規パッケージ をブロック
  • testing の既存パッケージに 再現性の退行 が生じた場合も移行がブロックされる
  • binNMU にも、source-full アップロードと同様の autopkgtest 実行機能が追加
  • loong64 の追加と multi-arch の再ビルドにより CI キュー が増大し、忍耐が必要

Debian パッケージ再現性の義務化

  • Debian リリースチームは、forky リリースサイクルの中間時点で Debian が 再現可能なパッケージ を提供すべきだと決定
  • この決定は、Reproducible Builds プロジェクト の取り組みに支えられたもの
  • 前日から、移行ソフトウェアが reproduce.debian.net で再現できない 新規パッケージ の移行をブロックするよう有効化された
  • testing にすでに存在する既存パッケージで 再現性の退行 が発生した場合も、移行はブロックされる

品質保証とアップローダーの責任

  • testing binNMU の autopkgtest 実行

    • 今年初め、移行ソフトウェアに binNMU でも source-full アップロードと同様に autopkgtest を実行する機能が追加された
    • この機能は多くのメンテナー作業と直接の関係は薄いかもしれないが、品質保証を強化するもう一つの段階として扱われている

  • loong64 アーキテクチャ追加と CI キュー増加

    • 2 週間前、アーカイブに新アーキテクチャ loong64 が追加された
    • Debian は buildd でビルドされたバイナリのみ移行を許可しており、multi-arch 要件 のため、すべてのアーキテクチャでかなりの数のパッケージを再ビルドする必要があった
    • 先に追加された binNMU 機能のため、現在 CI キュー はかなり大きくなっており、リリースチームは少しの忍耐を求めている

  • アップロード後のフォローアップ

    • ソースパッケージのアップローダーには、そのパッケージが移行されるよう保証する責任がある
    • パッケージが逆方向のテスト依存関係の autopkgtest 回帰 によってブロックされ、その依存関係の更新が必要な場合、アップローダーは適切な RC 深刻度のバグを提出しなければならない

関連記事

2件のコメント

 
GN⁺ 2 시간 전
Hacker Newsのコメント

  • Debianと自由ソフトウェアの世界にとって大きな成果だと思う。
    ただ、この必要性が理解されるまでにはかなり時間がかかった。2007年にdebian-develでこれが必要だと言ったときも、ひどい時間の無駄だという返答を受けたし、実際ここまで来るには多くの人による莫大な作業が必要だったが、それだけの価値は十分にあった

    • 2007年以降、Debianで再現可能なパッケージによって防げたバグや攻撃はなかった。
      「価値があった」というのは当たらないと思う。Debianへの貢献のハードルをさらに上げるだけで、ただでさえDebianへの貢献が難しいと不満を言う人を多く見てきた。以前は「パッケージ同士がうまく噛み合うよう、あらゆる検証やチェックが必要だ」と擁護していたが、これは特に理由もなく難しくしていて、得られる利益も小さい段階に見える

  • https://wiki.debian.org/ReproducibleBuilds に詳しい情報がある。古くなっている部分もあるが、CIでビルドされるパッケージ数と、そのうち再現可能なビルドがどれくらいあるかを示すグラフもある。
    オレンジ色はFTBR、つまり「再現可能なビルド失敗」を意味する。グラフから数字を読むのは得意ではないが、ざっくり数パーセント、4〜5%くらいだと見ている

    • 私にはこれしか表示されない:

      Forbidden

      You are not allowed to access this!
      HTMLタグまでそのまま見える :)
      編集: 履歴をたどったら「I Challenge Thee」ページも見つかった。もしかしてボット対策に引っかかったのか？ なぜ???

  • 良いことだ。NetBSDは2017年から完全に再現可能なビルドを実現している。https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

    • リンクにもある通り、NetBSDはDebianの助けを借りてそれを達成した。正しく理解しているなら、NetBSDがより頑張ったというより、問題の方が簡単だったということだ。パッケージ数が少なく、変更も少ない。今でもCVSを使っているので、「安定性」という言葉でも足りないくらいだ。
      ちなみにDebianパッケージの大半は再現可能なビルドになっている。そうでないもの、だいたい5%ほどのパッケージは、ここのグラフでオレンジ色で表示されている: https://wiki.debian.org/ReproducibleBuilds
    • 自慢をすると、stagexは昨年、100%フルソースブートストラップに基づく決定論的かつ隔離されたビルドを初めて達成し、各リリースで異なるメンテナーがそれぞれのハードウェア上で実行した複数の署名付き再現を必須にしたのも初めてだ。
      Debianも大きく前進したが、Debianが再現可能だと言うとき、それは自分たちのビルドのためにサードパーティのバイナリを持ち込むという意味だ。私たちが再現可能だと言うときは、ソフトウェアサプライチェーンの最後まで100%ソースコードからブートストラップするという意味だ。
      この違いは重要だと思う。
      https://stagex.tools

  • この変化は本当にうれしい。2021年にSolarWinds攻撃の記事を読んで衝撃を受けて以来、再現可能なビルドに関わるようになった。[1]
    OpenJDKの再現可能ビルドに取り組んでいたMagnus Ihse Bursieの言葉がいちばん的確だと思う: 「私に言わせれば、コンパイラとビルドツールがいつの間にか非決定的な出力を作るようになっていたという事実そのものが、初日からのバグだった。」[2]
    [1] https://www.linux.com/news/preventing-supply-chain-attacks-l...
    [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997

  • 最近なぜこれが話題になっているのか気になる。組み込み機器でYoctoを使っているが、再現可能なビルドはほとんど当然のように実装できていた。
    Debianパッケージ管理も簡単に有効化できるので、もう全部できているのではと思ってしまう

    • 「最近なぜこれが話題なのか」というのがどういう意味か気になる。
      再現可能なビルドは産業用コンピューティングでは必須の手法だ。Debianがこの分野の最前線にいるというより、長期運用や安全関連の用途で使われる他のオペレーティングシステムにも適用されている業界全体の手法を取り入れている、という方が近い。
      もちろん、YoctoやDebian開発者たちの多くの困難な作業のおかげで、すでに簡単に使えている部分も大きい。
      興味深いのは、Debian開発者たちが今やこれをより前向きな方針として適用し、選択肢ではなく基本規範にしようとしている点だ
    • 実際にビルドがビット単位で再現可能かどうかを能動的に検証したのか気になる

  • amd64 forky基準
    reproduced: 97.02%
    good: 17586
    bad: 511
    fail: 30
    unknown: 0
    この統計や他のアーキテクチャの統計、再現不可能な理由は https://reproduce.debian.net で見られる

  • Debianがこれを主導していて、しかも商用ベンダーではないというのはいつも意外に思う。RHELやUbuntuにお金を払っている大きな組織なら、検証可能なバイナリを強く求めそうなのに

    • 競合相手が、自分たちのパッケージが大きな組織の配布物とビット単位で同一だと証明できるなら、その競合相手はその大きな組織のセキュリティ保証の恩恵を受けられる。
      自由ソフトウェアにとってはとても良いが、独占者になりたい側にとってはあまり都合が良くない
    • 再現可能なビルドは信頼の必要性を減らすために存在するが、商用ベンダーは信頼を売るビジネスをしている

  • Forbidden
    You don't have permission to access this resource.
    Apache Server at lists.debian.org Port 443
    :/
 
GN⁺ 5 시간 전
Lobste.rsの意見

  • セキュリティ面で良い変化だと思う。移行プロセスは煩雑になり得るが、最終的には世界中のDebian Linuxユーザーにより高い信頼性を提供することになる

  • Debianのようなプロジェクトにとっての中核的な利点は何なのか気になる。誰もがバイナリにバックドアがない証拠を持てるようにするということなのだろうか?
    つまり、メンテナーに要求される信頼を減らし、悪意あるメンテナーのリスクも下げる効果があるのか気になる。懐疑的というわけではなく、Debianがなぜここにこれほど多くの時間を使っているのかを100%理解できていない。ビルドを再現可能にするのはかなり厄介で手間のかかる作業に思える

    • バックドアだけでなく、一般的な改ざんや変更の有無も確認できるようになる。これはセキュリティにも役立つし、プロジェクト開発にも利点がある。再現可能である程度閉じた形でビルドされるパッケージは、他の開発者環境で奇妙に壊れる可能性が低くなる。
      要点は、出力されたパッケージを生成したソースコードが本当にその特定のソースコードであり、隠された第2のソース一式ではないという証拠成果物を提供することにある。the reproducible-builds org has a bit of a 'why' which puts it better than i can
      再現可能なビルドを実現するのは非常に難しい。たとえばコンパイルパイプライン内のタイムスタンプも差異を生み、生成されたアーカイブのメタデータも同様だ。こうしたものをすべて取り除く必要があり、場合によってはパッケージ自体ではなく、CMakeやGoコンパイラのような上流プロジェクトへのパッチが必要になる。多くの場合、以前はこうした問題がそもそも考慮対象ですらなかったため、ビルドスタック全体にわたる作業が必要になる。ただし、この作業はかなり前から進められてきたので、下回りのかなりの部分はすでに完了しているか、かなり深く進行している
    • これがDebianの最優先事項であるべきだとは思わないが、Debianはそういうふうには動かない。人々は自分がやりたいことをやるのであって、個人の優先順位はプロジェクト全体として妥当な優先順位と一致しないことが多い

  • Debianの言う再現可能性は、NixOSのようなところで言うものと同じ概念なのか?

    • いや。NixOS is not reproducibleが標準的な参考記事だ
    • 再現可能なビルドをプロジェクトとして追跡しているディストリビューションは、おおむね同じ目標に向かっている。reproducible-builds.orgは、パッケージングパイプラインでこれに積極的に取り組んでいるプロジェクトを追跡している。
      NixOSも再現可能なビルドに取り組んでおり、記憶が正しければ少なくともISOはビルドとランタイムの両方で100%再現可能だ。しかし、一般にNixOSについて語られる再現可能性は、ここで議論している「再現可能なビルド」ではない。このスレッドの兄弟コメントでリンクされているfoxboronの記事を見ればよい。それは環境の再現性、あるいは「決定的ビルド」に近いもので、依然として価値はあるが、ここで話している対象ではない

  • 今のところ、ラチェット方式のように聞こえる。これまで一度も再現可能にビルドされたことがないものは、依然として許容されるのか?

    • パッケージが再現可能にビルドされなければ、次のDebianリリースには含まれない。つまり、「一度も再現可能にビルドされたことがない」パッケージはDebian unstableには残れるかもしれないが、stableに到達しないパッケージをDebian unstableに置き続けることは好ましく見られていない。ただし、機械的に強制されるルールはないと理解している