ไม่ควรมอง Trusted Publishing ของ PyPI เป็นสัญญาณความน่าเชื่อถือของแพ็กเกจ

 (blog.yossarian.net)
3 คะแนน โดย GN⁺ 3 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • “ความน่าเชื่อถือ” ใน Trusted Publishing ไม่ได้หมายความว่ามนุษย์ควรเชื่อถือแพ็กเกจนั้นได้ แต่หมายถึงความสัมพันธ์ด้านการยืนยันตัวตนสำหรับการอัปโหลด ระหว่าง ตัวตนของเครื่อง ภายนอก เช่น CI/CD กับ package index
  • การทำงานของ PyPI สร้างอยู่บน OIDC federation โดยออก credential สำหรับการเผยแพร่ที่มีอายุสั้นและขอบเขตแคบ แทน API token ระยะยาว เพื่อลดการเปิดเผย credential ที่มีอายุยาวและสิทธิ์เกินจำเป็น
  • หลังจาก PyPI เปิดตัวในปี 2023 แนวทางนี้แพร่ไปยัง npm, RubyGems, crates.io, NuGet ฯลฯ แต่ความซับซ้อนของ data model, การจัดการที่แตกต่างกันตามผู้ให้บริการ OIDC และความเป็นไปได้ที่ CI/CD จะถูกเจาะยังคงอยู่
  • PyPI ไม่เน้นสถานะ Trusted Publishing ด้วย เครื่องหมายถูกสีเขียว บนหน้าโปรเจกต์ แต่แสดงเป็น metadata แบบ Yes/No ธรรมดาในรายละเอียดไฟล์เท่านั้น เพื่อลดโอกาสถูกเข้าใจผิดว่าเป็นสัญญาณด้านความปลอดภัย
  • Trusted Publishing และ PyPI attestations บอกได้เพียงว่าเป็นการยืนยันตัวตนสำหรับการอัปโหลด หรือมีการเซ็นตามตัวตนของเครื่องหรือไม่ และไม่สามารถใช้ตัดสินความปลอดภัยหรือคุณภาพของแพ็กเกจได้ จนกว่าจะมีการเชื่อถือตัวตนนั้นแยกต่างหาก

ขอบเขตของความน่าเชื่อถือที่ Trusted Publishing จัดการ

  • Trusted Publishing ไม่ใช่ฟีเจอร์ที่บอกให้มนุษย์เชื่อถือแพ็กเกจ แต่เป็นวิธีการยืนยันตัวตนที่จัดการ ความน่าเชื่อถือระหว่างเครื่อง
  • หากมอง Trusted Publishing เป็นประเด็นว่ามนุษย์เชื่อถือได้หรือไม่ได้ ก็ถือว่าเป็นการจัดหมวดหมู่ผิด
  • แก่นสำคัญคือการสร้างความสัมพันธ์ด้านความน่าเชื่อถือเพื่อยืนยันตัวตนสำหรับการอัปโหลด ระหว่างตัวตนของเครื่องภายนอก เช่น workflow ของ CI/CD กับตัวตนของโปรเจกต์ใน package index

โครงสร้าง Trusted Publishing ของ PyPI

  • “Trusted Publishing” เป็นคำที่ PyPI ใช้อธิบายวิธีการยืนยันตัวตนบน OpenID Connect federation
  • PyPI เปิดตัวสิ่งนี้ในปี 2023 และหลังจากนั้น npm, RubyGems, crates.io, NuGet ฯลฯ ก็รับไปใช้ด้วย
  • จุดเริ่มต้นมาจากปัญหาสองข้อ
    • API token ของ index ซึ่งเป็น credential ระยะยาว จัดการให้ปลอดภัยได้ยาก และผู้ใช้มักกำหนดสิทธิ์ขั้นต่ำกับระยะเวลาหมดอายุได้ยาก จึงมีแนวโน้มถูกตั้งค่าให้มีสิทธิ์เกินจำเป็น
    • ผู้ใช้จำนวนมากสร้าง credential เพื่อใส่ไว้ในแพลตฟอร์ม CI/CD และแพลตฟอร์ม CI/CD เองก็มีกลไกผ่าน OIDC เพื่อพิสูจน์การควบคุมตัวตนของเครื่องเฉพาะเจาะจง
  • ผู้ใช้ลงทะเบียน Trusted Publisher ซึ่งเป็นตัวตนของเครื่อง CI/CD ไว้ครั้งเดียวใน package index และเมื่อ CI/CD แสดง identity token ทาง index จะตรวจสอบและออก credential สำหรับการเผยแพร่ที่มีอายุสั้นและขอบเขตแคบให้

ข้อดีและข้อจำกัดที่ยังเหลืออยู่

  • วิธีใช้ credential ที่มีอายุสั้นและกำหนดขอบเขตในตัวเองถือเป็นแนวทางที่ประสบความสำเร็จอย่างมากสำหรับผู้ใช้ PyPI
    • ผู้ใช้ชอบแนวทางที่ไม่ต้องจัดการ credential เองเมื่อไม่จำเป็น
    • โปรเจกต์โอเพนซอร์สขนาดใหญ่และองค์กรต่าง ๆ ชอบคุณสมบัติที่สิทธิ์ในการเผยแพร่ผูกกับ ตัวตนของแหล่งที่มา ไม่ใช่กับ maintainer รายบุคคล
  • Trusted Publishing ยังมีความซับซ้อนเชิงโครงสร้างเหลืออยู่
    • “pending publishers” ของ PyPI ช่วยแก้ปัญหาโปรเจกต์ที่ยังไม่มีอยู่จริง แต่ทำให้ data model ซับซ้อนขึ้น และสร้างความสับสนให้ผู้ใช้มากกว่า Trusted Publishing ทั่วไป
    • ผู้ให้บริการ OIDC สามารถใส่ค่าหลากหลายลงใน claim set นอกเหนือจาก claim บางส่วนที่ใช้ร่วมกันได้ ทำให้ index ต้องจัดการรูปแบบเฉพาะของผู้ให้บริการแต่ละรายแยกกัน
    • ด้วยเหตุนี้ ตัวตนของเครื่องจึงไม่สามารถใช้แทนกันได้ระหว่าง OIDC IdP ต่าง ๆ และเป็นหนึ่งในเหตุผลที่ PyPI เพิ่มผู้ให้บริการ Trusted Publishing รายใหม่อย่างค่อยเป็นค่อยไป
  • หาก workflow ของ CI/CD ถูกเจาะ ผู้โจมตีอาจรั่วไหล credential ของ Trusted Publishing หรือ OIDC ID token ที่เป็นเมล็ดตั้งต้นของมันได้
    • คล้ายกับกรณีที่มี credential ระยะยาวอยู่ใน workflow แต่ credential ของ Trusted Publishing ไม่มีความเสี่ยงด้านขอบเขตและอายุการใช้งานแบบเดียวกัน
    • PyPI ลดความเสี่ยงจากการเจาะ CI/CD โดยปฏิเสธการแลก token สำหรับตัวตนของเครื่องที่สอดคล้องกับ trigger ที่ถูกนำไปใช้ในทางที่ผิดได้ง่าย เช่น pull_request_target

เหตุผลที่ไม่ใช่สัญญาณความน่าเชื่อถือของแพ็กเกจ

  • Trusted Publishing เป็นเพียง วิธีการยืนยันตัวตน และไม่ได้ให้ข้อมูลว่าแพ็กเกจปลอดภัยหรือไม่ มีคุณภาพสูงหรือไม่ หรือน่าใช้หรือไม่
  • PyPI เป็น index สาธารณะ ทุกคนจึงอัปโหลดได้ และทุกคนก็สามารถใช้ Trusted Publisher เพื่ออัปโหลดได้
    • แม้ใช้ Trusted Publisher ก็ยังอัปโหลดมัลแวร์หรือโค้ดที่มีช่องโหว่ได้
    • ในแง่นี้เหมือนกับ API token ซึ่งเป็นวิธีการยืนยันตัวตนสำหรับอัปโหลดแบบอื่นของ PyPI
  • Trusted Publishing ไม่ใช่ข้อบังคับใน PyPI และในอนาคตก็ไม่อาจกลายเป็นข้อบังคับได้
    • การบังคับให้ผู้ใช้ใช้ Trusted Publishing เป็นไปไม่ได้ในเชิงวิศวกรรม และไม่พึงประสงค์ทั้งในเชิงเทคนิคและสังคม
    • Trusted Publishing จะเป็นตัวเลือกเสมอ

วิธีที่ UI ของ PyPI ลดความเข้าใจผิด

  • PyPI ระมัดระวังไม่ให้ผู้ใช้เข้าใจสถานะ Trusted Publishing ผิดว่าเป็นสัญญาณความน่าเชื่อถือของแพ็กเกจ
  • บนหน้าโปรเจกต์ไม่มี เครื่องหมายถูกสีเขียว ที่แสดงสถานะ Trusted Publishing
  • เครื่องหมายถูกสีเขียวสำหรับสถานะที่ผู้ใช้ควบคุมได้ จะใช้เฉพาะกับลิงก์ที่ PyPI พิสูจน์ได้ว่ามาจากแหล่งเดียวกับตัวแพ็กเกจเอง
  • URL ที่ผ่านการตรวจสอบพิสูจน์ได้เพียงว่า ณ เวลาที่ตรวจสอบ URL นั้นอยู่ภายใต้การควบคุมของเจ้าของแพ็กเกจ PyPI และไม่ได้หมายถึงความปลอดภัยเพิ่มเติมของ URL หรือโปรเจกต์
  • สถานะ Trusted Publishing ของไฟล์เฉพาะจะแสดงในรายละเอียดไฟล์เป็นค่า Yes/No ธรรมดา
    • พื้นที่ metadata ของไฟล์ไม่ได้ถูก render ให้ดูเหมือนข้อมูลสำคัญต่อการตัดสินความน่าเชื่อถือของผู้ใช้
    • แม้แต่ JSON blob ที่มาจาก user agent ของ upload client ก็ยังไม่ได้ render อย่างเหมาะสม

การแยกออกจาก attestations

  • ประเด็นนี้แยกต่างหากจาก attestations ของ PyPI
  • attestations ในปัจจุบันก็ใช้ตัวตนของเครื่อง OIDC แต่ไม่ใช่ สัญญาณความน่าเชื่อถือ
  • attestation คล้ายกับการเซ็นบนตัวตนของเครื่อง แต่เนื่องจากทุกคนสามารถอัปโหลดไปยัง PyPI ได้ ทุกคนจึงสามารถเซ็นด้วยตัวตนของเครื่องที่ตนควบคุมได้
  • การมี Trusted Publisher ไม่ได้หมายความว่าจะต้องมี attestation เสมอไป และการมี attestation ก็ไม่ได้หมายความว่าผู้ใช้ปลายทางควรเชื่อถือตัวตนใดตัวตนหนึ่ง
  • โมเดลความน่าเชื่อถือของ attestation ใน PyPI ก็บันทึกเรื่องนี้ไว้ในเอกสารเช่นกัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 일 전
ความคิดเห็นบน Lobste.rs

  • เป็นบทความที่ดี Trusted Publishing กับ การรับรอง (attestation) ให้การรับประกันที่แตกต่างกันต่อโหมดความล้มเหลวที่ต่างกัน และทั้งสองอย่างก็แยกจากสิ่งที่ผู้ใช้ส่วนใหญ่เรียกว่า “ความไว้วางใจ”

  • ที่ Trusted Publishing เป็นไปได้ ก็เพราะในช่วง 15 ปีที่ผ่านมา โปรเจกต์โอเพนซอร์สจำนวนมากย้ายจากการ โฮสต์เอง เช่น เมลลิงลิสต์, Git repository, bug tracker, build server ไปอยู่บน forge แบบรวมศูนย์
    ตอนนี้เมื่อข้อเสียของ forge แบบรวมศูนย์ชัดเจนขึ้น โปรเจกต์ต่าง ๆ ก็เริ่มกลับมาพิจารณาการโฮสต์เองอีกครั้ง
    ในทศวรรษ 2010 ความสะดวกและผลของโซเชียลเน็ตเวิร์กผลักให้โปรเจกต์เข้าไปอยู่ใน forge แบบรวมศูนย์ แต่ตอนนี้มีปัจจัยที่ผูกโปรเจกต์ไว้มากขึ้นมาก รวมถึง Trusted Publishing ด้วย
    อย่าไว้ใจผู้มีอำนาจ — จงส่งเสริมการกระจายศูนย์
    — "The Hacker Ethics", Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)

    • Trusted Publishing ไม่มี การผูกติด (lock-in) อยู่เลย สามารถใช้วิธียืนยันตัวตนอื่นได้ตลอดเวลา รวมถึงโฮสต์ที่ PyPI สามารถเชื่อมต่อด้วยได้
      มีความย้อนแย้งอยู่เล็กน้อยในการเรียกการยืนยันตัวตนแบบสหพันธ์ว่าเป็นรูปแบบหนึ่งของการผูกติด
    • การโฮสต์เองแทบจะเป็นรสนิยมของคนส่วนน้อยมาโดยตลอด จุดประสงค์ของ SourceForge ก็คือการรับภาระนั้นแทน
      ในช่วงเวลาใกล้เคียงกันราว 25 ปีก่อน ก็มี ASF อยู่ด้วย แต่ ASF ก็มีภาระด้าน governance มากเช่นกัน ก่อนหน้านั้นมีโครงการ GNU ซึ่งเน้นอุดมการณ์ซอฟต์แวร์เสรีมากกว่า และให้ความสำคัญกับบริการโฮสต์โปรเจกต์อย่างเป็นระบบน้อยกว่า เพราะ GNU มีมาก่อนที่จะมีแนวคิดชัดเจนว่าโปรเจกต์ซอฟต์แวร์เสรีต้องการบริการแบบใด
      โปรเจกต์ซอฟต์แวร์เสรีในทศวรรษ 1990 มักอยู่บนบริการ time-sharing ของมหาวิทยาลัย หรือบนเซิร์ฟเวอร์ colocation ของเพื่อน เช่น PuTTY หรือ Hyperreal.org ที่เคยโฮสต์ Apache httpd ก่อนยุค ASF
      มีโปรเจกต์ไม่มากที่เติบโตจนถึงขั้นคุ้มค่ากับการมีโครงสร้างพื้นฐานของตัวเอง และโฮสติ้งราคาถูกก็เพิ่งเป็นไปได้ค่อนข้างไม่นานมานี้
    • มีเหตุผลอะไรที่ Forgejo ที่โฮสต์เอง จะทำ Trusted Publishing ไม่ได้หรือเปล่า? ถ้ามี ก็คงเป็นสิ่งที่ผมพลาดไป