- Pemeliharaan rsync sedang menghadapi situasi di mana ledakan laporan keamanan bertabrakan dengan kontroversi penggunaan AI, sehingga kini dibutuhkan suite pengujian yang lebih ketat, cakupan kode, CI multi-platform, pemindaian keamanan, dan pertahanan berlapis
- Suite pengujian Python yang baru menggantikan struktur skrip shell lama, tetapi desain dan rencana verifikasinya tetap ditangani oleh pemelihara, sementara Claude, Codex, dan Gemini digunakan untuk membantu pekerjaan berulang
- Rilis 3.4.3 adalah rilis yang memprioritaskan perbaikan keamanan, tetapi memunculkan regresi pada beberapa kasus penggunaan yang valid namun tidak umum yang tidak tertangkap oleh pengujian lama maupun pengujian manual
- pytest banyak dipakai di proyek lain, tetapi tidak cocok untuk kebutuhan spesifik suite pengujian rsync, sehingga dipilih pendekatan terpisah; LLM dinilai perlu digunakan dengan hati-hati tetapi tetap merupakan alat yang berguna
- Arah berikutnya masih diputuskan antara 3.4.4 untuk meredakan regresi dan 3.5.0 yang akan membawa perubahan keamanan besar; openrsync saat ini gagal pada 85 dari 98 pengujian di suite baru
Ledakan laporan keamanan dan penguatan pertahanan
- Pemelihara rsync, seperti banyak pengembang paket open source belakangan ini, sedang menghadapi banjir laporan keamanan; banyak di antaranya merupakan hasil buatan AI, tetapi ada juga sejumlah analisis manual yang cermat dan bermutu tinggi
- Seiring lonjakan laporan yang makin parah, rsync kini membutuhkan suite pengujian yang lebih menyeluruh, analisis cakupan kode, pengujian CI di lebih banyak platform, pemindaian untuk isu keamanan yang disengaja, dan teknik pertahanan berlapis
- Pemelihara sudah pensiun dan ingin lebih banyak berlayar, tetapi karena besarnya volume pekerjaan yang dibutuhkan, ia menggunakan berbagai alat AI dan tidak menyesali pilihan itu
Suite pengujian Python dan pekerjaan bantu AI
- Suite pengujian rsync lama yang berbasis skrip shell telah ditulis ulang dalam Python, dengan desain inti dan rencana validasi tetap ditangani langsung oleh pemelihara
- Claude digunakan untuk pekerjaan berulang, sementara Codex dan Gemini dipakai untuk pemeriksaan silang; ini bukan pendekatan yang sekadar menyerahkan tugas dengan perintah “ubah suite pengujian ke Python”
- Pemelihara meninjau sendiri seluruh bagiannya, menghabiskan banyak waktu CI untuk menyesuaikannya, lalu setelah itu beralih menjalankan sebagian besar pengujian di beberapa VM lokal untuk mengurangi waktu tunggu CI
- Tanda
co-authored by claude dalam riwayat commit dinilai hanya memperlihatkan sebagian dari keseluruhan pekerjaan rekayasa perangkat lunak yang dilakukan
Perdebatan LLM, pilihan pytest, dan regresi 3.4.3
- LLM tidak menjadi alat yang tidak berguna hanya karena orang memahami cara kerjanya; alat ini perlu dipakai dengan hati-hati, tetapi tetap berguna dalam lingkungan rekayasa perangkat lunak dan pemeliharaan keamanan TI saat ini
- rsync 3.4.3 adalah rilis yang sengaja condong pada prioritas perbaikan isu keamanan, dan dalam proses itu beberapa kasus penggunaan yang valid tetapi tidak umum ikut terdampak oleh perubahan tersebut
- Kasus penggunaan yang terdampak itu tidak tercakup dalam suite pengujian rsync lama maupun pengujian manual, dan regresi yang dilaporkan melalui issue dan PR di repositori GitHub sedang ditangani satu per satu
- pytest banyak digunakan di proyek lain, tetapi dinilai sangat sulit untuk sebagian pekerjaan yang dibutuhkan dalam suite pengujian rsync, sehingga dipilih perancangan pendekatan pengujian tersendiri
Rilis berikutnya dan perluasan pengujian keamanan
- Laporan keamanan terus berdatangan, dan saat ini beberapa pekerjaan CVE sedang berlangsung
- Pengembang lain dengan kemampuan pengembangan sistem dan pengetahuan keamanan telah bergabung, dan sebagian dari mereka menjadi terlihat berkat kemarahan yang baru-baru ini mencuat
- Pilihan berikutnya ada di antara 3.4.4 yang meredakan sebagian regresi dan 3.5.0 yang membawa perubahan jauh lebih besar; 3.5 akan secara signifikan meningkatkan standar keamanan rsync, tetapi merupakan rilis dengan skala perubahan yang besar
- Untuk menerapkan sekumpulan perubahan besar dengan cepat pada perangkat lunak seperti rsync, dibutuhkan suite pengujian yang komprehensif, dan penulisan ulang suite pengujian baru lahir dari kebutuhan tersebut
- Rilis 3.5 akan menyertakan pengujian tambahan yang menangani isu-isu terkait keamanan
Perbandingan openrsync dan permintaan code review
- Menanggapi dorongan untuk memaketkan openrsync bagi platform tertentu, reaksinya adalah bahwa suite pengujian rsync yang baru dapat dicoba diterapkan pada openrsync
- Contoh eksekusinya adalah perintah berikut
./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp
- openrsync saat ini gagal pada 85 dari 98 pengujian, dan meskipun banyak kegagalan disebabkan oleh fitur yang tidak dimiliki openrsync, hasil itu tetap dinilai tidak bagus
- Daripada meluapkan kemarahan lebih jauh, ada permintaan agar orang benar-benar meninjau kode yang telah dipublikasikan dan memberikan kritik yang konstruktif
1 komentar
Opini Lobste.rs
Dari kutipannya, penulis terkesan ingin berlayar tetapi juga merasakan tekanan untuk memelihara proyek, dan seolah melihat solusi memakai LLM agar bisa melakukan keduanya
Tidak apa-apa pensiun dan menikmati berlayar sambil tidak memperbaiki bug, dan tidak apa-apa juga tidak memperbaiki bug di proyek open source. Yang penting, hal itu disampaikan secara terbuka dan transparan. Seperti ungkapan lama, “patches welcome” sudah cukup. Terlebih lagi jika perusahaan-perusahaan dengan sumber daya besar bergantung pada proyek itu
Saya berharap lebih banyak maintainer dan developer bisa menikmati masa pensiun dan berlayar tanpa tekanan bahwa mereka harus menerima “bantuan” LLM untuk pemeliharaan open source. Meski begitu, jika ia ingin bereksperimen dengan LLM di proyek rsync, itu adalah pilihannya. Sama saja meskipun orang lain, termasuk saya, tidak setuju
Apa pun alasannya, orang-orang yang melecehkan developer open source tampaknya lupa bahwa perangkat lunak open source gratis bukanlah produk, melainkan hadiah
Orang luar yang hanya menonton dari pinggir, kalau tidak suka, tinggal fork saja. Andrew berhak bekerja di proyek itu dengan cara yang ia inginkan, dan komentar serta opini kita pun belum tentu diperlukan
Bagian yang memberi harapan adalah dalam jangka panjang mungkin akan muncul orang lain yang mengambil alih pemeliharaan rsync. Tridge juga pernah menyerahkannya kepada maintainer baru di masa lalu
Saya menulis di LWN setelah mendengar presentasi tentang kasus-kasus ketika OpenJS Foundation menyediakan pendanaan dan dukungan transisi untuk beberapa proyek agar berpindah dari sistem maintainer tunggal ke pemeliharaan tim, dan itu dijadwalkan terbit hari ini. Proyek seperti rsync jauh lebih membutuhkan dukungan semacam ini
Isu keamanan menimbulkan tekanan besar, sangat terekspos, dan sering kali jauh dari inti proyek yang justru menarik minat maintainer
Pemeliharaan membawa banyak tanggung jawab dan tidak semuanya menyenangkan, tetapi saya tetap bersyukur ketika maintainer free/open source juga menangani hal-hal seperti itu. Tampaknya tidak banyak orang yang mau melakukannya
Bisa jadi tanpa bantuan LLM, biaya untuk mencapai tujuan tertentu dianggap terlalu tinggi, sedangkan dengan bantuan LLM biayanya menjadi masuk akal
Jika dilihat secara positif, ini berarti maintainer open source yang ingin menjaga keseimbangan kerja dan hidup yang sehat kini dapat mengurangi beban kerja dengan LLM sambil lebih mudah mencapai tujuan yang mereka inginkan
Bagian yang dipilih untuk dikutip hanyalah sebagian dari pengantar, dan tulisan ini jelas ditulis dengan hati-hati dan penuh nuansa, bukan sekadar tulisan dasar tentang pemeliharaan open source
Yang lebih aneh, konteks tepat sebelum kutipan itu justru dihilangkan. Isinya adalah bahwa lonjakan laporan membuat rsync harus menaikkan garis pertahanannya secara besar-besaran, dan diperlukan test suite yang jauh lebih menyeluruh, analisis code coverage, pengujian CI di lebih banyak platform, penelusuran isu keamanan, serta penambahan teknik defense in depth
Dalam kasus ini penulis memang sudah pensiun, tetapi di proyek open source lain, orang yang masih punya pekerjaan atau urusan lain bisa terseret ke peningkatan beban kerja yang serupa. Terus terang, saya bingung komentar ini mendapat begitu banyak upvote, dan rasanya tidak ditulis dengan itikad baik. Paling tidak, reaksinya terasa minim usaha, hanya sedikit lebih baik daripada komentar yang datang setelah membaca judul saja
Saya tidak bermaksud membenarkan atau menyetujui pelecehan, tetapi ada alasan yang hilang dari pembelaan ini
Penjelasannya adalah bahwa penulis merancang untuk vibe coding, meninjau kode hasilnya, mahir dalam kode dan chatbot, menangani vibe coding dengan hati-hati, serta berusaha menyeimbangkan keamanan dan regresi fungsi. Kedengarannya masuk akal, tetapi pada kenyataannya memang terjadi regresi, dan penulis bahkan tidak sampai pada akar penyebabnya
Ia mengatakan bahwa “alat AI kuat untuk tugas sederhana sehingga pekerjaan seperti itu diserahkan kepadanya”, tetapi tidak demikian. Chatbot sebenarnya buruk dalam menulis. Itu inti masalahnya, dan penulis tampaknya bahkan tidak menyadarinya
Akan bagus jika kita bisa memastikan apakah angkanya benar-benar naik belakangan ini. Regresi sendiri bukan hal langka, dan saya rasa bisa saja orang hanya mencari alasan untuk menyerang Andrew
Penulis mengakui bahwa ada regresi pada sebagian use case dalam rilis rsync 3.4.3, dan menjelaskan bahwa pada rilis itu ia memang sengaja memberi bobot lebih besar pada perbaikan isu keamanan, sehingga beberapa use case yang valid tetapi tidak umum ikut terdampak oleh perubahan
Kasus-kasus itu tidak termasuk dalam test suite rsync yang ada maupun pengujian manual yang ia lakukan sendiri, dan sekarang ia sedang menangani regresi tersebut sambil berterima kasih kepada orang-orang yang melaporkannya melalui issue atau PR di repositori GitHub. Ia juga meminta maaf jika use case seseorang ikut terdampak, dan mengatakan bahwa bila mereka bersedia menanggung risiko keamanan, mereka bisa memakai rilis sebelumnya
Saya terus mendengar selama sekitar setengah tahun terakhir hal-hal seperti “dunia rekayasa perangkat lunak telah berubah drastis dalam beberapa bulan terakhir” dan “dunia pemeliharaan perangkat lunak di tengah keamanan TI dan banjir laporan telah berubah total dalam beberapa minggu terakhir”, dan itu melelahkan
Jika penyebab banjir laporan ini adalah LLM, mencari solusi dengan LLM terasa seperti arah yang salah sampai sulit dipercaya
Meski begitu, saya langsung bisa percaya bahwa memelihara sesuatu yang sedang populer saat ini pasti mengerikan. Mungkin baginya yang terbaik adalah mundur saja dan menikmati masa pensiun yang sesungguhnya, alih-alih terus memeras waktu komputasi yang terbatas
Kalau itu memang alat yang berguna setidaknya setengah dari yang diklaim orang, kegunaannya akan berbicara sendiri
Namun, cerita dari orang seperti Tridgell tetap layak didengar. Dan “banjir” laporan keamanan memang harus ditanggapi serius. Siapa pun atau apa pun yang menemukannya, isu keamanan tetaplah isu keamanan. Karena itu tulisan ini terasa berbeda dari serangan membosankan yang biasa saya lihat
Pada akhirnya kita bisa masuk ke spiral penurunan dengan ketergantungan pada LLM yang terus membesar
Mengapa itu arah yang salah? Apakah maksudnya akan lebih baik jika tak seorang pun memiliki LLM?
Pengembangan berbantuan LLM tidak harus selalu menghasilkan “sampah”
Saya menghargai bahwa tulisan ini dibuat dan dibagikan. Khususnya bagian yang menonjol adalah pertimbangan apakah akan meredakan sebagian regresi lewat 3.4.4, atau langsung menuju 3.5.0 yang memuat perubahan jauh lebih besar
Jika penulis membaca ini, di sini 3.4.4 tampaknya merupakan pendekatan yang tepat. Dalam situasi ketika rilis terakhir memiliki regresi, langsung melompat ke 3.5.0 yang besar akan dianggap ceroboh oleh banyak orang. Jika orang lebih mudah memahami perbedaannya, kekhawatiran akan berkurang
Soal bagian bahwa mungkin itu ide buruk karena mencoba lebih dulu mengerjakan struktur inti test suite baru secara terbuka di master dan itu justru memicu kemarahan, saya rasa persepsi dan reaksinya tidak akan membaik hanya dengan mengurangi transparansi. Paling-paling itu hanya menunda penolakan yang lebih besar
Menyuruh openrsync menjalankan test suite rsync yang baru itu tidak adil. samba rsync adalah protokol 32 sedangkan openrsync adalah protokol 27, dan juga tidak mengklaim kelengkapan fitur
Medium dan Cloudflare, kombinasi mengerikan yang seharusnya tidak dicampur
https://archive.is/qbyVA
Menjadi maintainer open source adalah pekerjaan yang kurang dihargai. Tridge tampaknya berusaha memperbaiki utang teknis pada test suite dan merespons secara bertanggung jawab banjir CVE yang terdeteksi LLM, tetapi tampaknya terkena Hukum Hyrum. Rencana 3.4.4 adalah pilihan yang sedikit tidak terlalu buruk, dan sepertinya pada akhirnya memang harus terus didorong maju
Soal ini membuat saya terbelah. Di satu sisi, saya cenderung berpikir keamanan hanya bisa dijamin ketika manusia menulis kode secara langsung
karena selama menulis, mereka memikirkan kode itu dan menangkap kesalahan lebih awal. Saat menulis sendiri saya jauh lebih teliti daripada saat meninjau. Ketika meninjau, saya tidak memikirkan setiap baris dengan saksama, jadi banyak hal begitu saja terlewat
Di sisi lain, terlepas dari fakta mendasar bahwa perundungan tidak bisa diterima, Andrew berhak menjalankan proyeknya di waktu luangnya dengan cara yang ia inginkan. Kalau ia ingin memakai LLM, saya mungkin tidak setuju, tetapi itu proyeknya dan itu wewenangnya. Kalau saya tidak suka, saya harus memindahkan backup saya ke restic atau borgbackup, atau mem-fork rsync
Biar jelas, saya tidak menentang vibe coding itu sendiri. Di kantor saya agak dipaksa memakainya, dan untuk sebagian besar pekerjaan saya belakangan ini—menulis glue code yang membosankan dan tidak baru—itu lumayan berguna. Hanya saja saya tidak memakainya di waktu luang
rsyncjuga bukan solusi yang sangat cocokkarena tidak membantu memulihkan saat isi file rusak. Alat seperti restic jauh lebih baik, dan juga menyimpan versi file sebelumnya untuk menangani kasus seperti ini. Bahkan ia juga melacak penghapusan, jadi bisa tahu file mana yang sudah tidak relevan lagi
Saya punya pengalaman di keamanan aplikasi, bisa memilih beberapa exploit, dan kadang bisa menangkapnya saat review. Tapi saya tidak sebaik LLM papan atas saat ini yang bisa terus mengulang pola seperti “cari kasus yang lebih patologis”
Dengan upaya minim, saya pernah menemukan masalah di kode saya, library yang saya pakai, dan implementasi alternatif pada perangkat lunak yang cukup populer. Waktu dan kegigihan yang bisa dikerahkan manusia benar-benar tidak sebanding
Di seluruh organisasi biasanya sudah tersebar luas perangkat lunak keamanan untuk mencegah, mendeteksi, dan merespons masalah. Di tiap area selalu ada celah dan selalu ada lebih banyak yang harus dikerjakan. Organisasi mungkin memilih menerima peningkatan postur keamanan, meski tahu itu tidak akan sempurna, daripada tidak ada peningkatan sama sekali. Kompromi yang ditawarkan LLM adalah bagian dari itu
Titik komprominya bergantung pada konteks, tetapi jarang sekali jawabannya menjadi “semua kode harus ditulis dengan tangan”
Ini juga berlaku untuk server seperti rsync. Seperti kata penulisnya, mungkin dibutuhkan refactor besar agar ia lebih kokoh dan tangguh. Jika dengan LLM kita bisa melakukan refactor ke arah pemisahan privilege sehingga menghasilkan kode berbasis kepercayaan yang lebih kecil, mungkin sebagian bug di luar lingkup itu bisa diterima
Saya tidak tahu konteks spesifik rsync, tetapi saya percaya penulisnya sedang mengambil keputusan terbaik untuk proyek dan penggunanya dalam keterbatasan sumber daya yang biasanya dimiliki proyek seperti ini
Sebagai gantinya, rclone punya paralelisme, jadi bisa memanfaatkan bandwidth jaringan yang tersedia jauh lebih efektif
Itu memberi batas atas pada jenis masalah yang mungkin muncul
Batas bawahnya adalah bug dan kerentanan yang bisa saya temukan, ditemukan orang lain, atau ditemukan hal lain, misalnya LLM
Situasi ketika seseorang meninjau kode C yang ia tulis sendiri, misalnya rsync, sulit dibilang berada di posisi yang bagus dalam spektrum ini. Saya sama sekali tidak bermaksud menyalahkan Andrew
Saya bisa bersimpati pada maintainer pensiunan yang ingin berlayar, tetapi saya rasa konteks itu pada dasarnya tidak mengubah apa pun
Tridgell tidak berutang pekerjaan apa pun kepada kita, dan ia bebas pensiun lalu berlayar. Jika itu yang ia inginkan, saya berharap yang terbaik baginya. Saya juga paham rasa tanggung jawab yang ia rasakan, tetapi kalau saya membaca yang tersirat dengan benar, ia tampaknya juga merasakannya sebagai beban sampai taraf tertentu
Namun rsync adalah perangkat lunak inti, dan menurut saya orang yang memilih memeliharanya harus memenuhi standar kualitas tertentu. Jika pekerjaan maintainer tidak mencapai standar itu, maka itu adalah kesalahan. Itu tentu bukan alasan untuk merundungnya. Mengatakan sesuatu adalah kesalahan tidak berarti orang yang melakukannya buruk atau bahwa kita tidak bersimpati padanya
Jadi pertanyaannya adalah apakah pekerjaan yang dilakukan alat coding AI memenuhi standar itu. Standarnya kira-kira adalah, “apakah pekerjaan dengan kualitas seperti ini lebih baik daripada tidak ada pekerjaan sama sekali.” Jika itu membuat perangkat lunak lebih baik, lanjutkan. Jika malah membuatnya lebih buruk, hentikan. Saya tidak mengklaim ini definisi yang cerdas, tetapi menurut saya ini definisi yang benar
Kita tidak berhak menuntut Tridgell melakukan pekerjaan tambahan, tetapi tetap ada ruang untuk mengatakan, jika memang benar, “ini membuat keadaan pengguna lebih buruk”
Sejujurnya saya belum sepenuhnya merapikan pikiran saya tentang bagaimana menilai pekerjaan ini. Ada regresi, dan Tridgell menjelaskannya sebagai edge case, tetapi tanpa konteks lebih banyak saya tidak tahu bagaimana membandingkan dampak regresi edge case itu dengan nilai dari perbaikan potensi isu keamanan
Mungkin ada yang teringat pada “WITHOUT ANY WARRANTY”, tetapi klausul itu tidak relevan di sini. Itu adalah penyangkalan tanggung jawab hukum, bukan penyangkalan kebanggaan atas craftmanship atau tuntutan non-hukum untuk melakukan yang terbaik. Komentar ini pun diberikan “WITHOUT ANY WARRANTY”, tetapi kalau saya melakukan kesalahan, tentu saya tetap bisa dikritik
Bukan penulisnya yang menjadikannya perangkat lunak inti. Jika Anda atau orang lain memakainya, tanggung jawabnya ada pada pengguna. Kalau perangkat lunaknya tidak bekerja sesuai harapan, Anda bisa mem-fork atau menggantinya. Yang tidak bisa dilakukan adalah memaksa orang itu bergerak mengikuti keinginan Anda
Konteks bagi yang melewatkan laporan regresi awal: https://github.com/RsyncProject/rsync/issues/929
Laporan issue itu berupa tangkapan layar dari mastodon post, dan setelah itu sudah ada lebih dari sekitar 300 komentar perdebatan
Tidak perlu dijelaskan, lakukan saja seperti biasa. Orang-orang yang tidak suka akan tetap tidak suka
Mereka mulai tidak menyukainya sejak orang berhenti menulis assembly, dan itu tidak akan berhenti di masa depan