Debian harus menyediakan paket yang dapat direproduksi

 (lists.debian.org)
1 poin oleh GN⁺ 5 jam lalu | 2 komentar | Bagikan ke WhatsApp
  • Tim rilis Debian memutuskan di pertengahan siklus forky untuk mewajibkan penyediaan paket yang dapat direproduksi
  • Perangkat lunak migrasi memblokir paket baru yang tidak dapat direproduksi di reproduce.debian.net
  • Migrasi juga diblokir jika terjadi regresi reproduktibilitas pada paket yang sudah ada di testing
  • autopkgtest kini juga ditambahkan untuk dijalankan pada binNMU seperti pada unggahan source-full
  • Antrean CI membesar karena penambahan loong64 dan rebuild multi-arch, sehingga diperlukan kesabaran

Kewajiban reproduktibilitas paket Debian

  • Tim rilis Debian memutuskan pada titik tengah siklus rilis forky bahwa Debian harus menyediakan paket yang dapat direproduksi
  • Keputusan ini didorong oleh upaya dari proyek Reproducible Builds
  • Sejak kemarin, perangkat lunak migrasi diaktifkan untuk memblokir migrasi paket baru yang tidak dapat direproduksi di reproduce.debian.net
  • Migrasi juga akan diblokir jika terjadi regresi reproduktibilitas pada paket lama yang sudah ada di testing

Jaminan kualitas dan tanggung jawab pengunggah

  • Menjalankan autopkgtest untuk testing binNMU

    • Awal tahun ini, perangkat lunak migrasi ditambahkan kemampuan agar binNMU juga menjalankan autopkgtest, sama seperti unggahan source-full
    • Fitur ini mungkin tidak terlalu terkait langsung dengan sebagian besar pekerjaan maintainer, tetapi diperlakukan sebagai langkah tambahan untuk memperkuat jaminan kualitas

  • Penambahan arsitektur loong64 dan peningkatan antrean CI

    • Dua minggu lalu, arsitektur baru loong64 ditambahkan ke arsip
    • Debian hanya mengizinkan biner yang dibangun di buildd untuk dimigrasikan, dan karena persyaratan multi-arch, banyak paket harus dibangun ulang di semua arsitektur
    • Karena fitur binNMU yang ditambahkan sebelumnya, antrean CI saat ini cukup besar, dan tim rilis meminta sedikit kesabaran

  • Tindak lanjut setelah unggahan

    • Pengunggah paket sumber bertanggung jawab untuk memastikan bahwa paket terkait dapat dimigrasikan
    • Jika sebuah paket terblokir karena regresi autopkgtest pada dependensi uji balik dan dependensi itu perlu diperbarui, maka pengunggah harus mengajukan bug dengan tingkat keparahan RC yang sesuai

Bacaan terkait

2 komentar

 
GN⁺ 2 jam lalu
Komentar Hacker News

  • Ini pencapaian besar bagi Debian dan dunia perangkat lunak bebas
    Hanya saja butuh waktu cukup lama sampai kebutuhan ini dipahami. Bahkan ketika pada 2007 dikatakan di debian-devel bahwa ini diperlukan, tanggapannya adalah bahwa ini pemborosan waktu yang luar biasa, dan memang butuh pekerjaan besar dari banyak orang untuk sampai ke titik ini, tetapi itu sangat layak dilakukan

    • Sejak 2007, tidak ada bug atau serangan yang bisa dicegah oleh paket yang dapat direproduksi di Debian
      Menurut saya ungkapan “itu layak dilakukan” tidak tepat. Ini hanya makin menaikkan hambatan untuk berkontribusi ke Debian, dan saya sudah melihat banyak orang mengeluh bahwa berkontribusi ke Debian memang sulit. Dulu saya membelanya dengan alasan “butuh banyak verifikasi dan checks and balances agar paket-paket saling cocok”, tetapi ini terlihat seperti membuat segalanya lebih sulit tanpa alasan jelas dan manfaatnya kecil

  • Ada informasi lebih lanjut di https://wiki.debian.org/ReproducibleBuilds. Sebagiannya sudah lama, tetapi ada juga grafik yang menunjukkan jumlah paket yang dibangun di CI dan berapa banyak di antaranya yang memiliki build yang dapat direproduksi
    Warna oranye berarti FTBR, yaitu “gagal dibangun secara reproducible”. Saya tidak terlalu terbiasa membaca angka di grafik, tetapi saya perkirakan sekitar beberapa persen, kira-kira 4~5%

    • Buat saya yang muncul hanya ini:

      Forbidden

      You are not allowed to access this!
      Bahkan tag HTML-nya terlihat apa adanya :)
      Edit: saya juga menemukan halaman “I Challenge Thee” di arsip. Mungkin saya terblokir oleh langkah anti-bot? Kenapa???

  • Ini kabar baik. NetBSD sudah memiliki build yang sepenuhnya dapat direproduksi sejak 2017. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

    • Seperti juga tertulis di tautannya, NetBSD mencapainya dengan bantuan Debian. Kalau saya memahaminya dengan benar, itu bukan karena NetBSD bekerja lebih keras, melainkan karena masalahnya lebih mudah. Paketnya lebih sedikit dan perubahannya juga lebih jarang. Mereka bahkan masih memakai CVS, jadi kata “stabil” saja rasanya kurang menggambarkannya
      Sebagai referensi, sebagian besar paket Debian memang sudah dapat direproduksi. Yang belum, sekitar 5% paket, ditandai warna oranye di grafik ini: https://wiki.debian.org/ReproducibleBuilds
    • Sedikit membanggakan, stagex tahun lalu menjadi yang pertama mencapai build deterministik dan terisolasi berbasis bootstrap sumber penuh 100%, dan juga yang pertama mewajibkan beberapa reproduksi bertanda tangan pada setiap rilis, yang dijalankan oleh maintainer berbeda di hardware mereka masing-masing
      Debian memang sudah banyak berkembang, tetapi ketika Debian mengatakan reproducible, itu berarti mereka mengambil binary pihak ketiga untuk build mereka sendiri. Ketika kami mengatakan reproducible, maksudnya kami melakukan bootstrap seluruh rantai pasok perangkat lunak sampai ujungnya dari 100% source code
      Menurut saya perbedaan ini penting
      https://stagex.tools

  • Saya sangat senang dengan perubahan ini. Setelah membaca tentang serangan SolarWinds pada 2021 dan merasa terguncang, saya mulai terlibat dalam build yang dapat direproduksi. [1]
    Menurut saya, perkataan Magnus Ihse Bursie yang mengerjakan build reproducible untuk OpenJDK paling tepat: “Kalau Anda tanya saya, fakta bahwa compiler dan build tool pada suatu titik mulai menghasilkan output non-deterministik itu sendiri sudah merupakan bug sejak hari pertama.” [2]
    [1] https://www.linux.com/news/preventing-supply-chain-attacks-l...
    [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997

  • Saya penasaran kenapa ini jadi isu belakangan ini. Saya memakai Yocto untuk perangkat embedded, dan build yang dapat direproduksi nyaris bisa diterapkan begitu saja
    Manajemen paket Debian juga bisa diaktifkan dengan mudah, jadi rasanya bukankah semua ini sebenarnya sudah bisa dilakukan?

    • Saya penasaran maksud “kenapa ini jadi isu sekarang” itu apa
      Build yang dapat direproduksi adalah metode penting dalam komputasi industri. Bukan berarti Debian berada di garis depan bidang ini, melainkan lebih ke mengadopsi teknik yang berlaku luas di industri dan juga diterapkan pada sistem operasi lain yang dipakai untuk operasi jangka panjang serta penggunaan terkait keselamatan
      Tentu saja, berkat banyak kerja keras dari Yocto dan para pengembang Debian, ada banyak bagian yang kini memang sudah mudah dipakai
      Hal yang menarik adalah sekarang pengembang Debian mulai menerapkannya sebagai kebijakan yang lebih proaktif, menjadikannya bukan pilihan lagi melainkan norma bawaan
    • Saya penasaran apakah ada verifikasi aktif bahwa build tersebut benar-benar dapat direproduksi sampai level bit

  • Untuk amd64 forky
    reproduced: 97.02%
    good: 17586
    bad: 511
    fail: 30
    unknown: 0
    Statistik ini, statistik untuk arsitektur lain, dan alasan kenapa sesuatu tidak dapat direproduksi bisa dilihat di https://reproduce.debian.net

  • Saya selalu heran Debian yang memimpin ini dan bukan vendor komersial. Rasanya organisasi besar yang membayar RHEL dan Ubuntu mestinya sangat menuntut binary yang dapat diverifikasi

    • Jika pesaing bisa membuktikan bahwa paket mereka identik sampai level bit dengan yang didistribusikan organisasi besar, pesaing itu bisa ikut menikmati jaminan keamanan milik organisasi besar tersebut
      Ini sangat baik untuk perangkat lunak bebas, tetapi tidak terlalu baik bagi pihak yang ingin menjadi pemilik tunggal
    • Build yang dapat direproduksi ada untuk mengurangi kebutuhan akan kepercayaan, tetapi vendor komersial berbisnis menjual kepercayaan

  • Forbidden
    You don't have permission to access this resource.
    Apache Server at lists.debian.org Port 443
    :/
 
GN⁺ 5 jam lalu
Komentar Lobste.rs

  • Ini perubahan yang baik dari sisi keamanan. Proses transisinya mungkin merepotkan, tetapi pada akhirnya akan memberikan keandalan yang lebih tinggi bagi pengguna Debian Linux di seluruh dunia

  • Penasaran apa manfaat utama yang diberikannya untuk proyek seperti Debian. Apakah tujuannya agar semua orang bisa memiliki bukti bahwa tidak ada backdoor di biner?
    Maksudnya, apakah ini mengurangi tingkat kepercayaan yang harus diberikan kepada maintainer dan juga menurunkan risiko maintainer yang berniat jahat. Bukan berarti saya skeptis, hanya saja saya belum 100% paham kenapa Debian menghabiskan begitu banyak waktu untuk ini. Membuat build bisa direproduksi tampaknya cukup rumit dan butuh banyak kerja

    • Bukan hanya backdoor, tapi juga memungkinkan verifikasi apakah ada peringkasan atau modifikasi secara umum. Ini membantu keamanan dan juga memberi keuntungan bagi pengembangan proyek, karena paket yang dibangun secara reproducible dan dengan cara yang relatif tertutup lebih kecil kemungkinannya rusak secara aneh di lingkungan pengembang lain
      Intinya adalah menyediakan artefak bukti bahwa paket output benar-benar dibuat dari source code tertentu itu, bukan dari kumpulan source kedua yang disembunyikan. the reproducible-builds org has a bit of a 'why' which puts it better than i can
      Membuat build reproducible itu sangat sulit. Misalnya, timestamp di dalam pipeline kompilasi bisa membuat perbedaan, begitu juga metadata arsip yang dihasilkan. Semua hal seperti ini harus dihilangkan, dan dalam beberapa kasus yang diperlukan bukan patch pada paket itu sendiri, melainkan patch proyek hulu seperti CMake atau compiler Go. Dalam banyak kasus, dulu masalah seperti ini bahkan tidak pernah dipertimbangkan, jadi pekerjaannya harus mencakup seluruh build stack. Meski begitu, pekerjaan ini sudah berjalan sejak lama, jadi sebagian besar fondasi di lapisan bawah sudah selesai atau sedang sangat jauh progresnya
    • Saya tidak berpikir ini harus menjadi prioritas utama Debian, tetapi Debian memang tidak bergerak seperti itu. Orang-orang mengerjakan hal yang ingin mereka kerjakan, dan prioritas individu sering kali tidak terlalu selaras dengan prioritas yang masuk akal di tingkat proyek

  • Apakah reproducibility yang dimaksud Debian adalah konsep yang sama dengan yang dibicarakan di tempat seperti NixOS?

    • Tidak. NixOS is not reproducible adalah tulisan rujukan standar
    • Distro yang melacak reproducible builds sebagai sebuah proyek pada umumnya bergerak menuju tujuan yang sama. reproducible-builds.org melacak proyek-proyek yang secara aktif mengerjakan hal ini dalam pipeline packaging mereka
      NixOS juga sedang mengerjakan reproducible builds, dan kalau saya ingat benar, setidaknya ISO mereka 100% reproducible baik saat build maupun runtime. Tetapi reproducibility yang biasanya dibicarakan tentang NixOS bukanlah “reproducible builds” yang sedang dibahas di sini. Lihat tulisan foxboron yang ditautkan di komentar saudara dalam thread ini. Itu lebih dekat ke reproduktibilitas lingkungan, atau “build deterministik”, dan tetap bernilai, tetapi bukan itu yang sedang dibahas di sini

  • Untuk saat ini, ini terdengar seperti mekanisme ratchet. Apakah hal-hal yang belum pernah sekali pun berhasil dibangun secara reproducible masih tetap diperbolehkan?

    • Jika sebuah paket tidak bisa dibangun secara reproducible, paket itu tidak akan dimasukkan ke rilis Debian berikutnya. Artinya, paket yang “belum pernah sekali pun berhasil dibangun secara reproducible” mungkin masih bisa tetap ada di Debian unstable, tetapi mempertahankan paket di Debian unstable yang tidak akan pernah mencapai stable tidak dipandang sebagai hal yang baik. Meski begitu, setahu saya tidak ada aturan yang dipaksakan secara mekanis untuk itu