YAML Anchors ใน GitHub Actions ก่อให้เกิดความกังวลด้านความปลอดภัยและเครื่องมือวิเคราะห์

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

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

เครื่องมือวิเคราะห์ความปลอดภัยเผชิญกับความท้าทายใหม่

หนึ่งในความกังวลหลักที่ชุมชนยกขึ้นเกี่ยวข้องกับผลกระทบต่อเครื่องมือวิเคราะห์ความปลอดภัย เครื่องมือ static analysis ที่สแกน GitHub Actions workflows เพื่อหาช่องโหว่ต้องเผชิญกับอุปสรรคทางเทคนิคที่สำคัญเมื่อประมวลผล anchors ปัญหาเกิดจากวิธีที่ YAML parsers จัดการ anchors - โดยปกติพวกเขาจะทำให้เนื้อหาที่ anchor แบนราบในแต่ละตำแหน่งที่มีการอ้างอิง ทำให้เกือบเป็นไปไม่ได้ที่จะติดตามกลับไปยังตำแหน่งต้นฉบับ

สิ่งนี้สร้างปัญหาใหญ่สำหรับเครื่องมือความปลอดภัยที่ต้องการให้ข้อความแสดงข้อผิดพลาดและรายงานช่องโหว่ที่แม่นยำ เมื่อตรวจพบปัญหาความปลอดภัยในส่วน anchored เครื่องมือไม่สามารถชี้ผู้ใช้ไปยังคำจำกัดความ anchor ต้นฉบับได้อย่างง่ายดาย ทำให้การดีบักและการแก้ไขยากขึ้น

เครื่องมือและระบบนิเวศที่ได้รับผลกระทบ

• การวิเคราะห์ความปลอดภัย: zizmor , actionlint , claws , poutine
• ผลกระทบ: การแมปตำแหน่งที่มาของซอร์สโค้ดกลายเป็นเรื่องยาก
• พฤติกรรมของ Parser: YAML parser ส่วนใหญ่จะทำการ flatten anchor ในระหว่างการ deserialization
• ความเข้ากันได้: เครื่องมือต่างๆ ต้องได้รับการอัปเดตเพื่อจัดการกับการแก้ไข anchor

โซลูชันทางเลือกที่มีอยู่แล้ว

นักพัฒนาหลายคนในชุมชนชี้ให้เห็นว่า GitHub Actions มีกลไกหลายอย่างอยู่แล้วสำหรับการลดการซ้ำซ้อนของโค้ดโดยไม่ต้องใช้ YAML anchors ตัวแปรสภาพแวดล้อมระดับ workflow, reusable workflows และการกำหนดค่าระดับ job สามารถแก้ไขปัญหาการซ้ำซ้อนส่วนใหญ่ได้ในขณะที่ยังคงความชัดเจนและความปลอดภัย

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

แนวทางทางเลือกที่กล่าวถึง

• ภาษาการกำหนดค่า: Dhall , CUE
• การสร้างโค้ด: Python , Bash scripts ที่สร้าง YAML
• คุณสมบัติที่มีอยู่ใน GitHub: บล็อก env ระดับ workflow , reusable workflows , การกำหนดค่าระดับ job
• การทดสอบในเครื่อง: เครื่องมืออย่าง Earthly CI , act (มีข้อจำกัด)

ความกังวลด้านการใช้งานและฟีเจอร์ที่ขาดหายไป

สิ่งที่เพิ่มเชื้อเพลิงให้กับความขัดแย้งคือการใช้งาน YAML anchor functionality ที่ไม่สมบูรณ์ของ GitHub ในขณะที่พวกเขาสนับสนุน anchors และ references พื้นฐาน พวกเขาไม่รวม merge keys ซึ่งเป็นฟีเจอร์ที่จะช่วยให้รวมการกำหนดค่า anchored หลายตัวได้ การละเว้นนี้ทำให้นักพัฒนาหลายคนงุนงงเนื่องจาก merge keys แสดงถึงหนึ่งในกรณีการใช้งานไม่กี่กรณีที่ YAML anchors ให้คุณค่าเฉพาะที่ไม่สามารถทำซ้ำผ่านฟีเจอร์ GitHub Actions อื่นๆ ได้

ชุมชนยังได้ยกความกังวลเกี่ยวกับแนวทางของ GitHub ต่อการปฏิบัติตาม YAML แทนที่จะสนับสนุน YAML specification อย่างเต็มที่ GitHub ดูเหมือนจะใช้งาน custom subset ซึ่งอาจนำไปสู่ความสับสนและปัญหาความเข้ากันได้ในอนาคต

สถานะการรองรับ YAML Anchor

• Basic Anchors: รองรับโดย GitHub Actions
• References: รองรับโดย GitHub Actions
• Merge Keys: ไม่รองรับโดย GitHub Actions
• YAML Version: การใช้งานแบบกำหนดเองของ GitHub (ไม่ได้รองรับมาตรฐาน 1.1 หรือ 1.2 อย่างสมบูรณ์)

ผลกระทบต่อเครื่องมือนักพัฒนาและระบบนิเวศ

การเปลี่ยนแปลงส่งผลกระทบต่อเครื่องมือยอดนิยมจำนวนมากในระบบนิเวศ GitHub Actions เครื่องมือ linting, security scanners และ workflow analyzers ต้องคำนึงถึงการแก้ไข anchor เมื่อประมวลผลไฟล์ workflow สิ่งนี้แสดงถึงความท้าทายด้านวิศวกรรมที่สำคัญสำหรับผู้ดูแลเครื่องมือที่สร้างโซลูชันของพวกเขาบนสมมติฐานที่ง่ายกว่าเกี่ยวกับโครงสร้าง workflow

YAML anchors ทำให้นามธรรมของ workflows, jobs และ steps มัวหมองยิ่งขึ้น โดยการนำรูปแบบ global state แบบ cross-cutting ที่ไม่เล่นตามกฎของระบบส่วนที่เหลือ

นักพัฒนาบางคนแนะนำว่าแทนที่จะเพิ่มฟีเจอร์ YAML มากขึ้น อุตสาหกรรมควรเปลี่ยนไปใช้ภาษาโปรแกรมมิ่งจริงสำหรับการกำหนด CI/CD pipeline เครื่องมือเช่น Dhall, CUE หรือแม้แต่การสร้าง YAML จาก Python หรือภาษาที่คุ้นเคยอื่นๆ สามารถให้ความสามารถในการนามธรรมที่ดีกว่าในขณะที่ยังคงการทดสอบในท้องถิ่น

ชุมชนแบ่งแยกเกี่ยวกับประโยชน์ในทางปฏิบัติ

แม้จะมีความกังวลทางเทคนิค นักพัฒนาหลายคนยินดีต้อนรับ YAML anchors สำหรับประโยชน์ในทางปฏิบัติทันที workflows ที่ซับซ้อนด้วยบล็อกการกำหนดค่าที่ซ้ำกันสามารถบำรุงรักษาได้ดีขึ้นอย่างมากด้วย anchors โดยเฉพาะสำหรับสถานการณ์ที่เกี่ยวข้องกับสภาพแวดล้อมการปรับใช้หลายตัวหรือการกำหนดค่า job ที่คล้ายกัน

ฟีเจอร์นี้พิสูจน์ให้เห็นคุณค่าเป็นพิเศษสำหรับ path filters ใน workflows ที่รายการ path ไฟล์เดียวกันต้องการการอ้างอิงข้ามเงื่อนไข trigger หลายตัว ก่อนหน้านี้ นักพัฒนาต้องทำซ้ำรายการเหล่านี้หรือใช้ third-party actions เพื่อให้ได้ฟังก์ชันการทำงานที่คล้ายกัน

มองไปข้างหน้า

การถกเถียงเน้นย้ำคำถามที่กว้างขึ้นเกี่ยวกับทิศทางของเครื่องมือ CI/CD และการจัดการการกำหนดค่า ในขณะที่ YAML anchors แก้ไขจุดเจ็บปวดทันทีสำหรับผู้ใช้บางคน พวกเขายังแสดงถึงก้าวไปสู่ความซับซ้อนที่เพิ่มขึ้นในระบบนิเวศที่หลายคนพบว่าท้าทายในการดีบักและบำรุงรักษาอยู่แล้ว

ความขัดแย้งเน้นย้ำความตึงเครียดระหว่างการให้ฟีเจอร์ที่ทรงพลังและการรักษาความเรียบง่ายและความปลอดภัย ในขณะที่ GitHub Actions ยังคงพัฒนาต่อไป ชุมชนจะยังคงถกเถียงว่าฟีเจอร์เช่นนี้ปรับปรุงหรือทำให้ประสบการณ์ development workflow ซับซ้อนขึ้น

อ้างอิง: Dear GitHub: no YAML anchors, please