Không nên xem Trusted Publishing của PyPI là tín hiệu tin cậy cho gói

• “Tin cậy” trong Trusted Publishing không có nghĩa là con người có thể tin vào gói, mà chỉ quan hệ xác thực upload giữa một danh tính máy bên ngoài như CI/CD và chỉ mục gói
• Cách triển khai của PyPI hoạt động trên liên kết OIDC, cấp thông tin xác thực phát hành ngắn hạn và phạm vi hẹp thay cho token API dài hạn, giúp giảm nguy cơ lộ thông tin xác thực dài hạn và quá quyền
• Sau khi PyPI công bố vào năm 2023, cơ chế này đã lan sang npm, RubyGems, crates.io, NuGet, v.v., nhưng vẫn còn các vấn đề như độ phức tạp của mô hình dữ liệu, xử lý riêng cho từng nhà cung cấp OIDC và khả năng CI/CD bị xâm phạm
• PyPI không nhấn mạnh trạng thái Trusted Publishing bằng dấu tick xanh trên trang dự án, mà chỉ hiển thị dưới dạng metadata Yes/No đơn giản trong chi tiết file, nhằm giảm khả năng bị hiểu nhầm là tín hiệu an toàn
• Trusted Publishing và PyPI attestations chỉ cho biết việc xác thực upload hoặc có chữ ký dựa trên danh tính máy hay không; trước khi bạn tin cậy riêng danh tính đó, chúng không thể dùng để đánh giá độ an toàn hay chất lượng của gói

---

Phạm vi “tin cậy” mà Trusted Publishing xử lý

• Trusted Publishing không phải là tính năng bảo con người hãy tin cậy một gói, mà là phương thức xác thực xử lý niềm tin giữa các máy
• Nếu xem Trusted Publishing như vấn đề con người có thể tin hay không tin, thì đã đặt sai phạm trù
• Điểm cốt lõi là thiết lập một quan hệ tin cậy dùng cho xác thực upload giữa danh tính máy bên ngoài như workflow CI/CD và danh tính dự án trên chỉ mục gói

Cấu trúc Trusted Publishing của PyPI

• “Trusted Publishing” là thuật ngữ PyPI dùng để mô tả phương thức xác thực trên nền liên kết OpenID Connect
• PyPI công bố cơ chế này vào năm 2023, và sau đó npm, RubyGems, crates.io, NuGet cũng đã áp dụng
• Điểm xuất phát là hai vấn đề
  • Token API của chỉ mục, vốn là thông tin xác thực dài hạn, khó quản lý an toàn; người dùng cũng khó đặt quyền tối thiểu và thời hạn hết hạn, nên chúng dễ bị cấu hình quá quyền
  • Nhiều người dùng tạo thông tin xác thực để đưa vào nền tảng CI/CD, trong khi các nền tảng CI/CD cũng có cơ chế chứng minh quyền kiểm soát một danh tính máy cụ thể thông qua OIDC
• Người dùng đăng ký một lần Trusted Publisher, tức danh tính máy CI/CD, với chỉ mục gói; khi CI/CD xuất trình token danh tính, chỉ mục sẽ xác minh token đó và cấp thông tin xác thực phát hành ngắn hạn, phạm vi hẹp

Lợi ích và các giới hạn còn lại

• Cách dùng thông tin xác thực ngắn hạn, tự xác định phạm vi được đánh giá là một hướng tiếp cận rất thành công với người dùng PyPI
  • Người dùng thích cách không phải tự quản lý thông tin xác thực khi không cần thiết
  • Các dự án mã nguồn mở lớn và doanh nghiệp thích thuộc tính trong đó quyền phát hành được gắn với danh tính nguồn, thay vì maintainer cá nhân
• Trusted Publishing vẫn còn độ phức tạp về mặt cấu trúc
  • “pending publishers” của PyPI giải quyết vấn đề dự án chưa tồn tại, nhưng làm mô hình dữ liệu phức tạp hơn và khiến người dùng dễ bối rối hơn so với Trusted Publishing thông thường
  • Ngoài một số claim chung, nhà cung cấp OIDC có thể đưa nhiều giá trị khác nhau vào claim set, nên chỉ mục phải xử lý riêng hình thức đặc thù của từng nhà cung cấp
  • Vì vậy, danh tính máy không thể thay thế lẫn nhau giữa các OIDC IdP, và đây là một trong những lý do PyPI bổ sung nhà cung cấp Trusted Publishing mới một cách chậm rãi
• Nếu workflow CI/CD bị xâm phạm, kẻ tấn công có thể làm lộ thông tin xác thực Trusted Publishing hoặc token ID OIDC là “hạt giống” tạo ra chúng
  • Trường hợp này tương tự khi thông tin xác thực dài hạn nằm trong workflow, nhưng thông tin xác thực Trusted Publishing không có cùng rủi ro về phạm vi và vòng đời
  • PyPI giảm thiểu rủi ro CI/CD bị xâm phạm bằng cách từ chối trao đổi token cho các danh tính máy tương ứng với những trigger dễ bị lạm dụng như pull_request_target

Vì sao đây không phải tín hiệu tin cậy cho gói

• Trusted Publishing chỉ là phương thức xác thực, không cung cấp thông tin về việc gói có an toàn, chất lượng cao hay đáng dùng hay không
• PyPI là chỉ mục công khai, ai cũng có thể upload, và ai cũng có thể upload bằng Trusted Publisher
  • Mã độc hoặc mã có lỗ hổng cũng có thể được upload bằng Trusted Publisher
  • Về điểm này, nó giống với token API, một phương thức xác thực upload khác của PyPI
• Trusted Publishing không bắt buộc trên PyPI, và trong tương lai cũng không thể trở thành bắt buộc
  • Buộc người dùng dùng Trusted Publishing là điều không khả thi về mặt kỹ thuật triển khai, đồng thời cũng không mong muốn về mặt kỹ thuật lẫn xã hội
  • Trusted Publishing sẽ luôn là tùy chọn

Cách UI của PyPI giảm hiểu nhầm

• PyPI cẩn trọng để người dùng không hiểu nhầm trạng thái Trusted Publishing là tín hiệu tin cậy cho gói
• Trang dự án không có dấu tick xanh biểu thị trạng thái Trusted Publishing
• Dấu tick xanh cho trạng thái do người dùng kiểm soát chỉ được dùng cho những liên kết mà PyPI có thể chứng minh là đến từ cùng nguồn với chính gói
• URL đã xác minh chỉ chứng minh rằng tại thời điểm xác minh, URL đó nằm dưới quyền kiểm soát của chủ sở hữu gói PyPI; nó không hàm ý thêm độ an toàn nào cho URL hay dự án
• Trạng thái Trusted Publishing của một file cụ thể được hiển thị trong chi tiết file dưới dạng giá trị Yes/No đơn giản
  • Khu vực metadata của file không được render như thông tin quan trọng cho phán đoán tin cậy của người dùng
  • JSON blob lấy từ user agent của client upload cũng không được render tử tế

Phân biệt với attestations

• Luận điểm này tách biệt với attestations của PyPI
• Attestations hiện cũng dùng danh tính máy OIDC, nhưng không phải là tín hiệu tin cậy
• Attestation giống như chữ ký trên danh tính máy, nhưng vì ai cũng có thể upload lên PyPI, ai cũng có thể ký bằng danh tính máy do mình kiểm soát
• Có Trusted Publisher không có nghĩa là nhất thiết có attestation, và có attestation cũng không có nghĩa là người dùng cuối có thể tin cậy một danh tính cụ thể
• Mô hình độ tin cậy của attestation trên PyPI cũng ghi rõ điểm này

[GN⁺]

Các ý kiến trên Lobste.rs

• Bài viết hay. Trusted Publishing và chứng thực (attestation) cung cấp những bảo đảm khác nhau cho các chế độ lỗi khác nhau, và cả hai cũng tách biệt với thứ mà đa số người dùng gọi là niềm tin.

• Trusted Publishing trở nên khả thi vì trong 15 năm qua, nhiều dự án mã nguồn mở đã chuyển từ tự host như mailing list, kho Git, trình theo dõi lỗi, máy chủ build sang các forge tập trung.
  Giờ đây, khi nhược điểm của các forge tập trung trở nên rõ ràng hơn, các dự án lại cân nhắc tự host.
  Trong thập niên 2010, sự tiện lợi và hiệu ứng mạng xã hội đã đẩy các dự án vào các forge tập trung, nhưng giờ đây có nhiều yếu tố hơn nhiều giữ chân dự án ở đó, bao gồm cả Trusted Publishing.
  Hãy nghi ngờ quyền lực — thúc đẩy phi tập trung hóa
  — “The Hacker Ethics”, Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)

  • Trusted Publishing không có khóa chân (lock-in). Có thể dùng phương thức xác thực khác bất cứ lúc nào, kể cả các host mà PyPI có thể tích hợp.
    Có chút mỉa mai khi gọi xác thực liên hợp là một dạng khóa chân.
  • Tự host trên thực tế gần như luôn là lựa chọn của thiểu số. Mục đích của SourceForge chính là gánh thay phần phiền toái đó.
    Gần cùng thời điểm, khoảng 25 năm trước, cũng có ASF, nhưng ASF cũng mang nhiều gánh nặng quản trị. Trước đó có dự án GNU, nhấn mạnh hơn vào lý tưởng phần mềm tự do và ít tập trung hơn vào dịch vụ hosting dự án có hệ thống. Bởi GNU đã tồn tại từ trước khi có một khái niệm rõ ràng về những dịch vụ mà một dự án phần mềm tự do cần.
    Các dự án phần mềm tự do trong thập niên 1990 thường được đặt trên dịch vụ chia sẻ thời gian của trường đại học hoặc máy chủ colocated của bạn bè. Ví dụ như PuTTY hay Hyperreal.org, nơi từng host Apache httpd trước ASF.
    Hiếm có dự án nào lớn đến mức biện minh được cho hạ tầng riêng, và hosting giá rẻ cũng chỉ mới trở nên khả thi tương đối gần đây.
  • Có lý do gì khiến Forgejo tự host không thể làm Trusted Publishing không? Nếu có thì có lẽ tôi đang bỏ sót điều gì đó.