ความเชื่อมั่นในการดาวน์โหลดแอปเดสก์ท็อป: เช็กซัม ลายเซ็น และที่มาบิลด์พิสูจน์อะไรจริง

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

คำถามเหล่านี้ต้องใช้หลักฐานต่างกัน การเรียกวิธีตรวจทุกอย่างว่า “รับรองความปลอดภัย” สร้างความคาดหวังที่วิธีนั้นทำไม่ได้ และอาจทำให้นักพัฒนามองข้ามช่องว่างในกระบวนการเผยแพร่

เช็กซัมตอบว่าไฟล์ตรงกันหรือไม่

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

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

ผู้เผยแพร่ควรดูแลชื่อไฟล์ที่ชัด ข้อมูลรุ่น และรายการเช็กซัมไว้ด้วยกัน ผู้ใช้ไม่ควรต้องคัดลอกแฮชจากบทความเก่ามาเทียบตัวติดตั้งของคนละแพลตฟอร์มหรือคนละบิลด์

ลายเซ็นต้องตรวจตัวตนที่คาดด้วย

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

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

เมื่อเปลี่ยนใบรับรองหรือวิธีลงนาม ผู้เผยแพร่ต้องให้คำอธิบายที่ตรวจได้ด้วย การให้ผู้ใช้เชื่อใบรับรองไม่คุ้นทันทีไม่ใช่ขั้นตอนอัปเดตที่ครบถ้วน

ที่มาบิลด์เชื่อมแพ็กเกจกับกระบวนการผลิต

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

ระดับบิลด์ SLSA แยกการมีบันทึกที่มา ที่มาลงนามซึ่งสร้างโดยแพลตฟอร์มโฮสต์ และการปกป้องแพลตฟอร์มบิลด์ที่เข้มขึ้น เมื่ออ้างระดับควรบอกขอบเขตและหลักฐาน ไม่ใช้ตัวเลขเป็นคะแนนครอบคลุมความเสี่ยงซอฟต์แวร์ทุกชนิด ระดับบิลด์ SLSA

หลักฐานเหล่านี้เสริมกันได้ นักพัฒนาควรอธิบายว่าจัดให้อะไรและยังต้องตรวจอะไรแยก

บิลด์ที่ทำซ้ำได้ต้องระบุอินพุตและสภาพแวดล้อม

โครงการ Reproducible Builds นิยามว่าต้องสร้างอาร์ติแฟกต์ที่ระบุตรงกันทุกบิตจากซอร์สโค้ด สภาพแวดล้อม และคำสั่งบิลด์เดียวกัน เป็นเป้าตรวจที่แม่นยำกว่า “คอมไพล์ได้บนเครื่องฉัน” นิยามบิลด์ที่ทำซ้ำได้

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

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

ลำดับตรวจดาวน์โหลดที่ใช้ได้จริง

1. ยืนยันรีโพซิทอรีเผยแพร่จากช่องทางทางการของโครงการ ไม่อาศัยเพียงโฆษณาค้นหาหรือลิงก์ส่งต่อ
2. อ่านบันทึกรุ่น ตรวจระบบปฏิบัติการ สถาปัตยกรรมหน่วยประมวลผล และช่องทางรุ่น
3. เทียบไฟล์กับเช็กซัมตรงรุ่น หากมีลายเซ็นหรือที่มา ให้ตรวจตัวตนที่คาดและขอบเขตด้วย
4. ตรวจสถานะบำรุงรักษาและข้อจำกัดที่ทราบ โดยไม่ถือว่าป้าย “ล่าสุด” แปลว่าเหมาะกับงานจริง
5. เมื่อข้อมูลขัดกัน เก็บรุ่นและชื่อไฟล์แล้วขอคำชี้แจงผ่านช่องทางสนับสนุนโครงการ

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

สำหรับนักพัฒนา การรักษาสายข้อมูลนี้ต่อเนื่องมีค่ากว่าติดตรา “ตรวจแล้ว” ครั้งเดียว ผู้ใช้ควรยังหาคำอธิบายได้เมื่อรุ่นเก่าถูกถอน วิธีลงนามเปลี่ยน หรืออัปเดตล้มเหลว

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

นักพัฒนาเริ่มจากทำรายการหลักฐานรุ่นให้ครบ ผู้ใช้เริ่มจากตรวจดาวน์โหลดหนึ่งรายการของแอปที่ใช้บ่อย แชร์ข้อมูลตรวจสอบที่อยากเห็นบนหน้าเผยแพร่ใน AlphaBiz Discussions