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

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

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

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

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

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

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

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

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

  • Trusted Publishing เป็นเพียง วิธีการยืนยันตัวตน เท่านั้น และไม่ได้ให้ข้อมูลว่าแพ็กเกจนั้นปลอดภัย มีคุณภาพสูง หรือควรใช้งานหรือไม่
  • PyPI เป็นดัชนีสาธารณะ ดังนั้นใครก็อัปโหลดได้ และใครก็ใช้ 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 แบบเรียบง่ายในหน้ารายละเอียดไฟล์
    • พื้นที่เมทาดาทาของไฟล์ไม่ได้ถูกแสดงผลในลักษณะที่ชวนให้มองว่าเป็นข้อมูลสำคัญต่อการตัดสินความเชื่อถือของผู้ใช้
    • แม้แต่ JSON blob ที่มาจาก user agent ของไคลเอนต์อัปโหลดก็ไม่ได้ถูกแสดงผลอย่างเด่นชัดเช่นกัน

ความแตกต่างจาก attestations

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

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

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

 
GN⁺ 5 시간 전
ความคิดเห็นบน 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 ไม่ได้หรือเปล่า? ถ้ามี ก็คงเป็นสิ่งที่ผมพลาดไป