Cara Memverifikasi Unduhan dengan Checksum di Linux

Verifikasi unduhan dengan checksum dalam dua menit

Untuk memverifikasi unduhan dengan checksum, buat hash dari file yang Anda terima, lalu biarkan alat membandingkan hash tersebut dengan hash yang dicantumkan oleh penerbit. sha256sum menangani kedua bagian ini: secara mandiri, perintah tersebut menampilkan digest, sedangkan dengan -c, perintah tersebut membaca daftar digest dan melaporkan file mana yang cocok. Panduan ini menjalankan seluruh proses pada file yang Anda buat, lalu sengaja merusak file tersebut agar Anda dapat melihat kegagalannya secara langsung, bukan sekadar membacanya.

Ingat satu kalimat ini sepanjang panduan. Checksum memberi tahu apakah byte yang Anda miliki sama dengan byte yang menghasilkan digest tersebut, tetapi tidak memberi tahu siapa yang membuatnya. Pertanyaan kedua memerlukan tanda tangan dan key yang Anda percayai. Bagian terakhir panduan ini menunjukkan dengan tepat batas antara kedua hal tersebut.

Buat file untuk latihan

Gunakan direktori kerja sementara agar tidak ada perintah di sini yang memengaruhi bagian lain dari sistem. Semua perintah di bawah berasal dari GNU coreutils, yaitu kumpulan perintah dasar yang tersedia di setiap server Ubuntu atau Debian. Jadi, tidak ada yang perlu diinstal.

mkdir -p ~/checksum-demo
cd ~/checksum-demo
printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum payload.txt

Anda akan mendapatkan satu baris: 64 karakter heksadesimal, dua spasi, lalu nama file. Ke-64 karakter tersebut adalah digest file. Jalankan perintah itu lagi dan barisnya akan tetap sama karena hashing bersifat deterministik: input yang sama selalu menghasilkan output yang sama. Ubah satu karakter pada file, lalu jalankan kembali perintah tersebut. Digest tidak akan berubah sedikit saja. Hasilnya akan terlihat sama sekali berbeda karena perubahan satu bit input mengubah sekitar setengah bit output. Sifat inilah yang membuat string sepanjang 64 karakter dapat digunakan sebagai pengganti image berukuran 4 GB.

Simpan file SHA256SUMS, lalu periksa isinya

Digest yang ditampilkan di layar tidak berguna sehari kemudian. Tulis digest tersebut ke file dengan format yang digunakan oleh sha256sum, agar tool dapat membacanya kembali nanti.

sha256sum payload.txt > SHA256SUMS
cat SHA256SUMS
sha256sum -c SHA256SUMS

sha256sum -c membaca setiap baris dalam daftar, menghitung hash file yang namanya tercantum pada baris tersebut, lalu membandingkan kedua digest. Eksekusi yang berhasil menampilkan satu baris untuk setiap file:

payload.txt: OK

Periksa juga status keluar karena skrip membaca status tersebut, bukan teksnya. echo $? menampilkan 0 setelah eksekusi berhasil. Nama SHA256SUMS adalah konvensi, bukan aturan, tetapi distribusi dan sebagian besar halaman rilis menggunakannya. Gunakan nama tersebut agar orang berikutnya dapat mengetahui isi file tanpa membukanya.

Balik satu byte dan amati kegagalan pemeriksaan

Sekarang rusak file tersebut dengan sengaja. Perintah ini menulis satu byte pada offset 5 dan membiarkan bagian lainnya tetap sama, sehingga panjang dan nama file tetap dipertahankan.

printf 'X' | dd of=payload.txt bs=1 seek=5 conv=notrunc status=none
cat payload.txt
sha256sum -c SHA256SUMS

conv=notrunc adalah flag yang penting. Tanpa flag ini, dd akan memotong file pada posisi terakhir penulisan, sehingga Anda akan menguji jenis kerusakan yang jauh lebih jelas. Pemeriksaan sekarang menampilkan:

payload.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

echo $? menampilkan 1. FAILED berarti file telah dibaca dan digest-nya tidak cocok dengan digest dalam daftar. Kembalikan byte asli, lalu pastikan pemeriksaan kembali menghasilkan OK:

printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum -c SHA256SUMS

Itulah seluruh kebiasaan tersebut. Perbedaan satu byte, di mana pun letaknya dalam file, menghasilkan FAILED. Unduhan yang terhenti karena koneksi terputus, mirror yang menyediakan build kemarin, proxy yang mengubah file saat transit, atau disk yang mengembalikan blok rusak—semuanya akan muncul pada baris yang sama.

Saat daftar mencantumkan file yang tidak Anda unduh

File SHA256SUMS yang sebenarnya dari sebuah distribusi mencantumkan setiap image yang dirilis oleh proyek tersebut, sedangkan Anda hanya mengunduh salah satunya. Simulasikan situasi tersebut di sini.

printf 'a second file\n' > notes.txt
sha256sum payload.txt notes.txt > SHA256SUMS.all
rm notes.txt
sha256sum -c SHA256SUMS.all

payload.txt: OK
sha256sum: notes.txt: No such file or directory
notes.txt: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read

FAILED open or read adalah kegagalan yang berbeda dari FAILED, dan salah membedakan keduanya hanya membuang waktu. FAILED berarti byte-nya salah. FAILED open or read berarti sha256sum sama sekali tidak menemukan file tersebut, sehingga tidak ada yang dibandingkan. Pada pengunduhan nyata, penyebab yang biasanya terjadi adalah working directory, karena nama dalam daftar bersifat relatif terhadap direktori tempat Anda menjalankan perintah. Pindah ke direktori yang berisi file tersebut, lalu jalankan kembali perintahnya. Untuk memeriksa hanya file yang benar-benar Anda miliki, gunakan perintah berikut:

sha256sum --ignore-missing -c SHA256SUMS.all

Perintah tersebut menampilkan payload.txt: OK dan keluar dengan kode 0. Jika tidak ada satu pun nama yang tercantum ditemukan, --ignore-missing tidak akan berhasil secara diam-diam pada nol file. Perintah tersebut melaporkan no file was verified dan keluar dengan kode non-zero. Inilah perilaku yang diinginkan, karena hasil berhasil yang tidak memeriksa apa pun adalah kegagalan yang tidak akan pernah Anda sadari.

Publikasikan digest tanpa membacanya secara visual

Membandingkan 64 karakter heksadesimal secara visual adalah titik ketika kebiasaan ini benar-benar gagal. Orang memeriksa empat karakter pertama dan empat karakter terakhir, lalu menganggapnya cocok. Perbandingan itulah yang memang direncanakan oleh penyerang yang gigih. Biarkan tool yang melakukan perbandingan. Atur EXPECTED ke digest yang Anda salin dari penerbit, menggunakan EXPECTED= diikuti oleh nilai yang ditempel, lalu buat satu baris yang diharapkan oleh -c:

printf '%s  %s\n' "$EXPECTED" payload.txt > payload.sha256
cat payload.sha256
sha256sum -c payload.sha256

Terdapat dua spasi antara digest dan nama file. Karena itu, format string tersebut memuat dua spasi. Itulah format yang ditulis oleh sha256sum dan dibaca oleh -c. File yang hanya berisi digest bukan baris checksum. Pemeriksaan akan menolak seluruh file dengan no properly formatted checksum lines found, bukan menebak file yang Anda maksud. Beberapa proyek menerbitkan format bertanda BSD, yaitu SHA256 (payload.txt) = diikuti oleh digest. GNU coreutils menulis format tersebut dengan sha256sum --tag payload.txt dan membacanya kembali dengan -c. Jadi, kedua format tersebut dapat disimpan.

Jika pemeriksaan berperilaku tidak semestinya, periksa isi daftar itu sendiri dengan cat -A SHA256SUMS. Perintah tersebut menandai akhir setiap baris dengan $ dan menampilkan karakter yang biasanya tidak terlihat. Baris yang berakhir dengan ^M$ memperoleh carriage return dari editor Windows. GNU sha256sum mengabaikan karakter tambahan tersebut dan tetap mencetak OK. Jadi, daftar CRLF bukan penyebab pemeriksaan Anda gagal, meskipun tool di luar coreutils lebih ketat terhadapnya. Normalisasi salinan yang Anda simpan dengan tr -d '\r' < SHA256SUMS > SHA256SUMS.clean.

Apa yang dibuktikan checksum, dan apa yang tidak?

Checksum membuktikan satu hal: byte pada disk Anda adalah byte yang menghasilkan digest yang dipublikasikan. Ini sepenuhnya mencakup kerusakan yang tidak disengaja. Ini juga mencakup penyerang yang ceroboh, yang mengganti file pada mirror unduhan tetapi tidak dapat mengubah halaman tempat digest dipublikasikan.

Checksum tidak membuktikan siapa pembuatnya. Digest adalah fakta tentang byte, bukan fakta tentang manusia. Jika satu halaman menyediakan file dan digest sekaligus, pihak yang dapat mengubah salah satunya juga dapat mengubah yang lain. Dalam kondisi itu, baris OK hanya berarti mirror tersebut cocok dengan dirinya sendiri. Karena itu, gunakan aturan berikut agar pemeriksaan checksum bermanfaat: ambil digest dari tempat yang berbeda dengan tempat Anda mengambil file. Misalnya, ambil digest dari domain milik proyek melalui TLS (transport layer security), sementara image diambil dari mirror atau torrent. Dengan demikian, penyerang harus menguasai dua tempat, bukan satu. Checksum juga tidak memberi tahu apa yang akan dilakukan byte yang telah diverifikasi setelah Anda menjalankannya. Ini adalah pertanyaan terpisah yang layak diajukan untuk segala sesuatu yang dieksekusi atas nama Anda, mulai dari skrip instalasi hingga plugin dsh yang berjalan dengan izin agent Anda.

Algoritmanya juga penting. SHA-256 (secure hash algorithm, output 256-bit) tidak memiliki collision yang diketahui hingga August 2026. Karena itu, publisher menggunakannya. MD5 (message digest 5) dan SHA-1 tidak lagi memadai: dua file berbeda dengan digest MD5 yang sama telah dapat dibuat sejak 2004, dan collision SHA-1 dengan chosen-prefix telah dipublikasikan pada 2020. File MD5SUMS tetap dapat mendeteksi unduhan yang terpotong karena kerusakan acak bukan collision yang dibuat secara sengaja. Namun, file tersebut tidak dapat menghentikan orang yang berusaha menipu Anda. Jika sebuah proyek memublikasikan keduanya, gunakan baris SHA-256.

Ketika tanda tangan mengambil alih

Tanda tangan menutup celah yang masih terbuka pada digest. Publisher menandatangani file digest dengan private key, lalu Anda memverifikasinya menggunakan public key mereka: gpg --verify SHA256SUMS.asc SHA256SUMS. Jika verifikasi berhasil, daftar digest tersebut berasal dari pihak yang memegang key itu. Selanjutnya, sha256sum -c SHA256SUMS menghubungkan file di disk Anda dengan daftar tersebut, sehingga rantainya berjalan dari key hingga ke byte.

Titik lemahnya berpindah ke key. Jika Anda mengambil key dari halaman yang sama dengan halaman penyedia file, Anda menyerahkan kedua komponen tersebut kepada attacker. GnuPG menyatakan hal ini dengan jelas, dan verifikasi pertama menampilkan Good signature bersama WARNING: This key is not certified with a trusted signature!. Good signature berarti perhitungannya valid. Hal itu tidak berarti key tersebut milik project yang Anda maksud. Dapatkan fingerprint dari sumber kedua, seperti dokumentasi project pada domain lain atau package distribusi yang sudah menyertakan key tersebut, lalu bandingkan fingerprint lengkap, bukan hanya delapan karakter terakhir. Ini adalah kehati-hatian yang sama seperti pada private key SSH, karena alasannya sama: key menentukan kepercayaan, dan semua komponen setelahnya mewarisi kepercayaan tersebut.

Reproducible build membawa gagasan ini selangkah lebih jauh. Digest yang dipublikasikan tetap mengikat Anda pada binary yang dibuat oleh satu mesin. Jika build sebuah project bersifat reproducible, siapa pun dapat mengompilasi source yang sama dan memperoleh output yang identik hingga ke byte, sehingga builder independen dapat mengonfirmasi digest yang dipublikasikan tanpa meminta Anda mempercayai satu server. Hal ini semakin penting setiap tahun karena semakin banyak code dikirim melalui pipeline otomatis dan patch yang ditulis oleh mesin. Menentukan hal yang boleh Anda masukkan ke dalam build adalah pertanyaan kebijakan, dan kebijakan open source untuk code berbantuan AI menangani supply chain yang sama dari sisi lainnya.

Manajer paket Anda sudah melakukan ini

Di Debian dan Ubuntu, apt menjalankan rangkaian ini pada setiap instalasi tanpa diminta. Indeks paket memuat digest SHA-256 untuk setiap file .deb. File Release memuat digest file indeks tersebut, dan InRelease memuat tanda tangan atas Release, yang diverifikasi menggunakan kunci dalam /usr/share/keyrings dan /etc/apt/trusted.gpg.d. Jika rantai ini terputus, apt akan memberi tahu Anda: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY jika kunci repositori pihak ketiga tidak ada, atau Hash Sum mismatch jika indeks yang diambil tidak cocok dengan Release yang ditandatangani. Biasanya, hal ini berarti caching proxy menyajikan file lama atau Anda mengakses mirror saat proses sinkronisasi sedang berlangsung.

Itulah standar yang perlu digunakan saat halaman utama suatu proyek meminta Anda menyalurkan skrip dari curl langsung ke shell. Tidak ada yang memverifikasi byte tersebut, dan Anda tidak pernah melihat isinya. Server juga dapat mengembalikan satu isi kepada skrip dan isi lain kepada browser, sementara Anda tidak memiliki salinan untuk diperiksa setelahnya. Unduh skrip ke file dengan curl -fsSL <url> -o install.sh, hitung hash-nya, baca menggunakan less, lalu jalankan hanya setelah itu. Kebiasaan ini hanya memerlukan sekitar dua puluh detik. Kebiasaan yang sama layak diterapkan pada VPS baru dalam sepuluh menit pertama, sebelum apa pun diinstal pada server.

Simpan daftar digest untuk setiap instalasi manual

Paket yang diinstal oleh apt akan tercatat. Binary yang Anda salin ke /usr/local/bin tidak tercatat, dan tidak ada komponen di sistem yang memantaunya. Daftar digest mengubah kondisi tersebut menjadi sesuatu yang dapat Anda periksa sesuai kebutuhan:

printf 'a second file\n' > notes.txt
sha256sum *.txt > inventory.sha256
sha256sum -c --quiet inventory.sha256

--quiet tidak mencetak apa pun jika semua file cocok, dan hanya mencetak baris yang gagal jika ada file yang tidak cocok. Jadi, tidak adanya output berarti pemeriksaan berhasil, sedangkan echo $? mengonfirmasinya dengan 0. Gunakan bentuk ini dalam scheduled job. --status melangkah lebih jauh dengan sama sekali tidak mencetak output, sehingga yang tersisa hanya exit status. Terapkan pola yang sama pada file sebenarnya dengan sha256sum /usr/local/bin/* > ~/local-bin.sha256 untuk membuat baseline. Path disimpan dalam daftar persis seperti saat Anda mengetikkannya, sehingga absolute path membuat pemeriksaan dapat dijalankan dari direktori mana pun.

Pahami dengan jelas nilai baseline tersebut. Baseline mendeteksi file yang berubah. Baseline tidak mendeteksi penyerang yang sudah memiliki akses root, karena penyerang itu dapat menulis ulang inventory.sha256 semudah menulis ulang binary tersebut. Simpan daftar di luar mesin jika Anda ingin daftar itu tetap bermakna. Hal ini merupakan bagian dari pertanyaan yang lebih luas tentang seberapa besar VPS yang sebenarnya Anda percayai dan siapa lagi yang dapat mengakses disk di bawahnya.

FAQ

Apakah checksum yang cocok berarti unduhan aman?

Tidak. Artinya, byte yang Anda miliki cocok dengan digest yang menjadi pembanding. Jika penyerang mengendalikan halaman yang menerbitkan digest tersebut, mereka dapat menerbitkan digest untuk file mereka sendiri dan pemeriksaan Anda akan mencetak OK. Kecocokan hanya menyatakan konsistensi. Pernyataan keamanan memerlukan tanda tangan yang diverifikasi terhadap kunci yang Anda peroleh dari sumber berbeda. Setelah itu, digest tersebut mewarisi kepercayaan dari kunci itu.

Mengapa sha256sum -c mencetak FAILED open or read?

Karena perintah tersebut tidak pernah membaca file. Baris terpisah tepat di atasnya menyatakan No such file or directory beserta nama file yang dicari. Nama file di dalam file SHA256SUMS bersifat relatif terhadap direktori tempat Anda menjalankan perintah. Karena itu, pindah ke direktori yang berisi unduhan, lalu jalankan kembali perintah tersebut. Jika daftar itu juga mencantumkan file yang tidak Anda unduh, tambahkan --ignore-missing. FAILED biasa tanpa open or read menunjukkan situasi sebaliknya: file telah dibaca, tetapi digest-nya tidak cocok.

Apakah MD5 cukup untuk memverifikasi unduhan?

Untuk kerusakan yang tidak disengaja, ya. Transfer yang terpotong atau blok disk yang rusak tidak akan menghasilkan digest MD5 yang cocok secara kebetulan. Untuk menghadapi penyerang, tidak. Dua file berbeda dengan digest MD5 yang sama telah dapat dibuat sejak 2004, dan SHA-1 mengalami chosen-prefix collision pada 2020. Gunakan baris SHA-256 jika proyek menerbitkan keduanya. Anggap proyek yang hanya menggunakan MD5 sebagai tanda bahwa proses rilisnya sudah lama.

Apa perbedaan antara sha256sum -c dan gpg --verify?

sha256sum -c membuktikan bahwa file cocok dengan suatu digest. gpg --verify membuktikan bahwa file digest ditandatangani oleh pemegang private key tertentu. Keduanya menjawab pertanyaan yang berbeda. Karena itu, jalankan keduanya jika proyek menyediakan keduanya. Tanda tangan membuat daftar digest dapat dipercaya, lalu daftar digest membuat file yang diunduh dapat dipercaya.

Bagaimana cara memeriksa satu file berdasarkan digest yang dicetak pada halaman web?

Jangan membandingkan karakter tersebut dengan melihatnya secara manual. Simpan digest dan nama file dalam satu baris, dengan pemisah dua spasi. Kemudian, jalankan sha256sum -c terhadap file tersebut dan periksa OK atau FAILED yang dicetaknya. Membuat baris tersebut dengan printf '%s %s\n' mencegah kesalahan format yang menyebabkan sha256sum menolak file dengan no properly formatted checksum lines found.