Không nên xem Trusted Publishing là tín hiệu tin cậy của gói
(blog.yossarian.net)- “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 tải lên giữa 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 hợp 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, qua đó giảm nguy cơ lộ thông tin xác thực dài hạn hoặc có quá nhiều quyền
- Sau khi PyPI công bố vào năm 2023, cơ chế này đã lan sang npm, RubyGems, crates.io, NuGet…, 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 theo 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 tệp, 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 tải lên hoặc ký dựa trên danh tính máy; nếu chưa 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 vào 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 nhìn Trusted Publishing như vấn đề con người có nên tin hay không, thì đã đặt sai phạm trù
- Trọng tâm là thiết lập quan hệ tin cậy để xác thực tải lên 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 hợp OpenID Connect
- PyPI công bố cơ chế này vào năm 2023, sau đó npm, RubyGems, crates.io, NuGet và các hệ sinh thái khác 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 dễ cấu hình quá nhiều 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 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ự giới hạn 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 gắn với danh tính nguồn, thay vì một maintainer cá nhân
- Trusted Publishing vẫn còn độ phức tạp mang tính 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à gây khó hiểu cho người dùng 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 dạng đặ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 OIDC ID token làm “hạt giống” cho chúng
- Điều 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à thời hạn
- 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 của 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, nên ai cũng có thể tải lên, và ai cũng có thể dùng Trusted Publisher để tải lên
- Mã độc hoặc mã dễ bị tổn thương vẫn có thể được tải lên bằng Trusted Publisher
- Về điểm này, nó giống API token, một phương thức xác thực tải lên khác của PyPI
- Trên PyPI, Trusted Publishing không bắt buộc và cũng không thể trở thành bắt buộc trong tương lai
- Ép người dùng dùng Trusted Publishing là bất khả thi về mặt kỹ thuật, đồng thời cũng không đáng mong muốn về mặt kỹ thuật lẫn xã hội
- Trusted Publishing luôn là tùy chọn
Cách UI của PyPI giảm hiểu nhầm
- PyPI thậ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 của gói
- Trên trang dự án không có dấu tick xanh thể hiện 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 các 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 ý mức độ an toàn bổ sung nào cho URL hay dự án
- Trạng thái Trusted Publishing của một tệp cụ thể được hiển thị trong chi tiết tệp dưới dạng giá trị Yes/No đơn giản
- Khu vực metadata của tệp 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 tải lên 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ể tải lên PyPI, nên ai cũng có thể ký bằng danh tính máy mà họ kiểm soát
- Có Trusted Publisher không có nghĩa là nhất định 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
1 bình luận
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)
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.
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.