ไลบรารีสำหรับแปลง JSON แบบมินิมอลลิสต์ใหม่ที่เรียกว่า sj.h ได้จุดประกายการอภิปรายอย่างเข้มข้นในชุมชนนักพัฒนาเกี่ยวกับความสมดุลระหว่างความเรียบง่ายและความปลอดภัยในซอฟต์แวร์โอเพนซอร์ส ไลบรารีนี้มีขนาดเพียง 150 บรรทัดของโค้ด C99 โดยสัญญาว่าจะไม่มีการจัดสรรหน่วยความจำและมีสถานะขั้นต่ำ พร้อมทั้งให้ความสามารถในการแปลง JSON ขั้นพื้นฐาน
ข้อมูลจำเพาะของไลบรารี:
- ขนาด: ประมาณ 150 บรรทัดของโค้ด C99
- หน่วยความจำ: ไม่มีการจัดสรรหน่วยความจำเลย พร้อมสถานะที่น้อยที่สุด
- คุณสมบัติ: ข้อความแสดงข้อผิดพลาดพร้อมตำแหน่งบรรทัด:คอลัมน์
- ข้อจำกัด: ไม่มีการแยกวิเคราะห์ตัวเลขหรือสตริงในตัว
- ใบอนุญาต: สาธารณสมบัติ ( Unlicense )
ข้อกังวลด้านความปลอดภัยขึ้นมาเป็นประเด็นหลัก
ความขัดแย้งหลักมุ่งเน้นไปที่ช่องโหว่ด้านความปลอดภัยที่อาจเกิดขึ้นในโค้ดของไลบรารี นักวิจัยด้านความปลอดภัยได้ระบุปัญหาเกี่ยวกับ signed integer overflow ที่อาจทำให้เกิด undefined behavior เมื่อประมวลผลข้อมูลนำเข้าบางประเภท ไลบรารีไม่ได้ตรวจสอบ overflow เมื่อเพิ่มค่าตัวนับความลึกหรือหมายเลขบรรทัด/คอลัมน์ ซึ่งอาจถูกใช้ประโยชน์ได้ด้วยไฟล์ JSON ที่เป็นอันตรายซึ่งมีโครงสร้างที่ซ้อนกันลึกหรือบรรทัดที่ยาวมาก
นักวิจารณ์โต้แย้งว่าไลบรารีแปลง JSON ใดๆ ควรจัดการกับกรณีขอบเขตเหล่านี้อย่างปลอดภัย โดยเฉพาะอย่างยิ่งเนื่องจาก JSON มักมาจากแหล่งที่ไม่น่าเชื่อถือ พวกเขาชี้ให้เห็นว่าแม้ไลบรารีอาจทำงานได้ดีในสภาพแวดล้อมที่ควบคุมได้ แต่อาจกลายเป็นความเสี่ยงด้านความปลอดภัยหากถูกนำไปใช้ในระบบการผลิตที่ประมวลผลข้อมูลภายนอก
หมายเหตุ: Undefined behavior หมายถึงโค้ดที่ไม่มีผลลัพธ์ที่คาดเดาได้ตามข้อกำหนดของภาษาโปรแกรม
ปัญหาด้านความปลอดภัยที่ระบุได้:
- การล้นของจำนวนเต็มที่มีเครื่องหมายในตัวนับความลึก
- ไม่มีการตรวจสอบการล้นสำหรับหมายเลขบรรทัด/คอลัมน์
- พฤติกรรมที่ไม่ได้กำหนดไว้ที่อาจเกิดขึ้นกับข้อมูลป้อนเข้าที่เป็นอันตราย
- การแยกวิเคราะห์แบบผ่อนปรนที่ยอมรับ JSON ที่มีรูปแบบผิด
- ความลึกการซ้อนสูงสุดถูกจำกัดด้วย INT_MAX (โดยทั่วไปมากกว่า 2 พันล้าน)
ปรัชญาของไลบรารีขั้นต่ำ
ผู้สนับสนุนไลบรารีปกป้องแนวทางของมัน โดยเน้นว่าซอฟต์แวร์ทุกชิ้นไม่จำเป็นต้องมีคุณสมบัติด้านความปลอดภัยระดับองค์กร พวกเขาโต้แย้งว่าไลบรารีนี้ให้บริการในช่องทางเฉพาะ - นักพัฒนาที่ต้องการการแปลง JSON ที่เบาและเรียบง่ายสำหรับสภาพแวดล้อมที่ควบคุมได้หรือระบบฝังตัวที่มีทรัพยากรจำกัด
การถกเถียงนี้สะท้อนให้เห็นความแตกแยกทางปรัชญาที่กว้างขึ้นในการพัฒนาซอฟต์แวร์ นักพัฒนาบางคนชอบไลบรารีที่ครอบคลุมซึ่งจัดการกับกรณีขอบเขตที่เป็นไปได้ทุกกรณี ในขณะที่คนอื่นๆ ชอบเครื่องมือขั้นต่ำที่ทำสิ่งหนึ่งได้ดีและปล่อยให้ความซับซ้อนเพิ่มเติมเป็นหน้าที่ของผู้ใช้
การเปรียบเทียบกับไลบรารีอื่นๆ:
- cJSON: ครอบคลุมมากกว่า ใช้กันอย่างแพร่หลายในการผลิต
- nlohmann/json: ไลบรารี C++ ที่มี 122 ล้านการทดสอบหน่วย พัฒนามา 13 ปี
- simdjson: ปรับแต่งเพื่อประสิทธิภาพ
- json.lua: การใช้งาน Lua แบบบริสุทธิ์ ช้ากว่าแต่พกพาได้
ผลกระทบในโลกแห่งความเป็นจริงและข้อกังวลเรื่องการนำไปใช้
การอภิปรายนี้ได้เน้นย้ำปัญหาทั่วไปในซอฟต์แวร์โอเพนซอร์ส: โปรเจกต์งานอดิเรกที่พิสูจน์แล้วว่ามีประโยชน์มักจะถูกนำไปใช้ในระบบการผลิตโดยไม่มีการตรวจสอบความปลอดภัยที่เหมาะสม แม้ว่าใบอนุญาตสาธารณสมบัติของไลบรารีจะระบุอย่างชัดเจนว่ามาโดยไม่มีการรับประกัน แต่นักวิจารณ์กังวลว่านักพัฒนาอาจใช้มันอย่างไม่เหมาะสมในแอปพลิเคชันที่มีความอ่อนไหวด้านความปลอดภัย
สมาชิกชุมชนหลายคนได้เสนอการแก้ไขง่ายๆ รวมถึงการเพิ่มขีดจำกัดความลึกและการตรวจสอบ overflow ที่จะรักษาความเรียบง่ายของไลบรารีในขณะที่แก้ไขข้อกังวลด้านความปลอดภัยที่ร้ายแรงที่สุด แพตช์ที่แนะนำซึ่งจำกัดความลึกของการซ้อนไว้ที่ 999 ระดับแสดงให้เห็นว่าการเปลี่ยนแปลงขั้นต่ำสามารถปรับปรุงความปลอดภัยได้อย่างมีนัยสำคัญโดยไม่ทำลายปรัชญาหลักของไลบรารี
ไลบรารี sj.h เป็นตัวอย่างกรณีศึกษาที่น่าสนใจในความตึงเครียดที่ดำเนินอยู่ระหว่างความเรียบง่ายและความแข็งแกร่งในการพัฒนาซอฟต์แวร์ แม้ว่าอาจไม่เหมาะสำหรับการใช้งานทุกกรณี แต่ก็เป็นเครื่องเตือนใจว่าโปรเจกต์ต่างๆ มีความต้องการที่แตกต่างกัน และบางครั้งวิธีแก้ปัญหาที่เรียบง่ายที่สุดคือสิ่งที่ต้องการ
อ้างอิง: sj.h