ついにDebianのライブイメージが再現可能に！その驚異的な努力とは？
引用元：https://news.ycombinator.com/item?id=43484520
マジすごい努力だね。数年前には夢物語みたいに聞こえたのに。関係者みんな、特に頑張った人にマジおめでとう。
Debianグループは尊敬しかないわ。OSデザインの基準を何度も良い方向に変えてるし。確定申告の時期になったら、コーヒー代を寄付しなきゃ=3
ほんとそれ！
何度も言ってるけど、ここでも言うわ。Debianは今あるLinuxディストリビューションの中で、100年後も確実に残ってる数少ないものの一つだと思う。
Archとかと比べると、バージョン管理とかリスクの面で最新ってわけじゃないけど、それがまた良いんだよね！
＞Debianは100年後も残るLinuxディストリビューションの一つになるだろうね。
そうだと嬉しいけど、組織が崩壊するのを見たことある人ならわかると思うけど、あっという間に終わることもあるからね。何も考えずに適当に選んだら、寿命の半分くらいって考えるのが普通だし、Debianが100年もつって言うのはまだ早いんじゃないかな。
＞Debianが100年もつって言うのはまだ早いんじゃないかな。
それってちょっと弱い意見じゃない？その考え方って、対象について何も知らない時に使うものじゃん。Debianとか似たようなプロジェクトについては色々知ってるんだから、その情報で考えをアップデートできるはずだよ（ベイズ的に）。Ian Murdockが31年前にDebianを始めたってことを考えたら、100年以上続くって予想するのは全然アリだと思うよ。
[0] 例：https://en.wikipedia.org/wiki/Lindy_effect
パッケージの非推奨化プロセスがあるから、人気のないプロジェクトはアップデートの時に削除されることが多いよね。
Flatpak/Snap/Dockerは、古いプログラムを新しいシステムで動かしたり、OSと互換性のない新しいソフトウェアを古いシステムで動かすためのものだよね。理想的な解決策ではないけど、win/exeみたいに長期サポートされてるプログラムを使うには必要だよね。
マイナーなものを使ってると、リポジトリから消えるのが早いよね=3
Lindy効果は理解できるけど、どんな分野にも当てはめるのは危険だと思うな。特にITは、新しいプロジェクトが次々と現れて、他のプロジェクトを追い落とすからね。Debianが30年続くのはありえると思うけど、100年は賭けかな。Debianみたいなプロジェクトの寿命についてのmetaculusの質問は面白そう。
＞特にITは、新しいプロジェクトが次々と現れて、他のプロジェクトを追い落とすからね。
Lindy効果は人気については何も言ってないよ。ここでは「追い落とす」って言葉で人気を表現してると思うけど。Lindy効果が言ってるのは、何かが存在してる期間が、将来も存在し続ける可能性と関係があるってこと。
＞特にITは、新しいプロジェクトが次々と現れて、他のプロジェクトを追い落とすからね
でも31年も続いてるって、IT業界ではマジで凄いことだよ。しかも、常に最新の状態に保たれてて、構造も良いし、貢献も凄いし、進化もしてるし。
一方で、CentOS、RedHat、Oracleの騒動を見てよ。どれだけ混乱させたんだよ。
なのにDebianは、ただひたすらに進んでる。
FreeBSDベースのDebianプロジェクトが、関心がないってことで終わっちゃったのは残念だったな。
100年後には、従来のノイマン型アーキテクチャなんて存在しないと思うよ。エネルギー需要の問題で、もっと効率的な設計が必要になると思うからね=3
DebianよりArchの方が安心できるなー。Debianってオリジナルのソフトウェアにめっちゃパッチ当てるじゃん？もはや原型留めてないレベル。Archはほぼオリジナルのコードそのまま使うし。Debianのメンテナーより、オリジナルの開発者の方が信頼できるわ。
＞オリジナルの開発者の方が信頼できる
それならDebian使わないのが正解だね。どのディストリを選ぼうが、メンテナーを信頼することになるんだし。
でもそれって良い点でもあるよね。ネットの怪しいコードを信用するより、信頼できるメンテナーグループが吟味したネットの怪しいコードを信用する方が、まだマシじゃない？
Debianはメンテナーの審査プロセスとか検証環境とか標準化されてるし、何か問題があっても誰の署名が原因かすぐ特定できる。
笑えるのがCanonicalの採用試験。飛行機のパイロットになるより書類が多いらしいよ…
認証付きの署名済みパッケージングって時間かかるし、手っ取り早くpip/npm/cargo/go使いたくなる気持ちもわかるけど、何かあった時に誰も責任取らないんだよね。
完全なランダムではないけど、数百のプロジェクトを含むOSリリースを「安定」させるには時間かかるのも仕方ないよね。
そうそう、それが言いたかった。ディストリを使えば、メンテナーによる何らかの検証を受けられる。検証されてないパッケージマネージャーだと、どっからともなく降ってくる。
メンテナーの検証なんて信用してない。小さなプロジェクトでもコード多すぎ。大規模プロジェクトはコードの海。メンテナーはめちゃくちゃ多くのパッケージをメンテしてるから、変更点を少しも理解できない。だから信用できない。変更点を分析するには、プロジェクトごとに専門のエンジニアチームが必要だけど、そんなの無理。
せいぜい、開発者の指示に従ってバイナリを作成してアップロードするだけ。それをPKGBUILDみたいなスクリプトにするくらいでしょ。
＞バイナリを作成してアップロードするだけ
それってメンテナーがやってることそのものでは？PKGBUILDみたいなレシピを書いて、パッチ当ててパッケージをビルドして配布する。
ArchだろうとDebianだろうと、メンテナーがマルウェアを仕込まないことを信じてるんでしょ？自分でPKGBUILDとかupstream projectを確認する人なんてほとんどいないでしょ。
いやいや、メンテナーは都合の良いようにソフトウェアを改変するんだよ。
最近の例だとこれ：https://www.reddit.com/r/debian/comments/1cv30gu/debian_keep…
こういうことよくあるし。開発者が意図しない方法でソフトウェアがパッチされてビルドされて、ユーザーが困って開発者に文句言ったり、脆弱性につながったり、ライブラリのリンク先をメンテナーが「より良く」変えたりして不安定になる。
＞https://www.reddit.com/r/debian/comments/1cv30gu/debian_keep…
公式のビルドオプションを使って、デフォルトで特定の機能を無効にして、別のパッケージで全部有効にするようにしただけじゃん。
それが「Debian adds so much of their patches on top of original software, that the result is hardly resembles the original.」の最高の例なら、Debianは思ったよりバニラに近いってことだね。
＞メンテナーは都合の良いようにソフトウェアを改変する
うん、でもどのメンテナーを選ぶかは自分次第じゃん。君はArchの方が「パッチが少ない」から好きって言ってるんだよね？
それでも、レシピ書いてビルドしてバイナリを配布するって、君が言うべきことちゃんとやってるじゃん。自分でビルドしたいならGentooもあるし。
＞https://www.reddit.com/r/debian/comments/1cv30gu/debian_keep…
パッケージを二つに分割しただけでしょ？Debianのやり方が気に入らないなら、別のディストリを使えばいい。ディストリを使うなら、メンテナーに頼ることになるってのは変わらないよ。
一般的に、見かけ上のユースケースとOSセキュリティへの意図しない影響は明確にする必要がある。Webブラウザ、シェル、メールプログラムに触れる「セキュリティ」ウィジェットには常に疑念がある。CVE-2023-35866みたいのが出たら、プロジェクトは責任問題になる。
3ページのBS説明が必要なアプリケーションはダメな設計。
脅迫してくるやつは大抵BANされる。
Debianマジ好きだけど、これって結構知られてないよね。Ubuntu使ってるとCanonicalが独自のパッチ当ててたりするから、さらにややこしくなるんだよねー。Debianをベースに自分のソフト動かすだけなら、そこまで気にしなくてもいいかもだけど。Debianのパッケージメンテナーがビルドエラーとか依存関係のミスマッチ直すためにパッチ当てるのはよくある話で、ほとんどは問題ないけど、たまにヤバいのがあるんだよね。Debianベースのパッケージにだけセキュリティホールがあったりとか。どのディストリも完璧じゃないし、Debian批判するつもりはないけど（ちゃんとした理由があってやってるんだし）、Archだってパッチなしで全部そのままってわけじゃないし。でもDebianでこういうのにハマったこと何度かあるんだよねー。 ＞Debianベースのパッケージにだけセキュリティホールがあったりとか。 今スマホからだから記憶頼りだけど、2020年くらいか2010年代後半に急いでパッチ当てた記憶があるなー。確かopensslのパッチのuse-after-free vulnだった気がするけど、自信ない。家帰ったら探してみるわ。 一般的に、責任を持って報告されたCVEは、パッチ修正がエコシステムに伝播するまで数週間猶予があるんだよね。OSのサポートが終了すると、攻撃対象領域が大きいほど既知の問題が蓄積されやすくなる。だから、レガシーな複雑なモノリスやデスクトップホストは、アボカドの袋よりも早く腐るんだよね。=3 Debian unstable (sid) 使えば、常に最新のパッケージを手に入れるって言うリスキーなアプローチも簡単だよ。 最近は特定のものをより最新にするために、専用のリポジトリを追加することもできるよね。あと、fzfみたいに手動でインストールするツールもあるし。 Debianのパッケージマネージャーよりも新しいアプリが欲しいなら、Flatpakも良い選択肢だよ。 そうそう、いくつかツールでやってる。ただ、apt-keyの廃止がまだ完全に受け入れられてないから、そこがちょっと面倒なんだよね。 オープンソースプロジェクトにもっと寄付したいんだけど、カナダだと税額控除が受けられるプロジェクトがないんだよねー。予算ギリギリだから、何もなしに寄付するのはちょっと厳しいんだ。 どこに住んでて、どこで働いて、どこに投資してるかによるね。念のため、大きな寄付が控除対象になるかどうか、地元の会計士に相談してみるのがおすすめだよ。ほとんどの大規模大学はアメリカとカナダ両方で登録されてるはず。 ビルドの再現性ってどうやるんだろ？ファイルのタイムスタンプとかどうするの？無視するのかな？内容が同じなら、タイムスタンプが違ってもハッシュ値は同じになるってこと？ Debianは これPerlで書かれてるんだね。DebianのツールってPerlが多いの？ strip-nondeterminismの作者だよ。Perlなのは、Debianのほぼ全てのパッケージのビルドに使われてるから。他の言語だと、その言語のランタイムがDebianパッケージのビルドの依存になっちゃうんだ。Perlはビルドプロセスで必須だけど、Pythonは違うからね。 Perlは、Pythonより優れたbashみたいなもんだと思えばいいんじゃないかな。 さっきの投稿読んだ？作者がPerlを選んだ理由を説明してるじゃん。OSのビルドに新しい言語の依存関係を追加するのは簡単じゃないんだよ。 それをメンテする人が見つかるのかな？今のメンテナーが永遠に生きるつもりじゃない限り、短絡的だと思うな。 もっと良い選択肢があるのに、悪い選択肢があるからって無視するのはおかしくない？ 記事にはbashのより良い代替としてPerl使ってるって書いてあるじゃん。Pythonの方が良いとは思ってないんじゃない？質問の意図間違えてたらごめんね。 PythonよりPerlが劣ってるとも思えないし、意味不明な言い方だよね。 確かに変な言い回しだね。「Perlはbashよりマシ（ちゃんとしたプログラミング言語が必要なタスクにおいて）」って意味で、「Pythonより劣ってない」ってことかな。 マジで、彼らはPythonの方が良いと思ってるのに、Perlの方が劣るからPerlを選んだって信じてるの？どういうこと？ パッケージングとかビルドスクリプト作成って、マジ報われないタスクの一つだよね。Debianみたいなオープンソースプロジェクトだと、みんなボランティアだから、どの言語を使うか強制できないんだよ。 一部はそうだけど、全部じゃないよ。昔のコードのせいでPerlがベースに入ってるけど、最近のツールはPythonも多いし、POSIX shellもあるよ（bashじゃない）。 apt関連のツールは、前に調べたときPerlで書かれてたな。 OpenBSD関連のやつもPerlで書かれてるの多いよね。全然悪いことじゃないと思う。 Perlマジ好き。GoogleがPythonを推したせいで負けたのが悲しい。当時みんなGoogleで働きたかったからね。HNでPerlは嫌われがちだけど、Camel本読んだ後にPerlを1時間以上使った人どれくらいいるんだろ？Linux触るなら、Camel本は一度読むべき。その後でPerlについて語ってくれ！ タイムスタンプは簡単だよ。選んだエポックに合わせて設定するだけ。 ASLRはアプリのメモリ状態を全部キャプチャしたい時以外は問題ないはずだよ。あれはメモリの中間表現であって、ビルドの出力じゃないし。JSONキーのソートみたいな内部オブジェクトのシリアライズで面倒なケースが出てくるけどね。 ASLRってことはmalloc（mmapから来るかも）のアドレスが予測できないってこと。プログラムによってはオブジェクトの同一性をキーにしたハッシュテーブル（ポインタとか）使ってたりするし。ASLRのせいで、プログラムの実行ごとにオブジェクトのアドレスが変わって、ハッシュテーブルの順番が変わったりするかも。それが原因で出力が変わるプログラムはバグとは限らないけど、再現性の問題になるね。例えば、コンパイラがシンボルテーブルをポインタのハッシュでソートして出力するとか。順番が違ってもオブジェクトファイルの意味は変わらないけど、完全に同じビルドじゃないってことになる。 それってコンパイラの非決定性の一例にすぎないんじゃない？結局、コンパイラがそういうことをしないオプションを用意する責任があると思うよ。 基本的にはそう。https://reproducible-builds.org/docs/timestamps/ 見てみて。ビルドが再現可能なら、いつビルドされたかは関係ないはず。ビルドのソースを追跡したいなら、タイムスタンプよりもっと良い方法があるよ。 Cコンパイラには__DATE__とか__TIME__マクロがあるけど、プリプロセッサが呼ばれた日時を表す文字列に展開されるんだ。これらを使ってるコードはビルドするたびに違う文字列になるから、修正が必要だね。実際の製品プログラムで使う理由が思いつかないけど、なぜか存在するんだよね。 だからGCCとかは環境変数のSOURCE_DATE_EPOCHを受け付けるし、-Wdate-timeオプションもあるんだね。__DATE__とか__TIME__をコードで使うのは、ソース管理とかビルドIDが普及する前には便利だったのかもね。 ソース管理は全部コミットしてれば役に立つけどね。例えばFreeBSDのブートローダーを修正してるとするじゃん？テストするたびにコミットしないと思うけど、“10分前にビルドしたバージョン”なのか“昨日ビルドしたバージョンをインストールし忘れて起動しただけ”なのかを知るのはすごく役に立つんだ。 ＞FreeBSDのブートローダーの変更作業をしていて、テストするたびにコミットしないって？ 見落としがちな点：FreeBSDはCVSを使ってるから、DVCSみたいにローカルでコミットできないんだ。 FreeBSDは2008年からCVSを使ってないよ。 えーと！投稿する前にダブルチェックしに行ったら、https://wiki.freebsd.org/VersionControl があったんだよね。 再現可能なソフトウェアのツールチェーンなら、これらの値を設定できるか、1970-01-01 00:00:00 になるようにできるんじゃないかな。 Nixは全部epochに設定するけど、Debianのアプローチはdsc tarballの中で一番新しいファイルのdateを使うだけだと思う。 もしかして的外れな質問？git repoをcloneしたら、gitに保存されてるメタデータも取得できるんじゃないの？それとも、ファイルの更新日はcloneした時の日付になるのかな？確認したことなかったわ。 gitからソースをcloneするけど、それを使って成果物を作るんだよね。成果物のビルド時間は違うかもしれないけど、再現可能なビルドなら成果物は一致するはず。 cloneしてbuildするだけなら、ファイルの更新日がgitにcommitされたバージョンと違うってことある？repoをcloneするだけで、ローカルコピーのファイルの更新日が違っちゃうの？ Gitはファイルの更新日時を保存したり復元したりしないよ。 ファイルのハッシュを生成するのにそれらは必要ないでしょ。それに、そのメタデータはファイル自体の一部じゃないし（少なくともそうである必要はない）、ファイルシステムかOSの一部だよ。 ファイルを配布するだけの単純なケースならそれでいいけど、配布物がもっと複雑なもの、例えばサブアーカイブを含むアーカイブだったらどうなるの？内部ファイルのメタデータは結果のアーカイブのchecksumに影響するよ。 ＞…ファイルの作成/変更タイムスタンプのようなメタデータはどうするの？それらも偽造するの？ それって、.debファイルから.isoファイルを作る話で、ソースから.debファイルを作る話じゃないんだよね。ソースから再現性のある.debファイルを作るのは、まだ開発中ってことみたい。 Debianのビルド基盤も再現性があるのかな？誰かがDebianパッケージのバイナリにマルウェアを仕込みたい場合（ソースをいじらずに）、ビルド基盤（コンパイラとかリンカとか）を狙う必要がありそう。あと、誰か他の人が同じイメージをコンパイルして、Debianのコンパイルサーバが侵害されてない証拠はあるのかな？ Debianの再現性に関する結果は、このページにあるよ: https://tests.reproducible-builds.org/debian/bookworm/index_… イメージについても同じようなものがあると思うけど、URLはわからない。 再現性のあるビルドのポイントは、ビルドボットが侵害されてもセキュリティを確保することだよ。 ビルドが実行されるハードウェアはどうなの？再現性あるの？😉 それに取り組んでるよ！基本的には、独立して作られたたくさんのハードウェアが同じ結果を再現できることを示すのが、ほとんどの場合において十分だってこと。 冗談でしょ。でも、この問題を解決することは、私たちが生きる情報時代において最も重要なことの一つだと思う。世界中のすべての国が「十分に良い」ハードウェアを製造できる能力を持つべきだ。 ＞ And what about the hardware on which the build runs? Is it reproducible? ;) A la xz って感じだね。結局、信頼できるバイナリとかハードウェアが必要になるんだよね ユーザースペースの話？それなら、364バイトくらいのx86_64バイナリだけで動くステージ0ビルドもできるよ（皮肉なことに、まだ成功してないけど）。問題はEFIとかIntelのリング-1の部分（これはオープンソース化すべき）だね。 それって、364バイトのものがマシンコードで書かれてるって言ってるのと同じだよね（かなり正確に）。バイナリとアセンブリを人力で変換できるくらい小さいってこと。 再現性のあるビルドって何がすごいの？普通のディストリビューションとどう違うの？もっとコメントを表示（1）
CVE-2008-0166より新しい例ってある？
誤解されたくないから言っとくけど、セキュリティが理由でDebian避けるってわけじゃないよ。ハックされたカーネルとか古いパッケージの方がもっと困るかな。でもそれも数年前までだけどね。普通に使う分には（自分で色々コンパイルしない限り）問題ないよ。
カナダ在住の人で、税額控除対象になるソフトウェアプロジェクト知ってる人いる？
https://www.canada.ca/content/dam/cra-arc/formspubs/pub/p113…
よろしくね、=3strip-nondeterminismってツールを使ってるよ。https://salsa.debian.org/reproducible-builds/strip-nondeterm…に情報があるよ。DebConf 2024の記事も参考になるかもね。https://lwn.net/Articles/985739/もっとコメントを表示（2）
難しいのは、不安定なハッシュ順序、ソートされてないファイルシステムリスト、並列実行、アドレス空間のランダム化とか。
なんで？FreeBSDのブートローダーにはVCSがないとか？
見落としてたのは（今となっては当然だけど）「以下のセクションはFreeBSDのCVSからSubversionへの移行に関する歴史的な参考資料です」っていうバナーだった。
ごめん！結局、SVNはDVCSじゃないから、未完成のコードをコミットするのは避けたいってことだよね？
（FreeBSDとOpenBSDを頭の中で混同してたかも、恥ずかしい…）もっとコメントを表示（3）
再現可能なビルドのために解決するのは一番簡単だけど、そうだよ。
本当の問題は、なぜ過去に非決定性が当たり前で、みんなそれがOKだと思ってたエコシステムが作られたのかってこと。
「どうすれば再現性が達成できるのか？」って聞く代わりに、「なぜ人々はわざわざタイムスタンプみたいな単純なものが決定性を狂わせるようにしたのか？」って疑問に思うべきじゃない？
それこそが戦うべきアンチセキュリティの考え方だ。そしてDebianはそうした。
Debianのサイトに色々ドキュメントがあるし、LWNにもHolger LevsenのDebConfでの講演に関する記事があるよ: https://lwn.net/Articles/985739/
「Diverse Double-Compiling (DDC)によるTrusting Trustへの完全な対抗 - コンパイラへのトロイの木馬攻撃への対抗」https://dwheeler.com/trusting-trust/
もしビルドがVM内で再現可能なら、x86とARMのように異なるアーキテクチャでビルドできる。もし同じライブイメージができたら、それは全く別の話になる。x86とARMの両方が同じようにバックドアされてるか、攻撃がソフトウェアによるか、あるいはバックドアがない（それも考える必要がある）。
