Arch Linux kini menyediakan image Docker yang dapat direproduksi bit-for-bit

• Image Docker Arch Linux dengan reproducibility bit-for-bit kini tersedia, memperluas tonggak yang sama yang dicapai pada image WSL beberapa bulan lalu ke Docker
• Image didistribusikan dengan tag repro khusus, dan untuk menjamin reproducibility, kunci pacman dihapus sehingga pacman tidak bisa langsung digunakan dalam keadaan default
• Untuk memasang atau memperbarui paket di dalam container, diperlukan pembuatan ulang keyring, yang dapat diinisialisasi dengan pacman-key --init && pacman-key --populate archlinux
• Reproducibility diverifikasi melalui kecocokan digest antar-build dan perbandingan dengan diffoci, bersama penyesuaian seperti build rootFS yang deterministik, normalisasi timestamp, dan penghapusan cache bantuan ldconfig
• Prosedur reproduksi dapat dilihat di REPRO.md, dan ke depannya ini bisa berlanjut ke rebuild serta verifikasi otomatis melalui server rebuilder, termasuk publikasi log build dan hasilnya

---

Poin utama

• Image Docker Arch Linux kini tersedia dalam bentuk dapat direproduksi bit-for-bit, memperluas tonggak yang sama yang dicapai pada image WSL beberapa bulan lalu ke sisi Docker
• Image ini didistribusikan dengan tag repro khusus, dan untuk menjamin reproducibility, kunci pacman harus dihapus dari image sehingga pacman tidak bisa langsung digunakan
  • Sampai solusi yang tepat tersedia, pembatasan ini membuatnya sementara disediakan terlebih dahulu sebagai tag terpisah
• Untuk memasang atau memperbarui paket di dalam container, Anda harus lebih dulu menjalankan pacman-key --init && pacman-key --populate archlinux untuk membuat ulang keyring
  • Pada eksekusi pertama, ini bisa dijalankan secara interaktif, atau dijalankan dalam pernyataan RUN pada Dockerfile yang menggunakan image ini sebagai basis
  • Di Distrobox, ini bisa ditangani melalui pre-init hook seperti distrobox create -n arch-repro -i docker.io/archlinux/archlinux:repro --pre-init-hooks "pacman-key --init && pacman-key --populate archlinux"
• Reproducibility bit-for-bit dari image ini dikonfirmasi melalui kecocokan digest antar-build, dan diverifikasi dengan podman inspect --format '{{.Digest}}' <image> serta perbandingan menggunakan diffoci
• Cara mereproduksi image Docker ini dapat dilihat di REPRO.md

Implementasi dan penyesuaian

• Tantangan terbesar adalah membangun rootFS dasar untuk image Docker secara deterministik, dan proses yang sama dengan image WSL yang berbagi sistem build rootFS digunakan kembali
  • Commit WSL terkait dapat dilihat di sini
• Salah satu penyesuaian khusus Docker adalah menetapkan SOURCE_DATE_EPOCH dan menyesuaikan LABEL org.opencontainers.image.created pada Dockerfile agar mengikutinya
• File cache bantuan ldconfig var/cache/ldconfig/aux-cache, yang memicu non-determinisme pada image hasil build, dihapus pada tahap Dockerfile
• Saat docker build atau podman build, opsi --source-date-epoch=$SOURCE_DATE_EPOCH dan --rewrite-timestamp digunakan untuk menerapkan normalisasi timestamp
  • Sebagai contoh, ditunjukkan adanya masalah ketika waktu pada etc/, etc/ld.so.cache, etc/os-release, sys/, var/cache/, var/cache/ldconfig/, proc/, dev/ tercatat berbeda-beda
• Seluruh perubahan terkait dapat dilihat lebih detail di merge request diff repositori archlinux-docker
• Langkah berikutnya mencakup kemungkinan membangun rebuilder di server untuk image Docker, image WSL, dan image reproducible berikutnya, guna rebuild otomatis berkala, verifikasi reproducibility, serta publikasi log build dan hasil

[GN⁺]

Komentar Hacker News

• Menyenangkan melihat rasa percaya diri seperti ini
  Saya menjalankan Arch Linux di WSL 2 selama hampir 1 tahun dan hasilnya sangat bagus, lalu memakai Arch native sekitar 5 bulan dan tetap puas
  Sampai sekarang saya masih memakai Arch native, dan dotfiles saya diuji dengan image Docker Arch di filesystem yang bersih
  Saat butuh pengujian end-to-end sampai penyiapan lingkungan desktop penuh, saya menjalankan Arch di VM
  Saya sendiri punya banyak masalah, tapi setidaknya Arch bukan salah satunya

  • Saya jadi penasaran apakah perubahan dotfiles juga punya staged rollout atau rollback
    Saya sedang mencari penyiapan dotfiles kelas enterprise yang bahkan mendukung metrik Prometheus dan health probe, dan ini terdengar persis seperti itu
  • Terima kasih juga karena mendukung distro lain dan sudah membagikannya
    Saya bahkan tidak pernah merasa membutuhkannya, tapi begitu melihat ini saya langsung merasa butuh
  • Penasaran apakah Anda juga pernah mencoba NixOS atau flakes
    Kalau pernah, saya ingin tahu juga bagaimana kesan Anda

• Menurut saya semua kontainer Docker seharusnya memang seperti ini sejak awal
  Menjalankan apt-get update pada tahap docker build itu nyaris seperti antipola

  • Meski begitu, jika memakai https://github.com/reproducible-containers/repro-sources-lis..., itu jadi pengecualian
    Saya pernah memakainya sendiri dan hasilnya bekerja cukup baik
  • Bagaimanapun juga, tidak ada yang benar-benar nyaman
    Kalau tidak update, isu keamanan yang sudah diketahui akan menumpuk di kontainer; kalau update, reproducibility-nya rusak
    Reproducibility memang keren dan punya manfaat keamanan, tapi setelah kontainer berumur lebih dari sebulan itu bisa terasa seperti target yang meleset, dan mungkin umur maksimum yang lebih masuk akal justru hitungan hari
  • Saya tahu itu antipola, tapi saya tidak tahu alternatifnya apa saat memang perlu memasang software
    Apakah maksudnya kita harus mengambil source code yang sudah ditag lalu mengompilasi semuanya sendiri dengan gcc?
  • Saya tidak setuju kalau itu dianggap aturan mutlak
    Kontainer yang reproducible memang bagus, tapi tidak selalu dibutuhkan, dan ada banyak kasus di mana menjalankan apt-get di dalam kontainer tanpa terlalu peduli pada reproducibility tetap sepenuhnya masuk akal
  • Ini juga makin sulit karena banyak distro menghapus versi lama dari repo begitu versi baru keluar
    Tentu saja masih ada cara mengambilnya dari archive

• Image yang reproducible sering terasa seperti fitur yang cuma memberi kepuasan emosional sehari-hari, tapi akan ada saat ketika itu benar-benar dibutuhkan
  Kami pernah punya dua image yang seharusnya identik tetapi di mesin berbeda menghasilkan perbedaan 3 byte pada timestamp, dan gara-gara itu kami membuang satu sore penuh untuk melakukan bisect ke arah yang sama sekali salah
  Tidak mencolok, tapi jelas kemenangan yang sangat berharga

  • Saya penasaran bagaimana perbedaan timestamp itu bisa sampai memicu gangguan sejak awal

• Sepertinya ada sesuatu yang bisa disisipkan untuk memberi tahu semua orang bahwa Anda memakai Arch di pipeline CI/CD
  Sekalian juga memberi tahu bahwa Anda ikut Crossfit tentunya

  • Ini mengingatkan saya pada sebuah koan
    Jika Anda bertemu vegan crossfitter yang juga pengguna Arch, apa hal pertama yang akan dia beri tahu kepada Anda?
  • Saya tidak pernah mengerti kenapa ada orang yang bangga dengan fakta bahwa mereka tidak memakai Slackware

• Informasi tentang Reproducible Builds bisa dilihat di sini
  https://reproducible-builds.org/
  Komunitas Bootstrappable Builds yang sangat terkait ada di sini
  https://bootstrappable.org/

• Saya penasaran apakah sistem operasi mutable yang dirancang dengan baik seperti Arch atau Alpine pada akhirnya bisa mengalahkan sistem seperti NixOS dalam jangka panjang
  Alasannya, skrip instalasi lebih ekspresif daripada bahasa konfigurasi deklaratif, dan biasanya juga tidak lebih bertele-tele

  • Kalau begitu sepertinya lebih baik pakai Guix saja
    Anda mendapat bahasa konfigurasi deklaratif, sekaligus bahasa pemrograman yang Turing-complete dan enak dipakai
  • Saya penasaran apa sebenarnya maksud strictly more powerful di sini

• Saya sudah membaca artikelnya dan terlihat cukup keren, tapi rasanya mereka mencampuradukkan Dockerfile dan docker image
  Kalau mereka membangun file tar image langsung dengan sesuatu seperti nix alih-alih Dockerfile, mungkin malah akan lebih mudah; memang agak niche, tapi tetap terasa lebih rapi

• Sedikit catatan kecil, tapi menurut saya istilah OCI Image lebih tepat dipakai
  Di podman juga berjalan tanpa masalah

  • Saya mungkin agak pemula di bagian komentar ini dan tidak mengikuti seluruh konteksnya, tapi ini terasa seperti poin yang membuka wawasan

• Hormat sebesar-besarnya untuk orang-orang yang benar-benar mewujudkan ini
  Waktu dan usaha yang dibutuhkan untuk menghasilkan satu headline seperti ini jauh lebih besar daripada yang dibayangkan kebanyakan orang

• Ini benar-benar topik lain, tapi di halaman itu ada sebuah animasi yang membuat hampir semua elemen halaman bergerak turun sekitar 20 piksel selama 1 detik
  Melihat layout berguncang di depan mata, saya kira itu pasti menghancurkan CLS, tetapi CLS aktualnya 0
  Jadi saya jadi bertanya-tanya apakah CLS itu metrik yang menyesatkan

  • Itu terjadi karena animasinya memang disengaja
    CLS menangani perubahan pada saat rendering awal, jadi meskipun tampak seperti pergeseran layout, itu bukan jenis yang dihitung sebagai CLS
  • Itu bukan layout shift
    Gerakan karena CSS transition adalah perubahan yang dapat diperkirakan, jadi tidak dihitung sebagai layout shift