วิธีตรวจสอบความถูกต้องของไฟล์ด้วย checksum บน Linux

ตรวจสอบไฟล์ที่ดาวน์โหลดด้วย checksum ภายใน 2 นาที

การตรวจสอบไฟล์ที่ดาวน์โหลดด้วย checksum ทำได้โดยการสร้าง hash ของไฟล์ที่คุณได้รับ แล้วให้เครื่องมือเปรียบเทียบค่า hash นั้นกับค่าที่ผู้เผยแพร่ระบุไว้ sha256sum สามารถทำงานได้ทั้งสองส่วน คือสร้างค่า digest ออกมาโดยตรง หรือใช้ร่วมกับ -c เพื่ออ่านรายการค่า digest และรายงานว่าไฟล์ใดบ้างที่ตรงกัน คู่มือนี้จะให้คุณทดลองทำตามขั้นตอนทั้งหมดกับไฟล์ที่คุณสร้างขึ้นเอง จากนั้นจะทำให้ไฟล์นั้นเสียหายโดยเจตนา เพื่อให้คุณเห็นความล้มเหลวที่เกิดขึ้นจริงแทนที่จะเพียงแค่อ่านคำอธิบาย

โปรดจำประโยคนี้ไว้ตลอดการใช้งาน: checksum บอกคุณได้เพียงว่าไบต์ที่คุณถืออยู่ในมือคือไบต์ชุดเดียวกับที่สร้างค่า digest นั้นขึ้นมา แต่ไม่ได้บอกอะไรเลยว่าใครเป็นผู้สร้างไบต์เหล่านั้น คำถามที่สองนั้นจำเป็นต้องใช้ลายเซ็นดิจิทัลและกุญแจที่คุณเชื่อถือได้ ส่วนสุดท้ายของคู่มือนี้จะแสดงให้เห็นชัดเจนว่าขอบเขตระหว่างทั้งสองสิ่งนี้อยู่ที่ใด

สร้างไฟล์เพื่อทดสอบ

ให้ทำงานในไดเรกทอรีชั่วคราวเพื่อไม่ให้ส่งผลกระทบต่อส่วนอื่นของระบบ คำสั่งทั้งหมดด้านล่างมาจาก GNU coreutils ซึ่งเป็นชุดคำสั่งพื้นฐานที่มีอยู่บนเซิร์ฟเวอร์ Ubuntu หรือ Debian ทุกเครื่อง จึงไม่จำเป็นต้องติดตั้งซอฟต์แวร์เพิ่มเติม

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

คุณจะได้รับข้อมูลหนึ่งบรรทัด ประกอบด้วยอักขระเลขฐานสิบหก 64 ตัว ตามด้วยช่องว่างสองช่อง และชื่อไฟล์ อักขระ 64 ตัวนั้นคือค่า digest ของไฟล์ หากคุณรันคำสั่งเดิมอีกครั้ง ผลลัพธ์ที่ได้จะเหมือนเดิมทุกประการ เนื่องจากการทำ hashing เป็นกระบวนการที่กำหนดผลลัพธ์ได้แน่นอน (deterministic): ข้อมูลนำเข้าชุดเดิมจะให้ผลลัพธ์เดิมเสมอ หากคุณแก้ไขอักขระเพียงตัวเดียวในไฟล์แล้วรันคำสั่งอีกครั้ง ค่า digest จะไม่เปลี่ยนไปเพียงเล็กน้อย แต่มันจะดูแตกต่างไปจากเดิมอย่างสิ้นเชิง เพราะการเปลี่ยนบิตข้อมูลนำเข้าเพียงบิตเดียวจะส่งผลให้บิตของผลลัพธ์เปลี่ยนไปประมาณครึ่งหนึ่ง คุณสมบัตินี้เองที่ทำให้สตริงความยาว 64 อักขระสามารถใช้เป็นตัวแทนของไฟล์อิมเมจขนาด 4 GB ได้อย่างมีประสิทธิภาพ

บันทึกไฟล์ SHA256SUMS แล้วตรวจสอบ

ค่า digest ที่แสดงบนหน้าจอไม่มีประโยชน์เมื่อเวลาผ่านไปหนึ่งวัน ให้เขียนค่าดังกล่าวลงในไฟล์ตามรูปแบบที่ sha256sum สร้างขึ้น เพื่อให้เครื่องมือสามารถอ่านกลับมาตรวจสอบได้ในภายหลัง

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

sha256sum -c จะอ่านแต่ละบรรทัดในรายการ ทำการ hash ไฟล์ที่ระบุในบรรทัดนั้น แล้วเปรียบเทียบค่า digest ทั้งสอง หากการทำงานปกติ โปรแกรมจะแสดงผลหนึ่งบรรทัดต่อหนึ่งไฟล์:

payload.txt: OK

ควรตรวจสอบ exit status ด้วย เนื่องจากสคริปต์จะอ่านค่านี้แทนการอ่านข้อความ echo $? จะแสดงค่า 0 หลังจากทำงานเสร็จสิ้นโดยไม่มีข้อผิดพลาด ชื่อไฟล์ SHA256SUMS เป็นเพียงข้อตกลงร่วมกันไม่ใช่กฎบังคับ แต่เนื่องจากดิสทริบิวชันและหน้าดาวน์โหลดส่วนใหญ่ใช้ชื่อนี้ คุณจึงควรใช้ชื่อนี้เช่นกัน เพื่อให้ผู้อื่นทราบว่าไฟล์นี้เก็บข้อมูลอะไรโดยไม่ต้องเปิดอ่าน

พลิกหนึ่งไบต์แล้วดูการตรวจสอบล้มเหลว

ตอนนี้ให้ลองทำให้ไฟล์เสียหายโดยเจตนา คำสั่งนี้จะเขียนข้อมูลหนึ่งไบต์ที่ออฟเซ็ต 5 โดยไม่กระทบส่วนอื่นของไฟล์ ทำให้ไฟล์ยังคงมีความยาวและชื่อเดิม

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

conv=notrunc คือแฟล็กที่สำคัญ หากไม่มีแฟล็กนี้ dd จะตัดไฟล์ทิ้ง ณ จุดที่หยุดเขียน ซึ่งจะทำให้คุณกำลังทดสอบความเสียหายที่ชัดเจนเกินไป ขณะนี้การตรวจสอบจะแสดงผลดังนี้:

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

echo $? จะแสดงผลเป็น 1 โดย FAILED หมายความว่าระบบอ่านไฟล์แล้วพบว่าค่า digest ไม่ตรงกับรายการที่ระบุไว้ ให้คืนค่าไบต์เดิมกลับไปแล้วยืนยันว่าการตรวจสอบกลับมาเป็น OK:

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

นี่คือขั้นตอนทั้งหมดของนิสัยนี้ ความแตกต่างเพียงหนึ่งไบต์ไม่ว่าจะอยู่ที่ใดในไฟล์จะทำให้เกิด FAILED ไม่ว่าจะเป็นการดาวน์โหลดที่ถูกตัดตอนจากการเชื่อมต่อที่หลุด, มิเรอร์ที่ให้บริการ build ของเมื่อวาน, พร็อกซีที่เขียนไฟล์ใหม่ระหว่างทาง หรือดิสก์ที่ส่งคืน bad block ทั้งหมดนี้จะนำไปสู่ผลลัพธ์ในบรรทัดเดียวกันนี้ทั้งสิ้น

เมื่อรายการระบุชื่อไฟล์ที่คุณไม่ได้ดาวน์โหลด

ไฟล์ SHA256SUMS ที่แท้จริงจาก distribution จะระบุรายการอิมเมจทั้งหมดที่โปรเจกต์ปล่อยออกมา และคุณได้ดาวน์โหลดมาเพียงไฟล์เดียว ให้จำลองสถานการณ์ดังกล่าวที่นี่

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 เป็นความล้มเหลวที่ต่างจาก FAILED และการสับสนระหว่างสองสิ่งนี้ทำให้เสียเวลา FAILED หมายความว่าข้อมูลไบต์ไม่ถูกต้อง ส่วน FAILED open or read หมายความว่า sha256sum ไม่ได้รับไฟล์เลย จึงไม่มีการเปรียบเทียบเกิดขึ้น ในการดาวน์โหลดจริง สาเหตุทั่วไปคือ working directory เนื่องจากชื่อในรายการเป็นแบบ relative เทียบกับตำแหน่งที่คุณรันคำสั่ง ให้เปลี่ยน directory ไปยังตำแหน่งที่เก็บไฟล์แล้วรันคำสั่งอีกครั้ง หากต้องการตรวจสอบเฉพาะสิ่งที่คุณมีอยู่จริง ให้ระบุเจาะจงดังนี้:

sha256sum --ignore-missing -c SHA256SUMS.all

คำสั่งดังกล่าวจะแสดง payload.txt: OK และจบการทำงานด้วยสถานะ 0 หากไม่มีชื่อใดในรายการปรากฏอยู่ --ignore-missing จะไม่ทำงานสำเร็จแบบเงียบๆ กับไฟล์จำนวนศูนย์ไฟล์ แต่จะรายงานว่า no file was verified และจบการทำงานด้วยสถานะที่ไม่ใช่ศูนย์ ซึ่งเป็นพฤติกรรมที่คุณต้องการ เพราะการตรวจสอบที่ผ่านโดยไม่ได้ตรวจสอบอะไรเลยคือความล้มเหลวที่คุณจะไม่มีวันสังเกตเห็น

วางค่า digest ที่เผยแพร่โดยไม่ต้องใช้สายตาตรวจสอบ

การเปรียบเทียบอักขระเลขฐานสิบหก 64 ตัวด้วยสายตาเป็นจุดที่ทำให้พฤติกรรมนี้ล้มเหลว ผู้คนมักตรวจสอบเพียง 4 ตัวแรกและ 4 ตัวสุดท้ายแล้วสรุปว่าตรงกัน ซึ่งนั่นคือจุดที่ผู้โจมตีที่มุ่งมั่นวางแผนไว้ให้คุณทำ ปล่อยให้เครื่องมือเป็นผู้เปรียบเทียบแทน กำหนดค่า EXPECTED ให้เป็น digest ที่คุณคัดลอกมาจากผู้เผยแพร่ โดยใช้ EXPECTED= ตามด้วยค่าที่วางลงไป จากนั้นสร้างบรรทัดเดียวที่ -c คาดหวัง:

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

มีช่องว่างสองช่องคั่นระหว่าง digest และชื่อไฟล์ ซึ่งเป็นเหตุผลว่าทำไมรูปแบบสตริงจึงมีช่องว่างสองช่อง นั่นคือรูปแบบที่ sha256sum เขียนและรูปแบบที่ -c อ่าน ไฟล์ที่เก็บเฉพาะ digest เพียงอย่างเดียวไม่ใช่บรรทัด checksum ดังนั้นการตรวจสอบจะปฏิเสธทั้งไฟล์ด้วย no properly formatted checksum lines found แทนที่จะเดาว่าคุณหมายถึงไฟล์ใด บางโครงการเผยแพร่ในรูปแบบ BSD tagged แทน โดยใช้ SHA256 (payload.txt) = ตามด้วย digest ซึ่ง GNU coreutils จะเขียนในรูปแบบนั้นด้วย sha256sum --tag payload.txt และอ่านกลับด้วย -c ดังนั้นจึงสามารถบันทึกได้ทั้งสองรูปแบบ

เมื่อการตรวจสอบทำงานผิดปกติ ให้ดูรายการนั้นด้วย cat -A SHA256SUMS ซึ่งจะทำเครื่องหมายท้ายทุกบรรทัดด้วย $ และแสดงอักขระที่คุณไม่สามารถมองเห็นได้ตามปกติ บรรทัดที่ลงท้ายด้วย ^M$ แสดงว่าได้รับ carriage return มาจากโปรแกรมแก้ไขข้อความบน Windows ตัว GNU sha256sum จะเพิกเฉยต่ออักขระส่วนเกินนั้นและยังคงพิมพ์ OK ออกมา ดังนั้นรายการที่เป็น CRLF จึงไม่ใช่สาเหตุที่ทำให้การตรวจสอบของคุณล้มเหลว แม้ว่าเครื่องมือภายนอก coreutils จะไม่ยอมรับรูปแบบดังกล่าวเท่าใดนัก ให้ปรับรูปแบบสำเนาที่คุณเก็บไว้ให้เป็นมาตรฐานด้วย tr -d '\r' < SHA256SUMS > SHA256SUMS.clean

Checksum พิสูจน์อะไรได้บ้าง และพิสูจน์อะไรไม่ได้

Checksum พิสูจน์สิ่งเดียวคือ ข้อมูลไบต์บนดิสก์ของคุณเป็นชุดเดียวกับที่สร้างค่า digest ที่ประกาศไว้ ซึ่งครอบคลุมถึงความเสียหายที่เกิดขึ้นโดยอุบัติเหตุทั้งหมด นอกจากนี้ยังครอบคลุมถึงกรณีผู้โจมตีที่ประมาทซึ่งสลับไฟล์บน mirror สำหรับดาวน์โหลด แต่ไม่สามารถเข้าถึงหน้าเว็บที่ประกาศค่า digest นั้นได้

มันไม่ได้พิสูจน์อะไรเกี่ยวกับความเป็นเจ้าของผลงาน ค่า digest เป็นข้อเท็จจริงเกี่ยวกับข้อมูลไบต์ ไม่ใช่ข้อเท็จจริงเกี่ยวกับตัวบุคคล หากหน้าเว็บหนึ่งให้บริการทั้งไฟล์และค่า digest ผู้ที่สามารถแก้ไขอย่างใดอย่างหนึ่งก็ย่อมแก้ไขอีกอย่างได้เช่นกัน และบรรทัด OK ของคุณจะมีความหมายเพียงว่า mirror นั้นสอดคล้องกับตัวเองเท่านั้น ดังนั้นนี่คือกฎที่ทำให้การรัน checksum มีประโยชน์: ให้รับค่า digest มาจากแหล่งอื่นที่ไม่ใช่แหล่งเดียวกับที่คุณรับไฟล์มา ตัวอย่างเช่น รับจากโดเมนของโครงการโดยตรงผ่าน TLS (transport layer security) ในขณะที่ไฟล์ image มาจาก mirror หรือ torrent ตอนนี้ผู้โจมตีจำเป็นต้องควบคุมแหล่งข้อมูลสองแห่งแทนที่จะเป็นแห่งเดียว

อัลกอริทึมก็มีความสำคัญเช่นกัน SHA-256 (secure hash algorithm, 256-bit output) ยังไม่มีการค้นพบการชนกันของข้อมูล (collision) ณ เดือนสิงหาคม 2026 ซึ่งเป็นเหตุผลที่ผู้เผยแพร่เลือกใช้ ส่วน MD5 (message digest 5) และ SHA-1 นั้นไม่สามารถใช้งานได้แล้ว: ไฟล์สองไฟล์ที่ต่างกันแต่มีค่า MD5 digest เดียวกันสามารถสร้างขึ้นได้ตั้งแต่ปี 2004 และมีการเผยแพร่การโจมตีแบบ chosen-prefix collision ของ SHA-1 ในปี 2020 ไฟล์ MD5SUMS ยังคงใช้ตรวจสอบการดาวน์โหลดที่ไม่สมบูรณ์ได้ เพราะความเสียหายแบบสุ่มไม่ใช่การชนกันของข้อมูลที่ถูกสร้างขึ้นอย่างจงใจ แต่มันไม่สามารถหยุดผู้ที่พยายามหลอกลวงคุณได้ เมื่อโครงการเผยแพร่ทั้งสองค่า ให้เลือกใช้บรรทัด SHA-256 เสมอ

เมื่อลายเซ็นเข้ามามีบทบาท

ลายเซ็นช่วยปิดช่องว่างที่ digest ทิ้งไว้ ผู้เผยแพร่จะเซ็นชื่อกำกับไฟล์ digest ด้วย private key และคุณจะตรวจสอบด้วย public key ของพวกเขา: gpg --verify SHA256SUMS.asc SHA256SUMS หากการตรวจสอบผ่าน แสดงว่ารายการ digest นั้นมาจากผู้ที่ถือครองกุญแจดังกล่าว จากนั้น sha256sum -c SHA256SUMS จะเชื่อมโยงไฟล์บนดิสก์ของคุณเข้ากับรายการนั้น ทำให้เกิดห่วงโซ่ความน่าเชื่อถือตั้งแต่กุญแจไปจนถึงระดับไบต์ของไฟล์

จุดอ่อนจะย้ายไปอยู่ที่ตัวกุญแจ การดึงกุญแจจากหน้าเว็บเดียวกับที่ให้ดาวน์โหลดไฟล์จะเปิดโอกาสให้ผู้โจมตีเข้าถึงทั้งสองส่วนได้ GnuPG ระบุเรื่องนี้ไว้อย่างชัดเจน โดยการตรวจสอบครั้งแรกจะแสดง Good signature พร้อมกับ WARNING: This key is not certified with a trusted signature! ซึ่ง Good signature หมายความว่าการคำนวณทางคณิตศาสตร์นั้นถูกต้อง แต่มันไม่ได้หมายความว่ากุญแจนั้นเป็นของโครงการที่คุณต้องการจริงๆ คุณควรนำ fingerprint มาจากแหล่งที่สอง เช่น เอกสารของโครงการบนโดเมนอื่น หรือแพ็กเกจของ distribution ที่บรรจุกุญแจนั้นมาอยู่แล้ว และให้เปรียบเทียบ fingerprint แบบเต็มแทนที่จะดูเพียงแค่ 8 ตัวอักษรสุดท้าย นี่คือ ความระมัดระวังระดับเดียวกับที่ SSH private key ควรได้รับ ด้วยเหตุผลเดียวกัน คือกุญแจคือการตัดสินใจเรื่องความเชื่อถือ และทุกสิ่งที่อยู่ถัดไปจะได้รับผลจากความเชื่อถือนั้น

กระบวนการ reproducible builds ยกระดับแนวคิดนี้ไปอีกขั้น digest ที่เผยแพร่อยู่ยังคงผูกคุณไว้กับไบนารีที่สร้างจากเครื่องเดียว เมื่อการ build ของโครงการสามารถทำซ้ำได้ (reproducible) ใครก็ตามสามารถคอมไพล์ซอร์สโค้ดเดียวกันและได้ผลลัพธ์ที่เหมือนกันทุกไบต์ ดังนั้นผู้สร้างอิสระรายอื่นจึงสามารถยืนยัน digest ที่เผยแพร่ได้ แทนที่จะให้คุณเชื่อถือเซิร์ฟเวอร์เพียงเครื่องเดียว สิ่งนี้มีความสำคัญมากขึ้นทุกปี เนื่องจากโค้ดจำนวนมากถูกส่งผ่านท่อส่งอัตโนมัติและแพตช์ที่เขียนโดยเครื่องจักร การตัดสินใจว่าจะยอมรับสิ่งใดเข้าสู่กระบวนการ build เป็นเรื่องของนโยบาย และ นโยบายโอเพนซอร์สสำหรับโค้ดที่ช่วยโดย AI ก็ทำงานบนห่วงโซ่อุปทานเดียวกันจากอีกด้านหนึ่ง

ตัวจัดการแพ็กเกจของคุณทำหน้าที่นี้ให้คุณอยู่แล้ว

บน Debian และ Ubuntu ตัว apt จะรันกระบวนการนี้ทุกครั้งที่มีการติดตั้งโดยที่คุณไม่ต้องร้องขอ ดัชนีแพ็กเกจจะมีค่า SHA-256 digest สำหรับไฟล์ .deb แต่ละไฟล์ ส่วนไฟล์ Release จะเก็บค่า digest ของไฟล์ดัชนีเหล่านั้น และ InRelease จะเก็บลายเซ็นที่กำกับ Release ซึ่งจะถูกตรวจสอบเทียบกับคีย์ใน /usr/share/keyrings และ /etc/apt/trusted.gpg.d เมื่อห่วงโซ่การตรวจสอบนี้ขาดตอน apt จะแจ้งเตือน: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY เมื่อคีย์ของ repository ภายนอกสูญหาย หรือ Hash Sum mismatch เมื่อดัชนีที่คุณดึงมาไม่ตรงกับไฟล์ Release ที่มีการลงลายเซ็นไว้ ซึ่งมักหมายความว่า caching proxy ส่งไฟล์เก่ามาให้ หรือคุณดึงข้อมูลจาก mirror ในขณะที่กำลังซิงค์ข้อมูลอยู่

นั่นคือมาตรฐานที่ควรใช้ตัดสินเมื่อหน้าเว็บของโปรเจกต์บอกให้คุณ pipe สคริปต์จาก curl เข้าสู่ shell โดยตรง เพราะไม่มีการตรวจสอบข้อมูลไบต์ใดๆ และคุณไม่เคยเห็นเนื้อหาเหล่านั้น เซิร์ฟเวอร์สามารถส่งข้อมูลอย่างหนึ่งให้สคริปต์และส่งอีกอย่างให้เบราว์เซอร์ได้ และคุณจะไม่มีสำเนาไว้ตรวจสอบภายหลัง ให้ดาวน์โหลดลงไฟล์ด้วย curl -fsSL <url> -o install.sh, ตรวจสอบค่า hash, อ่านเนื้อหาด้วย less แล้วค่อยรันสคริปต์นั้น นิสัยนี้ใช้เวลาเพียงประมาณยี่สิบวินาที และเป็นนิสัยเดียวกันกับที่ควรเริ่มทำบน VPS เครื่องใหม่ในช่วงสิบนาทีแรก ก่อนที่จะติดตั้งสิ่งใดลงบนเครื่อง

เก็บรายการ digest สำหรับสิ่งที่ติดตั้งด้วยตนเอง

แพ็กเกจที่ติดตั้งโดย apt จะถูกติดตามสถานะไว้ แต่ไฟล์ binary ที่คุณคัดลอกลงใน /usr/local/bin จะไม่ถูกติดตาม และไม่มีส่วนใดในระบบคอยตรวจสอบไฟล์เหล่านั้น รายการ digest จะเปลี่ยนไฟล์เหล่านี้ให้เป็นสิ่งที่ตรวจสอบได้ตามต้องการ:

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

--quiet จะไม่แสดงผลลัพธ์ใดๆ หากไฟล์ทั้งหมดตรงกัน และจะแสดงเฉพาะบรรทัดที่ตรวจสอบไม่ผ่านเท่านั้น ดังนั้นความเงียบจึงหมายถึงการผ่านการตรวจสอบ และ echo $? จะยืนยันผลลัพธ์ด้วย 0 ซึ่งเป็นรูปแบบที่ควรนำไปใส่ในงานที่ตั้งเวลาไว้ (scheduled job) --status จะทำงานละเอียดกว่าโดยไม่แสดงผลลัพธ์ใดๆ เลย และให้สถานะการทำงาน (exit status) แก่คุณเท่านั้น ให้ชี้รูปแบบเดียวกันนี้ไปยังไฟล์จริงด้วย sha256sum /usr/local/bin/* > ~/local-bin.sha256 เพื่อสร้างค่าพื้นฐาน (baseline) เส้นทางไฟล์จะถูกจัดเก็บในรายการตามที่คุณพิมพ์ ดังนั้นการใช้ absolute path จะช่วยให้การตรวจสอบทำงานได้จากทุกไดเรกทอรี

โปรดเข้าใจให้ชัดเจนว่าค่าพื้นฐานนี้มีประโยชน์อย่างไร มันสามารถตรวจพบไฟล์ที่ถูกเปลี่ยนแปลงได้ แต่มันไม่สามารถตรวจพบผู้บุกรุกที่มีสิทธิ์ root อยู่แล้วได้ เนื่องจากผู้บุกรุกเหล่านั้นสามารถเขียนทับ inventory.sha256 ได้ง่ายพอๆ กับที่พวกเขาเขียนทับไฟล์ binary หากคุณต้องการให้รายการนี้มีความหมาย คุณควรเก็บรายการไว้นอกเครื่อง ซึ่งเป็นส่วนหนึ่งของคำถามที่กว้างกว่าเรื่อง คุณเชื่อใจ VPS ของคุณได้มากแค่ไหน และใครอื่นที่สามารถเข้าถึงดิสก์ภายใต้ VPS นั้นได้บ้าง

FAQ

การที่ checksum ตรงกันหมายความว่าไฟล์ที่ดาวน์โหลดมาปลอดภัยหรือไม่?

ไม่ปลอดภัย หมายความเพียงว่าข้อมูลไบต์ที่คุณมีตรงกับค่า digest ที่คุณนำไปเปรียบเทียบ หากผู้โจมตีควบคุมหน้าเว็บที่เผยแพร่ค่า digest นั้นได้ พวกเขาก็จะเผยแพร่ค่า digest ของไฟล์ที่พวกเขาเตรียมไว้เอง และการตรวจสอบของคุณก็จะแสดงผล OK การที่ค่าตรงกันเป็นเพียงการยืนยันความสอดคล้องของข้อมูลเท่านั้น การยืนยันความปลอดภัยต้องอาศัยลายเซ็นดิจิทัลที่ตรวจสอบเทียบกับกุญแจ (key) ที่คุณได้รับมาจากแหล่งอื่นที่เชื่อถือได้ และเมื่อนั้นค่า digest จึงจะได้รับความน่าเชื่อถือนั้นมา

ทำไม sha256sum -c ถึงแสดงผล FAILED open or read?

เพราะโปรแกรมไม่ได้อ่านไฟล์นั้น บรรทัดที่อยู่เหนือขึ้นไปจะแสดง No such file or directory พร้อมกับชื่อไฟล์ที่โปรแกรมพยายามค้นหา ชื่อไฟล์ที่ระบุไว้ภายในไฟล์ SHA256SUMS จะอ้างอิงตามไดเรกทอรีที่คุณรันคำสั่ง ดังนั้นให้เปลี่ยนไดเรกทอรีเข้าไปยังตำแหน่งที่เก็บไฟล์ที่ดาวน์โหลดมาแล้วรันคำสั่งใหม่อีกครั้ง หากในรายการมีชื่อไฟล์ที่คุณไม่ได้ดาวน์โหลดมาด้วย ให้เพิ่มแฟล็ก --ignore-missing การแสดงผล FAILED เปล่าๆ โดยไม่มี open or read คือสถานการณ์ตรงกันข้าม นั่นคือโปรแกรมได้อ่านไฟล์แล้ว แต่ค่า digest ไม่ตรงกัน

MD5 เพียงพอสำหรับการตรวจสอบไฟล์ที่ดาวน์โหลดหรือไม่?

หากใช้เพื่อตรวจสอบความเสียหายจากอุบัติเหตุ ถือว่าเพียงพอ การโอนถ่ายไฟล์ที่ไม่สมบูรณ์หรือบล็อกข้อมูลบนดิสก์ที่เสียหายจะไม่ทำให้ค่า MD5 ตรงกันโดยบังเอิญ แต่หากใช้ป้องกันผู้โจมตี ถือว่าไม่เพียงพอ เนื่องจากมีการสร้างไฟล์สองไฟล์ที่ต่างกันแต่มีค่า MD5 เท่ากันได้มาตั้งแต่ปี 2004 และ SHA-1 ก็ถูกเจาะด้วยวิธี chosen-prefix collision ในปี 2020 ให้เลือกใช้บรรทัด SHA-256 เมื่อโปรเจกต์เผยแพร่ค่าทั้งสองแบบ และหากโปรเจกต์ใดเผยแพร่เฉพาะ MD5 ให้ถือว่าเป็นสัญญาณของกระบวนการปล่อยซอฟต์แวร์ที่ล้าสมัย

sha256sum -c และ gpg --verify แตกต่างกันอย่างไร?

sha256sum -c ใช้พิสูจน์ว่าไฟล์ตรงกับค่า digest ที่ระบุ ส่วน gpg --verify ใช้พิสูจน์ว่าไฟล์รายการ digest นั้นได้รับการลงนามโดยผู้ถือครอง private key ที่ระบุ ทั้งสองคำสั่งตอบคำถามที่ต่างกัน ดังนั้นควรใช้งานทั้งสองอย่างเมื่อโปรเจกต์มีให้ทั้งคู่ ลายเซ็นดิจิทัลจะทำให้รายการ digest น่าเชื่อถือ และรายการ digest นั้นจะทำให้ไฟล์ที่ดาวน์โหลดมาน่าเชื่อถือตามไปด้วย

ฉันจะตรวจสอบไฟล์หนึ่งไฟล์เทียบกับค่า digest ที่แสดงบนหน้าเว็บได้อย่างไร?

อย่าใช้วิธีไล่สายตาเปรียบเทียบตัวอักษร ให้บันทึกค่า digest และชื่อไฟล์ลงในบรรทัดเดียวกันโดยเว้นวรรคสองช่อง จากนั้นรันคำสั่ง sha256sum -c กับไฟล์นั้นแล้วอ่านผลลัพธ์ OK หรือ FAILED ที่แสดงออกมา การสร้างบรรทัดด้วยคำสั่ง printf '%s %s\n' จะช่วยป้องกันความผิดพลาดในการจัดรูปแบบ ซึ่งเป็นสาเหตุที่ทำให้ sha256sum ปฏิเสธไฟล์พร้อมแสดงข้อความ no properly formatted checksum lines found