Google เพิ่งประกาศโครงการ OSS Rebuild ซึ่งเป็นโครงการที่มุ่งเสริมสร้างความไว้วางใจในแพ็กเกจโอเพนซอร์สโดยการสร้างใหม่และตรวจสอบไลบรารีที่ได้รับความนิยมจาก PyPI, npm และ Crates.io registries ระบบนี้สร้าง SLSA Build Level 3 provenance attestations เพื่อช่วยตรวจจับการโจมตี supply chain โดยไม่ต้องให้ผู้ดูแลแพ็กเกจเปลี่ยนแปลงอะไร อย่างไรก็ตาม การประกาศนี้ได้จุดประกายการถกเถียงอย่างมากในชุมชนนักพัฒนาเกี่ยวกับว่าแนวทางนี้เป็นโซลูชันที่ถูกต้องหรือไม่
ความครอบคลุมการ Rebuild OSS ในปัจจุบัน:
- PyPI (Python): แพ็กเกจหลายพันแพ็กเกจที่มีการรับรอง SLSA Build Level 3
- npm (JavaScript/TypeScript): แพ็กเกจยอดนิยมที่มีการตรวจสอบ rebuild
- Crates.io (Rust): รองรับด้วยคำจำกัดความการ build อัตโนมัติ
- การรับรองทั้งหมด: มีการเผยแพร่ 9,507 builds ณ วันที่ประกาศ
- การสนับสนุนเชิงทดลอง: แพ็กเกจ Debian, JVM และระบบนิเวศ Ruby
นักพัฒนาตั้งคำถามเกี่ยวกับความจำเป็นของโครงสร้างพื้นฐานใหม่
สมาชิกชุมชนหลายคนตั้งคำถามว่าทำไม Google ถึงสร้างระบบใหม่ทั้งหมดในขณะที่มีโซลูชันที่มีอยู่แล้ว การวิจารณ์ที่ดังที่สุดมุ่งเน้นไปที่ package managers ที่มีอยู่แล้วอย่าง Nix และ Guix ซึ่งมีความสามารถในการสร้าง reproducible builds และการตรวจสอบอยู่แล้ว นักวิจารณ์โต้แย้งว่าการมีส่วนร่วมกับระบบนิเวศที่มีความเป็นผู้ใหญ่เหล่านี้จะมีประโยชน์มากกว่าการเริ่มต้นใหม่ตั้งแต่ศูนย์
การถกเถียงขยายไปเกินกว่าแค่ package managers นักพัฒนาหลายคนชี้ให้เห็นว่า Linux distributions อย่าง Debian และ Arch Linux มีระบบตรวจสอบการสร้างใหม่ที่แข็งแกร่งอยู่แล้ว โซลูชันที่มีอยู่เหล่านี้ได้ดำเนินการอย่างประสบความสำเร็จมาหลายปี ทำให้บางคนสงสัยว่าแนวทางของ Google ทำซ้ำงานที่มีอยู่แล้วมากกว่าที่จะปรับปรุงมัน
ทางเลือกอื่นที่ชุมชนแนะนำ:
- Nix/NixOS: มีไลบรารีที่แพ็กเกจแล้ว 107,158 ตัวพร้อมการสร้างแบบทำซ้ำได้
- ReprOS/StageX: โมเดลความไว้วางใจแบบกระจายอำนาจพร้อมการ bootstrap จากซอร์สโค้ดเต็มรูปแบบ
- Debian: โครงการสร้างแบบทำซ้ำได้ (reproduce.debian.net ตั้งแต่ปี 2024)
- Arch Linux: การสร้างแบบทำซ้ำได้ (reproducible.archlinux.org ตั้งแต่ปี 2020)
- Guix: การทำซ้ำแบบ bit-for-bit พร้อมการตรวจสอบฝั่งไคลเอนต์
ความกังวลเรื่องการรวมอำนาจครองการอภิปราย
ประเด็นที่เป็นข้อโต้แย้งหลักคือแนวทางการรวมอำนาจของ Google ในการตรวจสอบแพ็กเกจ สมาชิกชุมชนกังวลเกี่ยวกับการสร้างจุดล้มเหลวเดียวอีกจุดหนึ่งใน software supply chain โดยเฉพาะอย่างยิ่งเมื่อพิจารณาประวัติของ Google ในการยุติโครงการต่างๆ ความกังวลนี้รุนแรงเป็นพิเศษเพราะ OSS Rebuild ต้องการ Google Cloud credentials และพึ่งพาโครงสร้างพื้นฐานของ Google สำหรับการตรวจสอบ attestation
สิ่งนี้ดูเหมือนจะมีข้อบกพร่องในการสมมติว่าเซิร์ฟเวอร์ของ google ไม่ถูกบุกรุก การมีความสามารถแบบกระจายในการทำซ้ำนั้นดีกว่ามาก
แนวทางทางเลือกอย่าง ReprOS และ StageX ได้รับความสนใจในการอภิปรายสำหรับโมเดลการตรวจสอบแบบกระจายของพวกเขา ระบบเหล่านี้อนุญาตให้หลายฝ่ายตรวจสอบการสร้างอย่างอิสระโดยไม่ต้องพึ่งพาหน่วยงานที่เชื่อถือได้เพียงหน่วยงานเดียว ซึ่งตอบสนองความกังวลเรื่องการรวมอำนาจที่นักพัฒนาหลายคนได้ยกขึ้น
การนำไปใช้ทางเทคนิคได้รับการตอบรับที่หลากหลาย
แม้ว่านักพัฒนาบางคนจะชื่นชมความสามารถทางเทคนิคของโครงการ แต่คนอื่นๆ ตั้งคำถามเกี่ยวกับการนำไปใช้ในทางปฏิบัติ ระบบปัจจุบันต้องการให้ผู้ใช้ติดตั้งเครื่องมือ command-line ที่ใช้ Go ซึ่งหลายคนมองว่าเป็นอุปสรรคสำคัญต่อการยอมรับ สมาชิกชุมชนได้เริ่มสร้าง web interfaces ที่ไม่เป็นทางการเพื่อทำให้ข้อมูลเข้าถึงได้ง่ายขึ้น
การใช้ AI แบบทดลองของโครงการสำหรับการทำให้กระบวนการสร้างเป็นแบบอัตโนมัติก็ได้สร้างการอภิปรายเช่นกัน ในขณะที่ Google มองว่านี่เป็นแนวทางที่มีแนวโน้มดีสำหรับการจัดการสถานการณ์การสร้างที่ซับซ้อน นักพัฒนาบางคนยังคงสงสัยเกี่ยวกับการพึ่งพา language models สำหรับโครงสร้างพื้นฐานความปลอดภัยที่สำคัญ
ความท้าทายในการรวมระบบนิเวศ
บางทีความท้าทายที่สำคัญที่สุดที่ชุมชนเน้นย้ำคือวิธีที่ OSS Rebuild รวมเข้ากับ workflows การพัฒนาที่มีอยู่ ไม่เหมือนกับระบบอย่าง Nix ที่สามารถแทนที่ workflows การจัดการแพ็กเกจทั้งหมด OSS Rebuild ทำงานเป็นชั้นเพิ่มเติมบน registries ที่มีอยู่ แนวทางนี้หมายความว่านักพัฒนาต้องใช้เครื่องมือและกระบวนการเพิ่มเติมมากกว่าที่จะเปลี่ยนไปใช้พื้นฐานที่ปลอดภัยกว่า
โครงการปัจจุบันครอบคลุมแพ็กเกจหลายพันแพ็กเกจในสามระบบนิเวศหลัก แต่ feedback จากชุมชนชี้ให้เห็นว่าการรวมระบบนิเวศในวงกว้างยังคงเป็นอุปสรรคสำคัญ นักพัฒนาต้องการโซลูชันที่ทำงานร่วมกับเครื่องมือที่มีอยู่ของพวกเขาอย่างราบรื่นมากกว่าที่จะต้องมีขั้นตอนการตรวจสอบเพิ่มเติม
แม้จะมีการวิจารณ์ OSS Rebuild ของ Google แสดงถึงความพยายามอย่างจริงจังในการแก้ไขความกังวลเรื่องความปลอดภัย supply chain ที่ได้รบกวนอุตสาหกรรมซอฟต์แวร์ ว่าจะได้รับการยอมรับหรือไม่น่าจะขึ้นอยู่กับว่าทีมงานจะแก้ไขความกังวลของชุมชนเกี่ยวกับการรวมอำนาจและการรวมเข้ากับ workflows ที่มีอยู่ได้ดีแค่ไหน
อ้างอิง: Introducing OSS Rebuild: Open Source, Rebuilt to Last