Giả sử ứng dụng máy tính có trên cả trang phát hành và máy chủ phản chiếu. Tên tệp và số phiên bản khớp nhau, nhưng người dùng vẫn cần trả lời: đây có phải cùng tệp không, ai phát hành, có đến từ mã và quy trình dựng dự kiến không, có phù hợp để chạy trên thiết bị này không?
Các câu hỏi đó cần bằng chứng khác nhau. Gọi mọi phương pháp kiểm chứng là “chứng nhận bảo mật” tạo kỳ vọng mà chúng không đáp ứng được, và có thể khiến nhà phát triển bỏ qua thiếu sót trong quy trình phát hành.
Tổng kiểm trả lời tệp có khớp không
Tính hàm băm sau khi tải và so với giá trị dự kiến giúp xác định nội dung tệp có khớp không. Điều kiện quan trọng là giá trị dự kiến đến từ kênh đáng tin. Nếu cả tệp và tổng kiểm đều từ cùng trang chưa được kiểm chứng, việc chúng khớp không xác lập danh tính nhà phát hành.
Ngược lại, hàm băm khác nghĩa là tệp khác, nhưng tự nó không chứng minh ý đồ xấu. Bản dựng khác, đóng gói lại hoặc tải nhầm đều có thể gây khác biệt. Hãy ngừng coi tệp đó là bản phát hành đã xác minh và kiểm tra lại nguồn, nền tảng đích và bản ghi tổng kiểm tương ứng.
Nhà phát hành nên duy trì cùng nhau tên tệp rõ ràng, thông tin phiên bản và danh sách tổng kiểm. Không nên khiến người dùng phải chép hàm băm từ bài cũ để so với bộ cài cho nền tảng hoặc bản dựng khác.
Chữ ký cần kiểm tra đúng danh tính dự kiến
Chữ ký số liên kết bên ký với dữ liệu đã ký, nhưng kiểm chứng còn phải xác định danh tính đó có đúng như dự kiến không. Tài liệu Sigstore yêu cầu kiểm tra chữ ký cùng điều kiện danh tính và bên cấp liên quan, minh họa sự phân biệt này. Tài liệu kiểm chứng Sigstore
Khi thấy “chữ ký hợp lệ”, người dùng cũng nên xác định nó đại diện nhà phát hành hay quy trình nào. Nhà phát triển nên quy định danh tính nào được ký bản chính thức. Không phải mọi chữ ký vượt qua kiểm tra toán học đều tự biến tệp thành bản phát hành chính thức.
Khi đổi chứng thư hoặc cách ký, nhà phát hành cũng cần giải thích theo cách người dùng kiểm chứng được. Yêu cầu tin ngay một chứng thư lạ không phải quy trình cập nhật đầy đủ.
Nguồn gốc bản dựng nối gói phần mềm với quá trình sản xuất
Chứng thực hiện vật của GitHub có thể ghi nguồn gốc bản dựng, giúp kiểm tra quan hệ giữa hiện vật với kho mã và quy trình. Chúng cung cấp bằng chứng về cách tệp được tạo, nhưng vẫn cần kiểm tra hiện vật thật và danh tính dự kiến. Tài liệu chứng thực hiện vật GitHub
Các cấp bản dựng SLSA phân biệt thêm việc có bản ghi nguồn gốc, nguồn gốc có chữ ký do nền tảng lưu trữ tạo và bảo vệ nghiêm ngặt hơn cho nền tảng dựng. Khi dẫn một cấp, nêu phạm vi và bằng chứng thay vì coi con số là điểm bao quát mọi rủi ro phần mềm. Các cấp bản dựng SLSA
| Bằng chứng | Chủ yếu giúp xác định | Không tự xác định được |
|---|---|---|
| Tổng kiểm | Đã nhận đúng nội dung tệp dự kiến chưa | Danh tính nhà phát hành hoặc hành vi an toàn |
| Chữ ký số | Ai ký dữ liệu nào | Bên ký có đáp ứng yêu cầu tin cậy của bạn không |
| Nguồn gốc bản dựng | Quy trình nào tạo hiện vật | Mọi mã nguồn và phụ thuộc đều không có vấn đề |
| Bản dựng tái lập | Có dựng lại cùng hiện vật trong điều kiện đã định không | Phần mềm không có lỗ hổng hay hành vi không phù hợp |
Những bằng chứng này có thể bổ sung nhau. Nhà phát triển nên giải thích mình cung cấp gì và kiểm tra nào vẫn phải làm độc lập.
Bản dựng tái lập cần đầu vào và môi trường rõ ràng
Dự án Reproducible Builds định nghĩa bản dựng tái lập là tạo các hiện vật chỉ định giống từng bit từ cùng mã nguồn, môi trường và hướng dẫn dựng. Đó là mục tiêu kiểm chứng chính xác hơn “máy tôi biên dịch được”. Định nghĩa bản dựng tái lập
Chúng tôi khuyên giữ bộ công cụ, thông tin khóa phụ thuộc, tham số dựng và quan hệ của chúng với hiện vật phát hành. Nếu chưa đạt tái lập, hãy ghi chính xác dựng lại thành công tới đâu, thay vì bỏ qua khác biệt rồi tuyên bố đạt.
Phạm vi kho công khai cũng cần giải thích. Nó có thể chứa mã nguồn cốt lõi, hoặc chủ yếu là công cụ dựng, cấu hình và gói ứng dụng được tạo từ thượng nguồn. Người dùng cần biết thực sự có thể xem và dựng lại phần nào để đánh giá hợp lý bằng chứng nguồn gốc.
Trình tự kiểm tra bản tải thực tế
- Xác nhận kho phát hành qua điểm truy cập chính thức của dự án, không chỉ dựa vào quảng cáo tìm kiếm hay liên kết chuyển tiếp.
- Đọc ghi chú phát hành và kiểm tra hệ điều hành, kiến trúc bộ xử lý, kênh phát hành.
- So tệp với tổng kiểm tương ứng. Nếu có chữ ký hoặc nguồn gốc, kiểm tra cả danh tính dự kiến và phạm vi.
- Xem tình trạng bảo trì và giới hạn đã biết, không mặc định nhãn “mới nhất” nghĩa là phù hợp môi trường vận hành.
- Khi thông tin mâu thuẫn, giữ phiên bản và tên tệp rồi yêu cầu làm rõ qua kênh hỗ trợ dự án.
Quy trình này không đòi mọi người dùng thành kỹ sư bản dựng. Sản phẩm có thể tổ chức bằng chứng phức tạp thành trang phát hành rõ ràng, giải thích tệp từ đâu, dành cho ai, kiểm tra thế nào và hỏi ở đâu khi có sai lệch.
Với nhà phát triển, duy trì chuỗi thông tin đó theo thời gian có giá trị hơn gắn nhãn “đã xác minh” một lần. Người dùng vẫn cần tìm được giải thích khi bản cũ bị rút, cách ký đổi hoặc cập nhật thất bại.
Mô tả kho công khai của AlphaBiz phân biệt công cụ dựng với gói ứng dụng được tạo từ thượng nguồn. Khi bàn về ứng dụng máy tính dạng này, cũng nên mô tả đúng phạm vi kiểm tra thay vì đánh đồng kho công khai, mã nguồn đầy đủ và bản phát hành tái lập. Tổng quan dự án AlphaBiz
Nhà phát triển có thể bắt đầu bằng hoàn thiện danh sách bằng chứng phát hành; người dùng có thể kiểm tra một bản tải của ứng dụng thường dùng. Chia sẻ thông tin kiểm chứng bạn muốn có trên trang phát hành tại AlphaBiz Discussions.