OSS Rebuild Google Menghadapi Tentangan Komuniti Mengenai Pemusatan dan Penyelesaian Sedia Ada

Pasukan Komuniti BigGo
OSS Rebuild Google Menghadapi Tentangan Komuniti Mengenai Pemusatan dan Penyelesaian Sedia Ada

Google baru-baru ini mengumumkan OSS Rebuild , sebuah projek yang bertujuan untuk mengukuhkan kepercayaan terhadap pakej sumber terbuka dengan membina semula dan mengesahkan perpustakaan popular daripada registri PyPI , npm , dan Crates.io . Sistem ini menghasilkan pengesahan asal usul SLSA Build Level 3 untuk membantu mengesan serangan rantaian bekalan tanpa memerlukan perubahan daripada penyelenggara pakej. Walau bagaimanapun, pengumuman ini telah mencetuskan perdebatan yang ketara dalam komuniti pembangun mengenai sama ada pendekatan ini adalah penyelesaian yang betul.

Liputan Pembinaan Semula OSS Semasa:

  • PyPI (Python): Beribu-ribu pakej dengan pengesahan SLSA Build Level 3
  • npm (JavaScript/TypeScript): Pakej popular dengan pengesahan pembinaan semula
  • Crates.io (Rust): Disokong dengan definisi pembinaan automatik
  • Jumlah Pengesahan: 9,507 pembinaan diterbitkan setakat pengumuman
  • Sokongan Eksperimental: Pakej Debian, JVM, dan ekosistem Ruby

Pembangun Mempersoalkan Keperluan untuk Infrastruktur Baharu

Ramai ahli komuniti mempersoalkan mengapa Google mencipta sistem yang sama sekali baharu apabila penyelesaian yang telah mantap sudah wujud. Kritikan yang paling lantang tertumpu pada pengurus pakej sedia ada seperti Nix dan Guix , yang sudah menyediakan keupayaan pembinaan semula yang boleh dihasilkan dan pengesahan. Pengkritik berpendapat bahawa menyumbang kepada ekosistem matang ini akan lebih bermanfaat daripada memulakan dari awal.

Perdebatan ini melangkaui pengurus pakej sahaja. Beberapa pembangun menunjukkan bahawa pengedaran Linux seperti Debian dan Arch Linux sudah mempunyai sistem pengesahan pembinaan semula yang kukuh. Penyelesaian sedia ada ini telah beroperasi dengan jayanya selama bertahun-tahun, menyebabkan sesetengah pihak tertanya-tanya sama ada pendekatan Google menduplikasi kerja sedia ada dan bukannya meningkatkannya.

Penyelesaian Alternatif yang Disebut oleh Komuniti:

  • Nix / NixOS: 107,158 perpustakaan yang dibungkus dengan binaan yang boleh dihasilkan semula
  • ReprOS / StageX: Model kepercayaan terdesentralisasi dengan bootstrapping sumber penuh
  • Debian: Projek binaan yang boleh dihasilkan semula (reproduce.debian.net sejak 2024)
  • Arch Linux: Binaan yang boleh dihasilkan semula (reproducible.archlinux.org sejak 2020)
  • Guix: Penghasilan semula bit-untuk-bit dengan pengesahan sebelah klien

Kebimbangan Pemusatan Mendominasi Perbincangan

Titik perbalahan utama ialah pendekatan berpusat Google terhadap pengesahan pakej. Ahli komuniti bimbang tentang mewujudkan satu lagi titik kegagalan tunggal dalam rantaian bekalan perisian, terutamanya memandangkan rekod prestasi Google dalam menghentikan projek. Kebimbangan ini amat ketara kerana OSS Rebuild memerlukan kelayakan Google Cloud dan bergantung pada infrastruktur Google untuk pengesahan pengesahan.

Ini kelihatan cacat untuk menganggap bahawa pelayan google tidak terjejas, adalah jauh lebih baik untuk mempunyai keupayaan teragih untuk menghasilkan semula.

Pendekatan alternatif seperti ReprOS dan StageX telah mendapat perhatian dalam perbincangan untuk model pengesahan terdesentralisasi mereka. Sistem ini membenarkan pelbagai pihak untuk mengesahkan pembinaan secara bebas tanpa bergantung pada satu pihak berkuasa yang dipercayai, menangani kebimbangan pemusatan yang dibangkitkan oleh ramai pembangun.

Pelaksanaan Teknikal Mendapat Ulasan Bercampur

Walaupun sesetengah pembangun menghargai keupayaan teknikal projek ini, yang lain mempersoalkan pelaksanaan praktikalnya. Sistem semasa memerlukan pengguna memasang alat baris arahan berasaskan Go , yang dilihat oleh ramai sebagai halangan yang ketara untuk penggunaan. Ahli komuniti telah mula membina antara muka web tidak rasmi untuk menjadikan data lebih mudah diakses.

Penggunaan eksperimental AI projek untuk mengautomasikan proses pembinaan juga telah menghasilkan perbincangan. Walaupun Google melihat ini sebagai jalan yang menjanjikan untuk mengendalikan senario pembinaan yang kompleks, sesetengah pembangun kekal skeptikal tentang bergantung pada model bahasa untuk infrastruktur keselamatan kritikal.

Cabaran Integrasi Ekosistem

Mungkin cabaran paling ketara yang ditonjolkan oleh komuniti ialah bagaimana OSS Rebuild berintegrasi dengan aliran kerja pembangunan sedia ada. Tidak seperti sistem seperti Nix yang boleh menggantikan keseluruhan aliran kerja pengurusan pakej, OSS Rebuild beroperasi sebagai lapisan pada registri sedia ada. Pendekatan ini bermakna pembangun mesti menggunakan alat dan proses tambahan dan bukannya beralih kepada asas yang lebih selamat.

Projek ini kini meliputi beribu-ribu pakej merentasi tiga ekosistem utama, tetapi maklum balas komuniti menunjukkan bahawa integrasi ekosistem yang lebih luas kekal sebagai halangan yang ketara. Pembangun mahukan penyelesaian yang berfungsi dengan lancar dengan alat sedia ada mereka dan bukannya memerlukan langkah pengesahan tambahan.

Walaupun terdapat kritikan, OSS Rebuild Google mewakili percubaan serius untuk menangani kebimbangan keselamatan rantaian bekalan yang telah melanda industri perisian. Sama ada ia mendapat penggunaan mungkin bergantung pada sejauh mana pasukan menangani kebimbangan komuniti tentang pemusatan dan integrasi dengan aliran kerja sedia ada.

Rujukan: Introducing OSS Rebuild: Open Source, Rebuilt to Last