491 / 736REPRO

Reproducible Firmware Build

Build firmware yang dapat direproduksi

Saat memperbarui dompet perangkat keras, Anda memasang sebuah berkas yang sudah jadi. Bagaimana memastikan bahwa berkas itu benar-benar berasal dari kode yang diterbitkan produsen? Reproducible Firmware Build memungkinkan pihak independen membangun ulang perangkat lunak yang sama dan membandingkan hasilnya. Dengan begitu, hubungan antara kode sumber terbuka dan pembaruan yang dibagikan dapat diperiksa.

Firmware adalah perangkat lunak yang menjalankan perangkat, misalnya dompet perangkat keras. Build-nya dapat direproduksi jika kode sumber, lingkungan yang ditentukan, dan petunjuk yang sama menghasilkan berkas yang telah ditetapkan dengan isi persis sama. Program yang hanya berperilaku sama belum cukup. Pemeriksaan membandingkan datanya sendiri; untuk rilis bertanda tangan, perlakuan terhadap tanda tangan juga harus jelas.

Produsen dapat menerbitkan kode yang bisa dibaca pemrogram. Namun, yang biasanya dipasang pada dompet adalah berkas jadi dalam bentuk yang diproses mesin, sering disebut biner. Proses build menghubungkan kedua bentuk ini. Pihak independen dapat mengulanginya lalu membandingkan hasilnya dengan rilis produsen. Pemeriksaan mencari kesamaan byte, yaitu satuan data, misalnya memakai hash kriptografis: sidik jari yang dihitung dari isi berkas. Klaim tersebut berlaku untuk keluaran yang ditentukan, seperti berkas firmware, bukan otomatis untuk semua berkas sementara dan log. [1] [4]

Bayangkan dua pengembang memeriksa satu pembaruan. Nama proyek saja tidak cukup: mereka membutuhkan commit yang sama, yakni revisi kode yang ditentukan secara tepat. Mereka juga perlu mengetahui versi pustaka pendukung dan compiler, alat yang mengubah kode menjadi bentuk mesin. Opsi alat tersebut, pengaturan lingkungan yang relevan, dan model dompet juga merupakan bagian dari prosedur. Informasi ini harus ditentukan sebelumnya atau dicatat saat build. Jika tidak, keduanya bisa bekerja dengan jujur tetapi menghasilkan berkas berbeda. [1] [2]

Perbedaan tidak selalu berarti seseorang mengubah perilaku program. Compiler dapat memasukkan jalur folder kerja ke dalam informasi untuk menelusuri kesalahan. Jika proyek disimpan di lokasi berbeda, berkas hasilnya pun bisa berbeda. Solusinya dapat berupa jalur yang ditetapkan atau cara yang didukung untuk menyeragamkan jalur. Aturan itu harus menjadi bagian prosedur yang sudah diketahui. Menghapus perbedaan yang belum dipahami setelah pemeriksaan gagal hanya agar hasilnya cocok justru menghilangkan makna verifikasi. [3]

Tanda tangan digital memungkinkan kita memeriksa apakah berkas cocok dengan tanda tangan yang dibuat memakai kunci terkait. Mengaitkan kunci itu dengan produsen merupakan bagian lain dari kepercayaan. Build yang dapat direproduksi menjawab pertanyaan berbeda: apakah berkas sesuai dengan kode sumber yang ditentukan? Kedua pemeriksaan saling melengkapi. Namun, pembaruan resmi dapat memuat data tanda tangan yang tidak ada pada build lokal. Membandingkan seluruh berkas tanpa memahami formatnya dapat menghasilkan perbedaan meskipun program dibangun dengan benar. [5]

Dokumentasi Trezor menjelaskan pemilihan versi dan model, proses build firmware, serta perbandingannya dengan berkas resmi. Karena hasil lokal tidak ditandatangani seperti rilis produsen, prosedur tersebut terlebih dahulu mengisi kolom tanda tangan yang ditentukan secara tepat dengan nol. Format lama juga berbeda pada header, bagian awal berkas yang memuat informasi tentangnya. Susunannya bergantung pada model dan versi, sehingga petunjuk untuk satu perangkat tidak boleh langsung diterapkan pada perangkat lain. Tanda tangan asli tetap diperiksa tersendiri; membandingkan salinan yang disesuaikan tidak menggantikan pemeriksaan itu. [5]

Pertama, pastikan bahwa yang dibandingkan menggunakan revisi kode, model, dan varian firmware yang sama. Berikutnya periksa alat, pustaka, dan transformasi berkas yang ditentukan. Simpan berkas asli beserta catatan perbedaannya. Penyebabnya bisa berupa kesalahan lingkungan atau petunjuk, tetapi bisa pula perubahan pada program yang didistribusikan. Ketidakcocokan sendiri belum menentukan sebab maupun pihak yang bertanggung jawab. Sebelum perbedaan dijelaskan dan pemeriksaan diulang, build tersebut belum layak disebut terverifikasi. [1] [4]

Jika kode yang dipublikasikan sudah memiliki cacat, setiap build ulang dapat menyalin cacat itu dengan sempurna. Compiler tidak tepercaya yang dipakai bersama juga dapat menambahkan perubahan berbahaya yang sama pada semua hasil. Menggunakannya kembali bukan berarti memeriksa alat itu secara independen. Komponen biner tertutup membatasi bagian yang dapat dibangun ulang dari kode yang tersedia. Kecocokan berkas di komputer juga tidak membuktikan bahwa dompet tertentu asli atau benar-benar menjalankan firmware tersebut. Memeriksa asal berkas merupakan bagian penting dari keamanan, bukan bukti lengkapnya. [6] [1]

Laporan “terverifikasi” baru berguna jika menjelaskan siapa yang memeriksa, revisi mana yang dibangun, untuk model apa, dan dengan prosedur apa. Laporan perlu menyebutkan berkas yang dibandingkan, fungsi hash, hasil, serta cara tepat menangani data tanda tangan. Orang lain kemudian dapat menelaah atau mengulang pekerjaan itu. Semakin banyak pihak independen yang melakukan build, semakin kecil ketergantungan pada satu penerbit. Meski begitu, kode, proses pembaruan, dan perangkatnya sendiri tetap perlu diperiksa. [2] [4]

Contoh · REPRO

Dua hasil sama dan satu hash berbeda

Dua pengembang membangun firmware dari revisi yang sama, untuk model yang sama, di lingkungan yang sama. Sidik jari SHA-256 kedua berkas cocok, tetapi sidik jari versi resmi bertanda tangan berbeda. Jika dokumentasi menentukan kolom tanda tangan secara tepat, mereka menerapkan transformasi yang ditentukan pada salinan dan membandingkannya lagi. Kecocokan itu berlaku untuk isi yang didefinisikan dengan cara tersebut. Tanda tangan asli masih harus diperiksa tersendiri; perbedaan lain yang belum dijelaskan tidak boleh sekadar dihapus.

Untuk gambaran yang lebih utuh, baca entri ini bersama Hardware Wallet, Private Key, Cold Storage, Secure Element. Entri ini juga dirujuk dari COLDCARD RNG Incident (2026).

01Apakah pengguna harus melakukan build firmware sendiri?

Anda tidak harus menjadi pemrogram untuk memahami hasil pemeriksaan. Namun, perhatikan apakah laporan independen menyebut versi, model, dan berkas yang dibandingkan secara spesifik. Hash yang cocok tidak membuktikan ketiadaan cacat: kode berbahaya atau compiler yang sama dapat menghasilkan berkas identik. Penilaian kode dan kepercayaan pada perangkat tetap merupakan persoalan tersendiri.

02Apakah hash berbeda pada pembaruan bertanda tangan berarti serangan?

Tidak otomatis. Berkas dapat memiliki data tanda tangan atau header berbeda yang memang sudah diperhitungkan prosedur. Versi, model, dan petunjuk yang tepat perlu diperiksa. Namun, perbedaan yang belum dijelaskan bukan verifikasi yang berhasil dan tidak boleh diakali dengan menghapus data sembarangan.

DOC · 001Reproducible Builds — DefinitionDokumentasi DOC · 002Reproducible Builds — Recording the environmentDokumentasi DOC · 003Reproducible Builds — Build pathsDokumentasi DOC · 004Reproducible Builds — Build infrastructure threatsDokumentasi DOC · 005Trezor — Reproducible build verificationDokumentasi DOC · 006Wheeler — Countering Trusting TrustSumber primer
Direvisi: Utamakan sumber · Bukan nasihat investasi