- FFmpeg คือเฟรมเวิร์กโอเพนซอร์สหลักสำหรับการประมวลผลสื่อทั่วโลก และเป็นองค์ประกอบสำคัญที่ใช้ในบริการหลักอย่าง VLC·Chrome·YouTube
- ไม่นานมานี้ สแกนเนอร์ความปลอดภัยที่ขับเคลื่อนด้วย AI ของ Google พบ บั๊กเล็กน้อย ที่เกี่ยวข้องกับโคเด็กของเกมจากปี 1995 จุดชนวนข้อถกเถียงว่าบริษัทใหญ่กำลังผลักภาระเกินควรให้กับนักพัฒนาอาสาสมัคร
- ฝั่ง FFmpeg ระบุว่า “โปรเจ็กต์นี้แทบทั้งหมดดูแลโดย อาสาสมัคร” และยืนยันว่า Google ไม่ควรแค่ส่งรายงานช่องโหว่ แต่ควร ส่งแพตช์หรือสนับสนุนด้านการเงิน ด้วย
- Google เน้นย้ำการมีส่วนร่วมด้านความปลอดภัยอย่างโปร่งใส โดยอ้างถึง นโยบายการเปิดเผยของ Project Zero และ โปรแกรม Patch Rewards แต่ชุมชน FFmpeg ชี้ว่าข้อจำกัดด้านค่าตอบแทนและการสนับสนุนที่ทำได้จริงยังไม่เพียงพอ
- ข้อถกเถียงครั้งนี้สะท้อนปัญหา CVE จำนวนมากที่ AI สร้างขึ้นกับความยั่งยืนของการดูแลโอเพนซอร์ส และลุกลามไปสู่การถกเรื่องความรับผิดชอบของบริษัทยักษ์ใหญ่ด้านเทคโนโลยี
ภาพรวมความขัดแย้งระหว่าง FFmpeg กับ Google
- FFmpeg เป็นเฟรมเวิร์กมัลติมีเดียโอเพนซอร์สที่รองรับ การแปลงไฟล์, การเล่น, และการสตรีม ของไฟล์เสียงและวิดีโอ
- ไลบรารีหลักอย่าง libavcodec, libavformat ถูกใช้งานใน VLC, Kodi, Plex, Chrome, Firefox, YouTube เป็นต้น
- แต่เช่นเดียวกับโปรเจ็กต์โอเพนซอร์สสำคัญอื่น ๆ โปรเจ็กต์นี้ก็อยู่ในภาวะ ขาดแคลนงบประมาณอย่างหนัก
- บน Twitter เกิดการโต้เถียงระหว่าง FFmpeg, Google, Chainguard และนักวิจัยความปลอดภัย เกี่ยวกับ วิธีการเปิดเผยช่องโหว่และความรับผิดชอบของแต่ละฝ่าย
- ประเด็นหลักของการถกเถียงคือ รายงานช่องโหว่จำนวนมากที่สร้างโดย AI มักมีคุณค่าจริงต่ำ
จุดเริ่มต้นของดราม่า: บั๊กเล็กน้อยที่ AI ของ Google พบ
- เอเจนต์ AI ของ Google พบ บั๊กที่เกี่ยวข้องกับการถอดรหัส LucasArts Smush codec ใน FFmpeg
- ปัญหานี้เป็น ช่องโหว่ระดับปานกลาง ที่มีผลเฉพาะกับ 10–20 เฟรมแรกของเกมปี 1995 Rebel Assault 2 เท่านั้น
- นักพัฒนา FFmpeg ได้แพตช์ปัญหานี้แล้ว แต่ก็ตำหนิการรายงานที่ไม่มีประสิทธิภาพ โดยเรียกว่า “CVE slop”
- FFmpeg ระบุว่า “FFmpeg aims to play every video file ever made” โดยมีเป้าหมายด้านความเข้ากันได้อย่างสมบูรณ์แบบ แต่ก็กล่าวถึงด้วยว่าโค้ดส่วนใหญ่ เขียนด้วยภาษาแอสเซมบลี ทำให้ดูแลรักษาได้ยาก
ภาระของผู้ดูแลโอเพนซอร์ส
- ชุมชน FFmpeg วิจารณ์ว่า บริษัทใหญ่ที่ใช้ FFmpeg อย่าง Google กำลัง โยนภาระการแก้ช่องโหว่ให้กับอาสาสมัครที่ไม่ได้รับค่าตอบแทน
- จุดยืนของพวกเขาคือ เมื่อ Google รายงานช่องโหว่ ก็ควร แนบแพตช์มาด้วยหรือสนับสนุนเงินทุน ควบคู่กันไป
- อีกกรณีคล้ายกันคือ Nick Wellnhofer ผู้ดูแล libxml2 ที่ประกาศ หยุดการดูแลรักษา เพราะต้องรับมือกับรายงานความปลอดภัยจากบุคคลที่สามซ้ำแล้วซ้ำเล่า
- เขาระบุว่า “การที่อาสาสมัครที่ไม่ได้รับค่าตอบแทนต้องใช้เวลาหลายชั่วโมงทุกสัปดาห์เพื่อจัดการปัญหาด้านความปลอดภัย เป็นสิ่งที่ไม่ยั่งยืน”
ข้อถกเถียงเรื่องนโยบายการเปิดเผยของ Google Project Zero
- ในเดือนกรกฎาคม 2025 Google Project Zero (GPZ) ได้นำนโยบาย ‘** Reporting Transparency**’ มาใช้
- หลังพบช่องโหว่จะ เปิดเผยภายใน 1 สัปดาห์ และเริ่มนับ เส้นตายแก้ไขภายใน 90 วัน โดยอัตโนมัติ
- แม้แพตช์จะยังไม่พร้อมก็ยังมีการเปิดเผยต่อไป ทำให้ถูกวิจารณ์ว่า สร้างแรงกดดันเกินควรต่อโปรเจ็กต์ที่ขับเคลื่อนด้วยอาสาสมัคร
- FFmpeg โต้กลับว่า “มันยุติธรรมหรือไม่ที่ AI ไปค้นพบปัญหาความปลอดภัยในโค้ดงานอดิเรก แล้วเรียกร้องให้อาสาสมัครเป็นคนแก้”
- แม้ Google จะมี Patch Rewards Program อยู่ แต่ FFmpeg ชี้ว่า “มีข้อจำกัดอย่างเช่นเดือนละ 3 รายการ จึงแทบไม่ช่วยอะไรในทางปฏิบัติ”
มุมมองที่แตกต่างและความยั่งยืนของโอเพนซอร์ส
- Dan Lorenc จาก Chainguard ปกป้องบทบาทของ Google โดยกล่าวว่า การเปิดเผยช่องโหว่ด้านความปลอดภัยก็เป็น การมีส่วนร่วมต่อสินค้าสาธารณะดิจิทัล เช่นกัน
- เขากล่าวว่า “Google เป็นหนึ่งในบริษัทที่สนับสนุนโอเพนซอร์สมากที่สุด และการถกเถียงแบบนี้อาจยิ่งทำให้ผู้สนับสนุนถอยห่าง”
- อย่างไรก็ตาม ฝั่ง FFmpeg เน้นย้ำว่า พวกเขา ขาดทั้งคนและเงินทุน ในการรับมือกับ CVE จำนวนมากที่ AI สร้างขึ้น
- ผู้เชี่ยวชาญด้านความปลอดภัยยอมรับว่า เนื่องจาก FFmpeg เป็นองค์ประกอบหลักของโครงสร้างพื้นฐานอินเทอร์เน็ต การเปิดเผยช่องโหว่จึงยังจำเป็น
- ช่วงท้ายของบทความเน้นว่า “หากไม่มีการสนับสนุนที่เป็นรูปธรรมจากบริษัทใหญ่ ก็เป็นไปไม่ได้ที่จะรักษาโปรเจ็กต์โอเพนซอร์สสำคัญไว้ได้” พร้อมยกกรณีของ libxml2 เพื่อเน้นย้ำ ความจำเป็นของโครงสร้างการสนับสนุนที่ยั่งยืน
15 ความคิดเห็น
คงไม่ถึงขั้นพังทลายความสัมพันธ์กันเหมือนกรณีระหว่างมูลนิธิ WordPress กับบริษัท WP Engine หรอกใช่ไหม?
ดูเหมือนว่าจะเป็นเรื่องต่อเนื่องจาก
https://daniel.haxx.se/blog/2024/…
ถ้าบทความข้างบนเป็นกรณีที่บุคคลทั่วไปส่งรายงานที่ผิดไปเลยเพื่อหวังเงินจาก bug bounty กรณีของ FFmpeg คือรายงานที่บริษัทยักษ์ใหญ่ส่งมานั้นมีผลใช้ได้ แต่เป็นเรื่องเล็กน้อย
ถ้า Google ชี้ประเด็นขึ้นมา จำเป็นต้องตอบสนองทุกครั้งเลยหรือ?
ดูเหมือนว่าคงเลี่ยงไม่ได้ที่จะต้องรับมือ เพราะสถานการณ์เป็นแบบที่ตัวช่องโหว่ถูกเปิดเผยออกสู่สาธารณะไปแล้ว
อ๋อ... มีมุมมองแบบนั้นด้วยนี่เองครับ ขอบคุณที่บอกนะครับ!
แปลว่าเป็นส่วนที่พอช่องโหว่ถูกเปิดเผยแล้วก็อาจถูกใช้โจมตีผ่านจุดนั้นได้สินะครับ น่ากลัวจัง
พูดกันตามจริง จะบอกว่าไม่ว่าจะเปิดเผยต่อสาธารณะหรือไม่ ถ้าเดือดร้อนนักก็ไปแก้เองสิ~ ก็ยังได้ แต่เหมือนว่าผู้ดูแลโครงการเป็นคนที่ทำแบบนั้นไม่ลง จึงทำให้มันพัฒนามาได้ไกลถึงขนาดนี้
อ๋อ.... ดูเหมือนว่าสิ่งที่คุณพูดจะถูกต้องนะครับ
ผมคิดจากมุมมองของตัวเองมากเกินไปจริง ๆ
ขอบคุณสำหรับคำพูดของคุณครับ!
ความคิดเห็นจาก Hacker News
มีส่วนหนึ่งในบทความที่น่าประทับใจ คือเรื่องที่ Mark Atwood ต้องอธิบายกับหัวหน้าที่ Amazon เพื่อสกัดการตัดสินใจบางอย่างเกี่ยวกับ FFmpeg ว่า “พวกเขาไม่ใช่เวนเดอร์ ไม่มี NDA และเราไม่สามารถใช้อิทธิพลกับพวกเขาได้”
ฉันเห็นด้วยกับแนวคิดที่ว่า “อย่านำมาแต่ปัญหา จงนำทางแก้มาด้วย” แต่ก็คิดว่าถ้า Google มีเงินพอจะหาบั๊กได้ ก็มีเงินพอจะช่วยแก้ได้เช่นกัน
เพราะแบบนั้นจะได้ไม่ต้องพึ่งแพตช์ปิดภายในองค์กร สามารถตอบแทนโครงการที่ช่วยเราไว้ตั้งแต่แรก และยังเป็นสิ่งที่ถูกต้องในเชิงจริยธรรมด้วย
แต่ในทางปฏิบัติ ปัญหาคือ ข้อกำหนดด้าน compliance และอุปสรรคเชิงกระบวนการ ภายในบริษัทมักทำให้การ upstream ทำได้ยาก
ฉันเคยจินตนาการถึง ไลเซนส์เชิงเสียดสี ที่กำหนดว่าถ้าพนักงานบริษัทใน S&P500 จะรายงานบั๊ก ต้องบริจาคเงินจำนวนหนึ่งก่อน และถ้าจ่ายไม่ถึงเกณฑ์ก็ไม่ควรคาดหวังว่าจะได้รับการตอบกลับภายในเวลาที่กำหนด
เวลาบริษัทต่าง ๆ รู้สึกไม่สะดวก พวกเขาก็ไม่ลังเลที่จะหันไปใช้ซอฟต์แวร์ปิดหรือเปลี่ยนไปใช้ AGPL ดังนั้นตอนนี้ถึงเวลาที่ต้องจ่ายค่าตอบแทนกันตรง ๆ แล้ว
ในฐานะ ผู้ดูแลรักษา โอเพนซอร์ส ฉันเข้าใจความรู้สึกที่ว่าบริษัทใหญ่ ๆ เหมือนกำลังบังคับให้ทำงานฟรี ด้วยการเปิดเผยปัญหาความปลอดภัยออกมา
แต่ในความเป็นจริง ไม่ว่าใครจะเป็นคนรายงาน ประเด็นด้านความปลอดภัยก็ยังเป็นสิ่งที่ฉันต้องแก้อยู่ดี
โครงการจะไม่ให้ความสำคัญกับความปลอดภัยเป็นอันดับต้น ๆ ก็ได้ แต่ถ้าเลือกแบบนั้นก็ต้องยอมรับความเสี่ยงด้านชื่อเสียงที่ตามมาด้วย
สำหรับบริษัทเชิงพาณิชย์ การกดดันให้แก้เร็วเป็นเรื่องสมเหตุสมผล แต่การคาดหวังแบบเดียวกันจาก OSS ที่ขับเคลื่อนด้วยอาสาสมัคร นั้นไม่สมจริง
ว่ากันว่าเกิดขึ้นเฉพาะใน 10–20 เฟรมแรกของเกมจากปี 1995 เท่านั้น จึงรู้สึกว่าการจัดเป็น ‘ความรุนแรงระดับปานกลาง’ นั้นเกินจริงไป
ดูเป็นตัวอย่างของการทำให้ผู้ดูแลรักษาเสียเวลาเปล่า
ถ้าเป็นปัญหาร้ายแรง ไม่ว่าใครแจ้งมาก็ควรได้รับการรับฟัง แต่ถ้าเป็นรายงานจุกจิกหรือผิดพลาดก็เมินได้
สุดท้ายแล้วโครงการต้องเป็นฝ่ายตัดสินเองว่าจะเลือกแก้บั๊กไหน
ฉันสนับสนุนจุดยืนของทีม FFmpeg หลายบริษัทใช้ FOSS แค่เพื่อ ฟอกภาพลักษณ์ทางการตลาด แต่ในทางปฏิบัติกลับไม่ค่อยมีส่วนร่วมอะไร
ถ้าเป็นสมัยก่อน คนกลุ่มนี้อาจแค่ละเมิดลิขสิทธิ์ แต่ตอนนี้ได้อาศัยไลเซนส์มาใช้งานแบบไม่รู้สึกผิดแทน
การทดสอบแม้กระทั่งโคเด็กที่ไม่ได้ใช้ภายในบริษัทก็เป็นประโยชน์ต่อสาธารณะล้วน ๆ
แน่นอนว่า Google มีศักยภาพจะสนับสนุนเงินให้ FFmpeg มากกว่านี้ แต่ฉันไม่เห็นด้วยกับการให้เงินตรงกับผู้ดูแลรักษาคนนี้ในกรณีนี้
มันเปิดให้ใช้ได้อย่างเสรี แต่ก็เปิดช่องให้ถูกเอาเปรียบได้มากเช่นกัน
แม้ GPL 3 จะถูกวิจารณ์ว่าหนักมือเกินไป แต่ก็อย่างน้อยมีเจตนาจะป้องกันการเอาเปรียบ
มีคนกลุ่มหนึ่งที่สร้างซอฟต์แวร์ซึ่งกำหนดยุคสมัยโดยไม่คิดเงิน และอีกกลุ่มคือบริษัทที่ใช้มันเพื่อ สกัดมูลค่าทุกอย่างออกไป
กลุ่มแรกขับเคลื่อนด้วยความรัก ส่วนกลุ่มหลังขับเคลื่อนด้วยธุรกรรม
สำหรับบริษัทใหญ่ การเปิดเผยช่องโหว่ต่อสาธารณะเป็นสิ่งจำเป็น แต่กับ OSS ที่ขาดแคลนทรัพยากร มันอาจสร้างความเสี่ยงมากกว่า
ถ้า Google ต้องการให้มีการแก้ไขเร็วขึ้น การ ส่งแพตช์มาด้วย ก็จะเป็นประโยชน์กับทุกฝ่าย
โดยเฉพาะถ้าเป็น ช่องโหว่ที่ LLM สามารถค้นพบได้ ก็มีโอกาสสูงว่าสักวันจะถูกนำไปใช้โจมตี
การเปิดเผยทำให้ผู้ใช้สามารถป้องกันตัวเองได้ และการที่ FFmpeg ตัดสินใจจะแก้ก็เป็นการเลือกด้วยความสมัครใจ
งานวิจัยด้านความปลอดภัยในตัวมันเองก็เป็น รูปแบบหนึ่งของการมีส่วนร่วมที่มีต้นทุนสูง ต่อโอเพนซอร์ส
การบอกนักวิจัยว่า “คุณมีส่วนร่วมไม่พอ” กลับคล้ายกับการเรียกร้องให้อาสาสมัครทำงานฟรีเสียเอง
ความโปร่งใสของ FOSS กลับช่วยให้ผู้คนตระหนักเรื่องความปลอดภัยมากขึ้น
ซึ่งไม่ยอมรับพื้นที่สีเทาในโลกความจริง
ถ้า “อีเมลหนึ่งฉบับหยุดสายผลิตภัณฑ์ได้สามตัว” จริง ฉันคิดว่า เงินสนับสนุนราว 10,000–20,000 ดอลลาร์ต่อปี ก็ถือเป็นค่าเบี้ยประกันที่คุ้มแล้ว
ถ้า Google กับ Amazon สนับสนุนกันคนละ 50,000 ดอลลาร์ FFmpeg ก็น่าจะทำให้ทีมพัฒนาทำงานได้มั่นคงขึ้น
โดยเฉพาะ Google ที่ดูแล YouTube น่าจะจ่ายระดับ 100,000–200,000 ดอลลาร์ได้สบาย ๆ
ขอแชร์ เธรดบน Twitter ที่หัวหน้าฝ่ายความปลอดภัยของ Google สรุปรายการการมีส่วนร่วมต่อ FFmpeg
บริษัทมูลค่าระดับล้านล้านดอลลาร์จะบอกว่าขาดคนหรือขาดเงินนั้นฟังไม่ขึ้น
ฉันสงสัยว่าเป้าหมายของ Project Zero คืออะไรกันแน่
อยากรู้ว่ามีเหตุผลมากกว่าแค่การหาช่องโหว่หรือไม่
ขณะเดียวกันก็เป็นผลดีต่อ การดึงดูดบุคลากรด้านความปลอดภัยและการบริหารชื่อเสียง
แต่ถ้ามีทรัพยากรมากพอจะทำแบบนั้นได้ ก็น่าจะลงทุนกับการเขียนแพตช์ด้วยเช่นกัน
ช่องโหว่ที่เป็นประเด็นคือ Use After Free และ AI ของ Google เป็นคนพบมัน
แต่การแก้เรื่องนี้อาจใช้เวลาไม่ถึง 3 วินาทีด้วยซ้ำ
บริษัทที่มีเงินล้นเหลือแต่โยน รายงานบั๊กลักษณะสแปม ใส่โครงการอาสาสมัครนั้นน่าหงุดหงิด
ไม่น่าถึงขั้นต้องจัดเป็น CVE แค่รายงานบั๊กธรรมดาก็น่าจะพอ
ถ้าจะป้องกัน memory leak ก็จำเป็นต้องแก้ที่ซับซ้อนกว่านั้น
บางทีแนวทางที่ถูกต้องอาจเป็นการ ปิดใช้งานโคเด็กนี้โดยค่าเริ่มต้น
ให้อะไรกินแล้วกลับมาทวงเอาห่อผ้าเลยนะ
รายงานบั๊กก็น่าจะเป็นการมีส่วนร่วมที่สำคัญอย่างแน่นอนเหมือนกัน...
ให้ความรู้สึกประมาณว่ามีใครสักคนอาสาออกมาช่วยทำความสะอาดชุมชน แต่เจ้าถิ่นผู้ทรงอิทธิพลที่ถือครองที่ดินในละแวกนั้นมากที่สุดกลับไปบอกคนที่กำลังเก็บกวาดว่า ตรงมุมนั้นมีก้นบุหรี่อยู่ครับ
ผมก็คิดว่าอุปมานี้ตรงเหมือนกันนะ
เป็นการเปรียบเทียบที่เหมาะสม
มันสมควรโดนจริงเหรอ? อ่านดูแล้วก็เป็นช่องโหว่ความปลอดภัยระดับกลางที่มีผลเฉพาะใน 10–20 เฟรมแรกของเกมบางเกมแบบเฉพาะเจาะจงมากเท่านั้น แบบนี้คุณคิดจริง ๆ เหรอว่านี่เป็นการมีส่วนร่วมที่สำคัญต่อฝั่ง FFmpeg? การสนับสนุนที่สำคัญที่สุดต่อชุมชนโอเพนซอร์สน่าจะเป็นการช่วยอุดหนุนให้พัฒนาต่อได้อย่างมั่นคง โดยเฉพาะถ้าเป็นบริษัทที่ใช้งานผลงานนั้นอยู่มาก ก็น่าจะให้ความสำคัญกับเรื่องนั้นก่อนนะ?
ก็เพราะคนแบบนี้นี่แหละ ถึงมีการฝังแบ็กดอร์ลงไปใน XZ
รายงานบั๊กเองก็ถือว่าระดับ S จริงอยู่ แต่พอเอาเรื่องที่ไม่สามารถรับมือช่องโหว่ร้ายแรงของฟอร์แมตวิดีโอที่ใช้กันมาตั้งแต่สมัยประธานาธิบดีเคนเนดีได้ภายในเวลาที่กำหนดไปเที่ยวป่าวประกาศเสียทั่ว มันก็เป็นอีกเรื่องหนึ่ง
ไม่ได้ให้ของที่กินได้ แต่ยื่นของที่จำเป็นต้องกินมาให้ แล้วก็ถามว่าทำไมถึงกินไม่ทันภายในเวลา
ffmpeg มีบุคลากรจำกัด แต่ Google กลับเทรายงานบั๊กหลายสิบรายการของฟอร์แมตที่ทุกวันนี้แทบไม่ได้ใช้แล้วด้วย AI แล้วกดดันให้แก้ทั้งหมดภายในเวลาที่กำหนด แบบนี้มันถูกต้องหรือ?