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

• Reproduksibilitas bit-for-bit berarti jika dibangun dari sumber yang sama, hasilnya akan benar-benar identik hingga tingkat byte, kapan pun, di mana pun, dan oleh siapa pun proses build dilakukan
  • Ini hanya bisa dicapai jika semua elemen nondeterministik seperti timestamp, cache, dan metadata yang bisa sedikit berbeda tergantung lingkungan build dihilangkan
• Dengan membangun image Docker secara langsung lalu membandingkan apakah digest (hash)-nya sama dengan image distribusi resmi, siapa pun dapat memverifikasi secara independen bahwa image yang didistribusikan tidak dimodifikasi: ini penting dari sisi keamanan rantai pasok
• Image Docker Arch Linux kini disediakan dalam bentuk yang dapat direproduksi bit-for-bit, memperluas tonggak yang sama yang dicapai beberapa bulan lalu pada image WSL ke sisi Docker
• Image ini didistribusikan dengan repro tag khusus, dan untuk menjamin reproduksibilitas, kunci pacman harus dihapus dari image sehingga pacman tidak bisa langsung digunakan
  • Sampai solusi yang tepat tersedia, karena keterbatasan ini image tersebut untuk sementara disediakan sebagai tag terpisah
• Untuk memasang atau memperbarui paket di dalam kontainer, pertama-tama perlu membangun ulang keyring dengan menjalankan pacman-key --init && pacman-key --populate archlinux
  • Saat pertama kali dijalankan, ini bisa dilakukan secara interaktif, atau dijalankan dalam pernyataan RUN di Dockerfile yang menggunakan image ini sebagai basis
  • Di Distrobox, ini dapat 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"
• Reproduksibilitas bit-for-bit 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 base rootFS 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 di Dockerfile agar mengikutinya
• File cache bantu ldconfig, var/cache/ldconfig/aux-cache, yang menyebabkan nondeterminisme 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 masalah di mana 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 ditinjau lebih rinci di merge request diff repositori archlinux-docker
• Langkah berikutnya yang sedang dipertimbangkan adalah membangun rebuilder di server untuk image Docker, image WSL, dan image reproducible berikutnya, guna melakukan rebuild otomatis berkala, verifikasi reproduksibilitas, serta publikasi log build dan hasilnya

[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