- Nhóm phát hành Debian đã quyết định cung cấp các gói có thể tái lập vào giữa chu kỳ forky
- Phần mềm migration chặn các gói mới không thể tái lập trên reproduce.debian.net
- Migration cũng bị chặn nếu các gói hiện có trong testing xuất hiện thoái lui về tính tái lập
- autopkgtest cũng được bổ sung khả năng chạy cho binNMU giống như các bản tải lên source-full
- Hàng đợi CI đã lớn hơn do bổ sung loong64 và việc rebuild multi-arch, nên cần kiên nhẫn
Bắt buộc tính tái lập của gói Debian
- Nhóm phát hành Debian đã quyết định rằng Debian phải cung cấp các gói có thể tái lập tại thời điểm giữa chu kỳ phát hành forky
- Quyết định này có được nhờ những nỗ lực của Dự án Reproducible Builds
- Kể từ hôm qua, phần mềm migration đã được kích hoạt để chặn việc migration của các gói mới không thể tái lập trên reproduce.debian.net
- Migration cũng sẽ bị chặn trong trường hợp xảy ra thoái lui về tính tái lập ở các gói hiện có sẵn trong testing
Đảm bảo chất lượng và trách nhiệm của người tải lên
-
Chạy autopkgtest cho testing binNMU
- Đầu năm nay, phần mềm migration đã được bổ sung khả năng chạy autopkgtest cho binNMU giống như với các bản tải lên source-full
- Tính năng này có thể không liên quan trực tiếp đến phần lớn công việc của maintainer, nhưng được xem là một bước nữa nhằm tăng cường đảm bảo chất lượng
-
Bổ sung kiến trúc loong64 và hàng đợi CI tăng lên
- Hai tuần trước, kiến trúc mới loong64 đã được thêm vào archive
- Debian chỉ cho phép migration với các binary được build trên buildd, và do yêu cầu multi-arch, một số lượng lớn gói phải được build lại trên mọi kiến trúc
- Do tính năng binNMU được bổ sung trước đó, hàng đợi CI hiện đang khá lớn và nhóm phát hành đề nghị mọi người kiên nhẫn một chút
-
Các bước theo dõi sau khi tải lên
- Người tải lên gói nguồn có trách nhiệm bảo đảm gói đó có thể được migration
- Nếu gói bị chặn bởi thoái lui autopkgtest của một phụ thuộc kiểm thử ngược và phụ thuộc đó cần được cập nhật, người tải lên phải gửi một bug với mức độ nghiêm trọng RC phù hợp
2 bình luận
Các bình luận trên Hacker News
Đây là một thành tựu lớn cho Debian và thế giới phần mềm tự do
Chỉ là phải mất khá lâu mọi người mới hiểu được sự cần thiết của việc này. Khi tôi nói trên debian-devel vào năm 2007 rằng điều này là cần thiết, tôi đã nhận được câu trả lời rằng đó là một sự lãng phí thời gian khổng lồ, và thực tế để đi được đến đây đã cần khối lượng công việc khổng lồ từ rất nhiều người, nhưng hoàn toàn xứng đáng
Tôi không nghĩ câu “hoàn toàn xứng đáng” là đúng. Nó chỉ làm tăng thêm rào cản để đóng góp cho Debian, và tôi đã thấy nhiều người than phiền rằng việc đóng góp cho Debian vốn đã khó rồi. Trước đây tôi từng bênh vực điều đó bằng lập luận rằng “cần đủ loại kiểm tra và đối chiếu để các gói ăn khớp tốt với nhau”, nhưng bước này có vẻ là làm cho mọi thứ khó hơn mà không có lý do rõ ràng, trong khi lợi ích lại nhỏ
Có thêm thông tin tại https://wiki.debian.org/ReproducibleBuilds. Một phần đã cũ, nhưng cũng có biểu đồ cho thấy số gói được build trong CI và bao nhiêu trong số đó là build tái lập được
Màu cam là FTBR, tức “không build tái lập được”. Tôi không quen đọc số trên biểu đồ lắm, nhưng ước chừng là vài phần trăm, khoảng 4~5%
Việc này rất tốt. NetBSD đã có build hoàn toàn tái lập được từ năm 2017. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...
Tham khảo thêm, phần lớn các gói Debian đều có build tái lập được. Những gói chưa làm được, khoảng 5%, được hiển thị bằng màu cam trong biểu đồ này: https://wiki.debian.org/ReproducibleBuilds
Debian cũng đã tiến bộ rất nhiều, nhưng khi Debian nói là có thể tái lập thì nghĩa là họ lấy các binary bên thứ ba để phục vụ việc build của chính mình. Còn khi chúng tôi nói có thể tái lập, nghĩa là bootstrap 100% từ mã nguồn cho tới tận cuối toàn bộ chuỗi cung ứng phần mềm
Tôi nghĩ sự khác biệt này rất quan trọng
https://stagex.tools
Tôi thực sự rất vui với thay đổi này. Sau khi đọc về cuộc tấn công SolarWinds vào năm 2021 và bị sốc, tôi đã bắt đầu tham gia vào build tái lập. [1]
Tôi nghĩ câu của Magnus Ihse Bursie, người từng làm việc về build tái lập cho OpenJDK, là chuẩn xác nhất: “Nếu hỏi tôi, thì việc compiler và công cụ build từ một thời điểm nào đó bắt đầu tạo ra đầu ra không tất định tự nó đã là một bug ngay từ ngày đầu tiên.” [2]
[1] https://www.linux.com/news/preventing-supply-chain-attacks-l...
[2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997
Tôi tò mò vì sao dạo này việc này lại thành chủ đề nóng. Tôi dùng Yocto cho thiết bị nhúng, và build tái lập được gần như là thứ có thể triển khai một cách hiển nhiên
Quản lý gói của Debian cũng có thể bật lên dễ dàng, nên tôi cứ nghĩ là mọi thứ vốn đã làm được rồi chứ
Build tái lập là một phương pháp thiết yếu trong điện toán công nghiệp. Thay vì nói Debian đang ở tuyến đầu trong lĩnh vực này, có lẽ đúng hơn là Debian đang tiếp nhận một kỹ thuật phổ biến trên toàn ngành, vốn cũng được áp dụng cho các hệ điều hành khác dùng trong các mục đích vận hành dài hạn và liên quan đến an toàn
Tất nhiên, cũng có phần lớn là nhờ Yocto và rất nhiều công việc khó khăn từ các nhà phát triển Debian mà giờ đây ta đã có thể dùng nó dễ dàng
Điều thú vị là giờ các nhà phát triển Debian đang áp dụng nó như một chính sách chủ động hơn, biến nó từ lựa chọn thành chuẩn mặc định
Với amd64 forky
reproduced: 97.02%
good: 17586
bad: 511
fail: 30
unknown: 0
Có thể xem thống kê này, thống kê cho các kiến trúc khác và lý do không tái lập được tại https://reproduce.debian.net
Tôi luôn thấy ngạc nhiên là Debian đang dẫn dắt việc này chứ không phải vendor thương mại. Người ta sẽ nghĩ các tổ chức lớn đang trả tiền cho RHEL và Ubuntu hẳn sẽ đòi hỏi binary có thể kiểm chứng được một cách quyết liệt chứ
Điều đó rất tốt cho phần mềm tự do, nhưng không hẳn tốt với những bên muốn trở thành kẻ độc quyền
Forbidden
You don't have permission to access this resource.
Apache Server at lists.debian.org Port 443
:/
Dù sao thì cũng có trên Wayback Machine: https://web.archive.org/web/20260510074120/https://lists.deb...
Ý kiến trên Lobste.rs
Đây là một thay đổi tốt về mặt bảo mật. Quá trình chuyển đổi có thể khá phiền phức, nhưng cuối cùng sẽ mang lại độ tin cậy cao hơn cho người dùng Debian Linux trên toàn thế giới
Tò mò không biết lợi ích cốt lõi đối với một dự án như Debian là gì. Có phải là để mọi người đều có thể có bằng chứng rằng trong binary không có backdoor không?
Tức là liệu việc này có tác dụng giảm mức độ tin cậy phải đặt vào người bảo trì và cũng giảm rủi ro từ người bảo trì độc hại không? Không phải tôi hoài nghi, chỉ là tôi chưa hiểu 100% vì sao Debian lại dành nhiều thời gian cho việc này. Làm cho build có thể tái lập có vẻ là việc khá khó và tốn công
Cốt lõi là tạo ra bằng chứng cho thấy gói đầu ra thực sự được tạo từ đúng bộ mã nguồn đó, chứ không phải từ một bộ mã nguồn thứ hai bị giấu đi. the reproducible-builds org has a bit of a 'why' which puts it better than i can
Việc tạo ra các build có thể tái lập là rất khó. Ví dụ, timestamp trong pipeline biên dịch cũng có thể tạo ra khác biệt, và metadata của archive được tạo ra cũng vậy. Tất cả những thứ đó đều phải được loại bỏ, và trong một số trường hợp còn cần vá các dự án upstream như CMake hay trình biên dịch Go chứ không chỉ bản thân gói. Trong nhiều trường hợp, trước đây những vấn đề như vậy thậm chí còn chưa từng được xem xét, nên cần làm việc trên toàn bộ stack build. Tuy vậy, công việc này đã được tiến hành từ lâu, nên phần lớn hạ tầng nền tảng bên dưới hoặc đã hoàn tất, hoặc đang tiến triển sâu
Tính tái lập mà Debian nói đến có phải là cùng một khái niệm với thứ người ta nói ở NixOS không?
NixOS cũng đang làm reproducible builds, và nếu tôi nhớ không nhầm thì ít nhất ISO là 100% có thể tái lập cả ở build lẫn runtime. Nhưng tính tái lập mà người ta thường nói về NixOS không phải là “reproducible builds” đang được bàn ở đây. Hãy xem bài viết của foxboron được liên kết trong bình luận cùng nhánh của thread này. Cái đó gần hơn với tính tái lập môi trường, hoặc “deterministic builds”, và vẫn có giá trị, nhưng không phải đối tượng đang được nói tới ở đây
Hiện tại nghe giống kiểu ratchet. Vậy những thứ trước giờ chưa từng build được theo cách có thể tái lập thì vẫn được phép chứ?