ความพยายามของนักพัฒนาในการปรับปรุงความปลอดภัยของ supply chain สำหรับแพ็กเกจ JavaScript ที่ได้รับความนิยมมากที่สุดแพ็กเกจหนึ่งได้จุดประกายการถกเถียงเกี่ยวกับแนวทางการมีส่วนร่วมในโอเพ่นซอร์สและการตอบสนองของผู้ดูแลโปรเจ็กต์ เหตุการณ์นี้เน้นย้ำถึงความตึงเครียดที่เพิ่มขึ้นระหว่างผู้มีส่วนร่วมที่เน้นความปลอดภัยกับผู้ดูแลโปรเจ็กต์ที่ต้องรับมือกับการมีส่วนร่วมแบบอัตโนมัติและคุณภาพต่ำที่เพิ่มขึ้น
การปรับปรุงความปลอดภัยที่กลับกลายเป็นปัญหา
นักพัฒนาได้พยายามเพิ่ม package provenance ให้กับ lodash ซึ่งเป็นไลบรารีอรรถประโยชน์ JavaScript ที่ใช้กันอย่างแพร่หลายและมีการดาวน์โหลดหลายสิบล้านครั้งต่อสัปดาห์ Package provenance สร้างคำแถลงที่ลงนามในระหว่างกระบวนการสร้าง ช่วยตรวจจับแพ็กเกจที่เป็นอันตรายซึ่งข้าม CI/CD workflows ที่เหมาะสม แม้ว่า lodash จะมีความนิยมสูง แต่ก็ไม่ได้รับการอัปเดตมานานกว่าห้าปีและขาดฟีเจอร์ความปลอดภัยพื้นฐานนี้
ผู้มีส่วนร่วมได้ใช้เวลาหลายชั่วโมงในการ reverse-engineer กระบวนการสร้างของ lodash และสร้าง GitHub Actions workflow ที่ใช้งานได้สำเร็จ อย่างไรก็ตาม หลังจากเปิดและปิด pull request ที่ยังไม่พร้อมอย่างรวดเร็ว พวกเขาก็พบว่าตัวเองถูกบล็อกจาก repository อย่างสมบูรณ์ - ไม่สามารถสร้าง issues, ติดตาม repo หรือมีส่วนร่วมในทางใดก็ได้
Package provenance: ฟีเจอร์ความปลอดภัยที่สร้างหลักฐานทางการเข้ารหัสของวิธีการและสถานที่ที่แพ็กเกจซอฟต์แวร์ถูกสร้างขึ้น ช่วยให้ผู้ใช้ตรวจสอบความถูกต้องได้
สถานะโปรเจกต์ Lodash
- ไม่มีการปล่อยเวอร์ชันใหม่มานานกว่า 5 ปี
- มีการดาวน์โหลดหลายสิบล้านครั้งต่อสัปดาห์
- Main branch: ไม่มีการ commit มา 9 เดือน
- ไม่มี CI/CD workflow สำหรับการเผยแพร่
- อยู่ในอันดับ 10 อันดับแรกของแพ็กเกจ npm ที่ไม่มี provenance
ชุมชนแบ่งความเห็นเกี่ยวกับการตัดสินใจบล็อก
การบล็อกนี้ได้แบ่งแยกชุมชนโอเพ่นซอร์ส บางคนมองว่าเป็นการตอบสนองที่เกินเหตุต่อความพยายามปรับปรุงความปลอดภัยที่แท้จริง คนอื่นๆ โต้แย้งว่าการกระโดดเข้าไปเปลี่ยนแปลงกระบวนการสร้างที่สำคัญโดยไม่มีการหารือล่วงหน้าทำให้เกิดสัญญาณเตือน โดยเฉพาะอย่างยิ่งเมื่อพิจารณาจากการเพิ่มขึ้นของการมีส่วนร่วมที่สร้างโดย AI ที่มุ่งเป้าไปยัง repositories ที่ได้รับความนิยม
คนที่ฉันไม่รู้จักและไม่มีประวัติการมีส่วนร่วมในโปรเจ็กต์ของฉันแล้วกระโดดเข้าไปยุ่งกับ packaging, distribution, provenance ทันทีจะทำให้ฉันตั้งคำถามกับความตั้งใจของพวกเขาจริงๆ
ช่วงเวลาที่เกิดขึ้นใน Hacktoberfest - กิจกรรมที่ยาวนานหนึ่งเดือนเพื่อส่งเสริมการมีส่วนร่วมในโอเพ่นซอร์ส - อาจมีส่วนทำให้ผู้ดูแลระแวดระวังเกี่ยวกับการมีส่วนร่วมแบบอัตโนมัติหรือผิวเผิน
การใช้งาน Package Provenance
- มีเพียง 2 จาก 10 แพ็กเกจ npm ยอดนิยมเท่านั้นที่ใช้ provenance
- แพ็กเกจ TypeScript ยังขาด provenance แม้จะเป็นที่นิยม
- การใช้งานต้องการเพียงแค่ flags ง่าย ๆ ใน npm publish:
--provenance --access public - ช่วยตรวจจับแพ็กเกจที่หลีกเลี่ยงการตรวจสอบความปลอดภัยของ CI/CD
ความท้าทายที่กว้างขึ้นของการดูแลโอเพ่นซอร์ส
เหตุการณ์นี้สะท้อนปัญหาที่ใหญ่กว่าที่โปรเจ็กต์โอเพ่นซอร์สยอดนิยมกำลังเผชิญ ผู้ดูแลต้องดิ้นรนเพื่อสร้างสมดุลระหว่างการต้อนรับผู้มีส่วนร่วมที่แท้จริงในขณะที่กรองการส่งคุณภาพต่ำ, สแปมที่สร้างโดย AI และการเปลี่ยนแปลงที่อาจเป็นอันตราย ผู้ดูแล lodash ได้ประกาศล้มละลายด้าน issue ในปี 2023 โดยปิด issues ที่เปิดอยู่จำนวนมากเพื่อเริ่มต้นใหม่
การขาดการสื่อสารทำให้ปัญหารุนแรงขึ้น หากไม่มีคำอธิบายสำหรับการบล็อก ผู้มีส่วนร่วมไม่สามารถเรียนรู้จากความผิดพลาดหรือชี้แจงความตั้งใจได้ สิ่งนี้สร้างวงจรที่นักพัฒนาที่มีเจตนาดีกลายเป็นท้อแท้ในขณะที่ผู้ดูแลรู้สึกถูกครอบงำด้วยความสนใจที่ไม่พึงประสงค์
นักพัฒนาได้ปรับแนวทางของตนแล้ว โดยวางแผนที่จะเปิด discussion issues ก่อนส่งการเปลี่ยนแปลงโค้ดเพื่อวัดความสนใจของผู้ดูแล แม้ว่าเป้าหมายการปรับปรุงความปลอดภัยจะยังคงถูกต้อง แต่ประสบการณ์นี้แสดงให้เห็นว่าแม้แต่การมีส่วนร่วมที่เป็นประโยชน์ก็ต้องการการแนะนำอย่างระมัดระวังในภูมิทัศน์โอเพ่นซอร์สที่ซับซ้อนในปัจจุบัน