ハクソク

世界を動かす技術を、日本語で。

Arch Linuxがビット単位で再現可能なDockerイメージを提供開始

18時間前原文(antiz.fr)

概要

  • Arch Linuxが新たにbit-for-bit再現可能なDockerイメージを公開
  • 再現性の確保のため、pacmanの鍵が初期状態で除去されている
  • **専用タグ“repro”**で配布、利用時は鍵の再生成が必要
  • イメージの再現性はdigest一致やdiffociで確認済み
  • 今後は自動再ビルドや公開検証の計画も検討中

Arch Linuxのbit-for-bit再現可能なDockerイメージ公開

  • Arch Linuxがbit-for-bitで再現可能なDockerイメージをリリース
  • “repro”タグで配布し、通常のイメージとは区別
  • 再現性確保のため、イメージからpacmanの鍵を削除
    • pacmanは初期状態で利用不可
  • ユーザーはpacman鍵の再生成が必要
    • コマンド例:
      pacman-key --init && pacman-key --populate archlinux
    • Dockerfile内RUN文や初回起動時の手動実行で対応
  • Distrobox利用者はpre-init hookで自動化可能
    • 例:
      distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"
  • イメージの再現性検証
    • digest一致（podman inspect --format '{{.Digest}}' <image>）
    • diffociによるビルド比較
  • ドキュメントで再現手順を公開

Dockerイメージ再現性の技術的工夫

  • WSLイメージと同じrootFSビルドシステムを利用
  • Docker固有の調整点
    • SOURCE_DATE_EPOCHの設定とDockerfile内LABELでの反映
    • ldconfigのauxiliary cacheファイル（非決定性の原因）を削除
    • タイムスタンプの正規化
      --source-date-epoch, --rewrite-timestampオプションで対応
  • 具体的な差分や詳細はarchlinux-dockerリポジトリで参照可能

今後の展望とコミュニティへのメッセージ

  • reproducible builds推進の一環として重要なマイルストーン
  • 自動再ビルド・検証システムの導入も検討中
    • サーバー上でDocker/WSLイメージを定期的に再ビルド
    • 再現性検証とビルドログの公開予定
  • コミュニティの協力と今後の発展への期待

Hackerたちの意見

再現可能な画像って、感情的な価値が大きい機能の一つだよね。でも、いつかその価値が実際に役立つ日が来るまで待たなきゃいけない。実際、二台のマシンで同じはずの画像が、タイムスタンプで3バイトの差があって、間違った方からビセクトするのに午後を無駄にしたことがあった。つまらない勝利だけど、実際の勝利だね。
└
どうして異なるタイムスタンプが最初に問題を引き起こしたの？ちょっと気になる。
これは本当に面白い成果だね！僕もファームウェアプロジェクトの再現可能なビルドに力を入れてるんだけど、驚いたことに、パッケージマネージャーのキー管理が最後の難関なんだ。Archがこれを先導することで、他のディストリビューションも同じことを試みるきっかけになるかな。再現可能なビルドは、認証やセキュリティ、重要な安全アプリケーションにとって重要だから、Linuxディストリビューションがこの方法にもっと準拠するようになるといいな。
└
Debianでは、これに関するプロジェクトが進行中だよ: https://wiki.debian.org/ReproducibleBuilds。
すべてのDockerコンテナは、こうあるべきだったよね。Dockerのビルドステップでの`apt-get update`はアンチパターンだよ。
└
アンチパターンなのはわかってるけど、ソフトウェアをインストールする必要がある場合、代わりに何をすればいいの？タグ付きのソースコードを引っ張って、gccで全部コンパイルするの？
└
こういう問題を解決するために、StableBuildを使ってるんだ。これは特定の時点で依存関係のキャッシュコピーを保持する管理サービスだよ。Dockerfile内で依存関係を固定して、再現可能なDockerイメージを作れるんだ。
└
どっちにしても詰んでるよ。更新しなければ、コンテナにはたくさんの既知のセキュリティ問題があるし、更新すると再現性がなくなる。再現性があるのは便利でセキュリティ面でもメリットがあるけど、コンテナが1ヶ月以上古いなら、再現性はあまり重要じゃないかも。1日でも古い方がマシかもね。
└
これはNixで20年以上前から解決されてる問題だけど、みんなに聞いても無理だよね。
└
それを厳格なルールとしては同意できないし、アンチパターンだという意見にも反対だな。再現可能なコンテナはいいけど、必ずしも必要ではないこともある。apt-getをコンテナで実行したい時もあるし、再現性なんて気にしないことも多いよ。
全く関係ないコメントだけど、そのページにはアニメーションがあって、1秒の間にページ上のほとんどすべてが約20ピクセル下に動くんだ。これでCumulative Layout Shiftのコアウェブバイタルが完全に崩れると思ったんだけど、実際にはそのページのCLSは0だった。じゃあ、CLSって誤解を招く指標なの？
└
レイアウトは変わってないから、レイアウトシフトじゃないよ。それに、CSSトランジションから来てるから、予想外ってわけでもない。
└
これは意図的なアニメーションの結果で起こってるんだ。CLSメトリックは初期レンダリングに関係してるから、レイアウトシフトはあるけど、CLSそのものではないよ。
こういう自信があるのはいいね。WSL 2でArch Linuxをほぼ1年使ってたけど、すごく良かった。その後、Archをネイティブで約5ヶ月使ったけど、やっぱりいい。今もArchをネイティブで使ってるけど、ArchのDockerイメージを使って新しいファイルシステムでdotfilesをテストしてるよ。それに、完全なデスクトップ環境をセットアップするためのエンドツーエンドテストをする時は、VMでArchを動かしてる。99の問題があるけど、Archを動かすのはその中に入ってないよ。[0]: https://github.com/nickjj/dotfiles
└
NixOSやフレークス試したことある？反応はどうだった？
再現可能なビルドについての詳細はこちら: https://reproducible-builds.org/ それに関連するのがBoostrappable Buildsコミュニティ: https://bootstrappable.org/
ちょっと細かいこと言うけど、「OCIイメージ」って言葉を使った方がいいと思う。podmanでちゃんと動くよ。
おそらく、CI/CDパイプラインに何かを組み込んで、みんなにArch使ってるって知らせることができるんじゃないかな（それに、たぶんCrossfitやってるってこともね）。
└
こんな公案があるよ：Archを使ってるビーガンのクロスフィッターに会ったら、最初に何を思う？
└
なんでSlackware使ってないことを誇りに思う人がいるのか、全然理解できない。
ローリングリリースモデルにはずっと魅了されてるけど、みんなサプライチェーン攻撃が心配じゃないの？最前線にいる人たちは、私たちにとってのカナリアみたいなもんだよね。
└
それがTFAみたいな再現可能なビルドの取り組みの目的なんだ。要するに、同じソースから複数のマシンでビット単位で同じビルドができることを確保すること。もちろん、ソース自体がやられたら意味がないけど、少なくともアーティファクトの改ざんに対するもう一つのバリアを作ることにはなる。どれくらいの割合のディストロが再現可能かを追跡するトラッカーもあるよ：https://reproducible.archlinux.org/
ArchやAlpineみたいなよく設計された「可変」オペレーティングシステムが、NixOSとかを長期的に打ち負かすかどうか気になるな。インストールスクリプトは、宣言的な設定言語よりも明らかに強力で、通常は冗長さも少ないし。