OSS Rebuild của Google đối mặt với sự phản đối từ cộng đồng về tập trung hóa và các giải pháp hiện có

Nhóm Cộng đồng BigGo
OSS Rebuild của Google đối mặt với sự phản đối từ cộng đồng về tập trung hóa và các giải pháp hiện có

Google gần đây đã công bố OSS Rebuild , một dự án nhằm tăng cường niềm tin vào các gói mã nguồn mở bằng cách xây dựng lại và xác minh các thư viện phổ biến từ các registry PyPI , npm và Crates.io . Hệ thống tạo ra các chứng thực xuất xứ SLSA Build Level 3 để giúp phát hiện các cuộc tấn công chuỗi cung ứng mà không yêu cầu thay đổi từ các nhà bảo trì gói. Tuy nhiên, thông báo này đã gây ra cuộc tranh luận đáng kể trong cộng đồng nhà phát triển về việc liệu cách tiếp cận này có phải là giải pháp đúng đắn hay không.

Phạm vi Tái Xây Dựng OSS Hiện Tại:

  • PyPI (Python): Hàng nghìn gói với chứng thực SLSA Build Level 3
  • npm (JavaScript/TypeScript): Các gói phổ biến với xác minh tái xây dựng
  • Crates.io (Rust): Được hỗ trợ với định nghĩa xây dựng tự động
  • Tổng Số Chứng Thực: 9,507 bản build được công bố tính đến thời điểm thông báo
  • Hỗ Trợ Thử Nghiệm: Các gói Debian , hệ sinh thái JVM và Ruby

Các nhà phát triển đặt câu hỏi về nhu cầu cơ sở hạ tầng mới

Nhiều thành viên cộng đồng đang đặt câu hỏi tại sao Google lại tạo ra một hệ thống hoàn toàn mới khi các giải pháp đã được thiết lập sẵn có. Những lời chỉ trích mạnh mẽ nhất tập trung vào các trình quản lý gói hiện có như Nix và Guix , những hệ thống đã cung cấp khả năng xây dựng lại có thể tái tạo và xác minh. Các nhà phê bình cho rằng việc đóng góp vào những hệ sinh thái trưởng thành này sẽ có lợi hơn so với việc bắt đầu từ đầu.

Cuộc tranh luận mở rộng ra ngoài các trình quản lý gói. Một số nhà phát triển chỉ ra rằng các bản phân phối Linux như Debian và Arch Linux đã có các hệ thống xác minh xây dựng lại mạnh mẽ. Những giải pháp hiện có này đã hoạt động thành công trong nhiều năm, khiến một số người tự hỏi liệu cách tiếp cận của Google có trùng lặp công việc hiện có thay vì cải thiện nó.

Các Giải Pháp Thay Thế Được Cộng Đồng Đề Xuất:

  • Nix/NixOS: 107,158 thư viện được đóng gói với khả năng tái tạo builds
  • ReprOS/StageX: Mô hình tin cậy phi tập trung với bootstrapping toàn bộ mã nguồn
  • Debian: Dự án reproducible builds (reproduce.debian.net từ năm 2024)
  • Arch Linux: Reproducible builds (reproducible.archlinux.org từ năm 2020)
  • Guix: Tái tạo từng bit một với xác minh phía client

Mối lo ngại về tập trung hóa chiếm ưu thế trong thảo luận

Một điểm tranh cãi chính là cách tiếp cận tập trung hóa của Google đối với việc xác minh gói. Các thành viên cộng đồng lo lắng về việc tạo ra một điểm lỗi đơn lẻ khác trong chuỗi cung ứng phần mềm, đặc biệt là với lịch sử ngừng các dự án của Google . Mối lo ngại đặc biệt nghiêm trọng vì OSS Rebuild yêu cầu thông tin xác thực Google Cloud và dựa vào cơ sở hạ tầng của Google để xác thực chứng thực.

Điều này có vẻ có lỗ hổng khi giả định rằng các máy chủ của google không bị xâm phạm, việc có khả năng phân tán để tái tạo sẽ tốt hơn rất nhiều.

Các cách tiếp cận thay thế như ReprOS và StageX đã thu hút sự chú ý trong cuộc thảo luận với các mô hình xác minh phi tập trung. Những hệ thống này cho phép nhiều bên độc lập xác minh các bản build mà không cần dựa vào một cơ quan đáng tin cậy duy nhất, giải quyết những lo ngại về tập trung hóa mà nhiều nhà phát triển đã nêu ra.

Triển khai kỹ thuật nhận được đánh giá trái chiều

Trong khi một số nhà phát triển đánh giá cao khả năng kỹ thuật của dự án, những người khác đặt câu hỏi về việc triển khai thực tế. Hệ thống hiện tại yêu cầu người dùng cài đặt một công cụ dòng lệnh dựa trên Go , điều mà nhiều người coi là rào cản đáng kể cho việc áp dụng. Các thành viên cộng đồng đã bắt đầu xây dựng các giao diện web không chính thức để làm cho dữ liệu dễ tiếp cận hơn.

Việc sử dụng AI thử nghiệm của dự án để tự động hóa các quy trình xây dựng cũng đã tạo ra cuộc thảo luận. Trong khi Google coi đây là một hướng đi đầy hứa hẹn để xử lý các tình huống xây dựng phức tạp, một số nhà phát triển vẫn hoài nghi về việc dựa vào các mô hình ngôn ngữ cho cơ sở hạ tầng bảo mật quan trọng.

Thách thức tích hợp hệ sinh thái

Có lẽ thách thức quan trọng nhất được cộng đồng nêu bật là cách OSS Rebuild tích hợp với các quy trình phát triển hiện có. Không giống như các hệ thống như Nix có thể thay thế toàn bộ quy trình quản lý gói, OSS Rebuild hoạt động như một lớp phủ trên các registry hiện có. Cách tiếp cận này có nghĩa là các nhà phát triển phải áp dụng các công cụ và quy trình bổ sung thay vì chuyển sang một nền tảng an toàn hơn.

Dự án hiện tại bao phủ hàng nghìn gói trên ba hệ sinh thái chính, nhưng phản hồi từ cộng đồng cho thấy rằng tích hợp hệ sinh thái rộng hơn vẫn là một trở ngại đáng kể. Các nhà phát triển muốn các giải pháp hoạt động mượt mà với các công cụ hiện có của họ thay vì yêu cầu các bước xác minh bổ sung.

Bất chấp những lời chỉ trích, OSS Rebuild của Google đại diện cho một nỗ lực nghiêm túc nhằm giải quyết các mối lo ngại về bảo mật chuỗi cung ứng đã gây khó khăn cho ngành công nghiệp phần mềm. Việc nó có được áp dụng hay không có thể sẽ phụ thuộc vào mức độ nhóm giải quyết tốt các mối lo ngại của cộng đồng về tập trung hóa và tích hợp với các quy trình làm việc hiện có.

Tham khảo: Introducing OSS Rebuild: Open Source, Rebuilt to Last