- Pemeliharaan curl telah menjadi pekerjaan penuh waktu yang memadukan kepentingan publik, tantangan engineering, dan target kualitas, dan terus berlangsung sekitar 50 jam per minggu
- curl adalah pustaka dan alat transfer dengan basis instalasi sekitar 30 miliar, sehingga beban untuk memastikan kegagalan keamanan tidak menyebar ke pengguna sangat besar
- Saat ini arus masuk laporan keamanan 4–5 kali lebih tinggi dibanding 2024, dua kali tingkat 2025, dan rata-rata lebih dari satu laporan per hari sehingga perlu ditangani segera
- Penanganan keamanan mencakup verifikasi klaim, penilaian tingkat keparahan, penulisan patch, penentuan kapan bug diperkenalkan, penulisan advisory, hingga komunikasi dengan peneliti dan tim keamanan
- Menjelang rilis berikutnya, sudah ada 12 kerentanan terkonfirmasi yang menunggu, dan di tengah tekanan yang belum pernah terjadi sebelumnya, keterbatasan pendanaan serta dukungan personel mulai terlihat
Rasa tanggung jawab terhadap curl dan pemeliharaan jangka panjang
- Pekerjaan open source bukanlah sesuatu yang dikerjakan demi uang atau gaya hidup glamor, melainkan sesuatu yang terus dijalani karena makna sosialnya, nilai kepentingan publiknya, dan tantangan engineering untuk membuatnya bekerja bagi semua orang
- Pekerjaan pada curl menjadi penuh waktu sejak 2019, biasanya menghabiskan sekitar 50 jam per minggu, berlanjut siang dan larut malam, pada hari kerja maupun akhir pekan
- Tujuan curl adalah menjadi pustaka dan alat transfer terbaik yang mungkin ada, serta menjadi proyek papan atas dalam kualitas, performa, dan keamanan open source
- curl bukan proyek satu orang, dan tanpa anggota tim, curl tidak akan menjadi seperti sekarang, tetapi banyak orang masih sangat mengaitkan curl dengan Daniel Stenberg secara pribadi
- Kritik terhadap curl terasa seperti kritik terhadap keputusan dan pilihan yang didukung atau diambil sendiri, dan curl telah menjadi proyek pribadi yang mengubah hidup secara permanen
- Pada akhir 2026, proyek curl akan merayakan ulang tahun ke-30, dan jumlah instalasi curl di seluruh dunia disebut sekitar 30 miliar
Perubahan lingkungan laporan keamanan
- Dalam beberapa tahun terakhir, lingkungan laporan keamanan curl telah berubah dari keluhan tentang LLM yang bodoh menjadi laporan AI slop, berakhirnya bug bounty, dan kekacauan berkualitas tinggi yang dimulai sekitar Maret 2026
- Setiap kali kegagalan keamanan besar berulang pada produk internet, infrastruktur perangkat lunak, dan open source, tekanan meningkat karena fakta bahwa curl ada di mana-mana dan hal seperti itu tidak boleh terjadi pada curl atau penggunanya
- Proyek curl telah terus menambahkan lebih banyak pemeriksaan, pengujian, dan panduan, sedikit demi sedikit mengurangi kemungkinan cacat lolos atau tenggelam tanpa diketahui
Tingkat verifikasi yang tinggi dan risiko yang tetap ada
- Setelah kejadian Mythos hanya menemukan satu masalah berkeparahan rendah pada pemindaian pertamanya, penilaian bahwa curl adalah salah satu kode yang paling banyak ditinjau, di-fuzz, dan diverifikasi pada tingkat yang bisa dibayangkan terus berulang
- Kondisi ini bukan kebetulan atau keberuntungan, melainkan hasil dari kerja keras puluhan tahun yang gigih, perhatian pada detail, dan perbaikan berulang yang tak pernah selesai
- Meski banyak ditinjau dan diverifikasi, itu tidak berarti tidak ada bug atau masalah keamanan; curl adalah ratusan ribu baris kode C yang menjalankan jaringan sangat paralel di berbagai protokol, sistem operasi, dan arsitektur CPU
- Setiap kali masalah ditemukan, proses memperbaikinya dan merilis patch terus terulang
- Basis instalasi global sekitar 30 miliar berarti ada kemungkinan curl hadir berkali-kali di ponsel, tablet, mobil, TV, printer, konsol game, dan perangkat dapur
- Proyek-proyek yang di masa lalu membuat dunia gaduh untuk sementara karena bug besar biasanya mendapat sorotan, dan sebagian memperoleh dana serta personel untuk mempekerjakan beberapa engineer penuh waktu
Volume laporan keamanan yang belum pernah terjadi sebelumnya
- Saat ini laju masuk laporan keamanan 4–5 kali lebih tinggi daripada 2024, dua kali 2025, dan rata-rata lebih dari satu laporan per hari
- Kualitas laporan jauh lebih tinggi daripada sebelumnya, dan umumnya ditulis sangat rinci dan panjang
- Karena laporan terus berdatangan, semuanya harus ditangani sebisa mungkin segera setelah tiba; jika tidak diproses pada laju yang mendekati kedatangannya, daftar potensi masalah keamanan akan terus menumpuk
- Daftar potensi masalah keamanan yang tidak terkendali menciptakan beban mental
- Saat ini, sebagian besar waktu dihabiskan untuk menangani daftar isu keamanan yang dilaporkan di HackerOne
- Pekerjaan utama meliputi verifikasi klaim, penilaian tingkat keparahan, penulisan patch, penentuan kapan bug diperkenalkan, pemahaman kerentanan, penulisan advisory keamanan yang rinci, serta komunikasi dengan peneliti keamanan dan tim keamanan curl
Tekanan pada kesehatan dan tim
- Untuk pertama kalinya, pasangan hidupnya mengkhawatirkan jam kerja dan kondisi kerja-kehidupan yang tidak seimbang, dan orang-orang di sekitarnya juga khawatir bagaimana arus besar ini dapat ditangani serta kemungkinan burnout
- Kekhawatiran terhadap anggota tim juga meningkat, dan mungkin dalam waktu dekat perlu mengurangi jam kerja agar bisa mendapat waktu untuk bernapas
- Situasi saat ini adalah tekanan yang belum pernah dialami sebelumnya oleh proyek curl maupun anggota tim keamanannya
- Penanganan isu keamanan adalah pekerjaan prioritas tertinggi yang mengalahkan semua pekerjaan lain dalam proyek, dan tidak diabaikan karena rasa tanggung jawab, hati nurani, dan kebanggaan terhadap pekerjaan
- Karena curl adalah perangkat lunak yang didistribusikan ke perangkat di seluruh dunia, ada rasa kewajiban yang kuat untuk memperbaiki masalah keamanan di dalamnya
- Menjelang rilis terjadwal, ketika sekitar setengah dari siklus rilis masih tersisa, sudah ada 12 kerentanan terkonfirmasi, yang berarti 12 pengumuman CVE sedang menunggu
- Ini adalah rekor baru proyek, dan berarti jumlah CVE publik pada 2026 mencapai 30 bahkan sebelum tahun itu berjalan setengah
- Jika tren ini berlanjut, jumlah total pengungkapan CVE curl sepanjang 2026 diperkirakan setidaknya dua kali lipat dari angka itu
Dukungan yang dibutuhkan dan keterbatasan struktural
- Dalam jangka pendek, pekerjaan yang sudah harus ditangani terlalu banyak sehingga sudah terlambat untuk langsung menerima bantuan
- Jika lebih banyak perusahaan yang menggunakan dan bergantung pada curl atau libcurl dalam perangkat lunak dan layanan komersial memberikan dukungan pendanaan, maka beban kerja bisa dibagi dengan membayar lebih banyak pengembang
- Jalur dukungan lain yang memungkinkan adalah melalui kontrak dukungan agar pemberi kerja membayarkan biayanya
- Sudah ada pelanggan yang memberikan dukungan seperti ini sehingga sebagian anggota dapat mengerjakan curl secara penuh waktu
- Namun, tidak ada harapan bahwa perubahan berarti di area ini akan segera terjadi, dan bahkan dalam situasi yang belum pernah terjadi sebelumnya serta fase yang lebih sulit, kemungkinan besar tetap harus melewati badai ini sendiri
- Proyek curl tidak dimiliki perusahaan dan tidak berada di bawah organisasi payung mana pun
- Struktur seperti ini kadang membuat sumber daya menjadi kurang, tetapi sekaligus memberi kebebasan dan fleksibilitas semaksimal mungkin
- Standar perilaku proyek berfokus pada membuat curl sebaik mungkin demi dunia dan para pengguna curl
Sisi positif dan kondisi saat ini
- Memperbaiki bug dan masalah itu sendiri adalah hal yang baik, dan satu masalah yang dilaporkan berarti satu isu yang akan diperbaiki
- Semakin banyak laporan, semakin baik produk curl
- Dalam beberapa tahun terakhir, semua kerentanan curl yang ditemukan dinilai berkeparahan LOW atau MEDIUM, dan kerentanan yang sangat serius hampir tidak ditemukan
- Ini tidak berarti HIGH tidak akan muncul lagi di masa depan, tetapi setidaknya itu kini jarang terjadi
- CVE curl dengan keparahan tinggi yang paling baru adalah CVE-2023-38545, yang diumumkan pada Oktober 2023
- Saat ini tim curl sedang berada di bawah tekanan, dan terkadang respons bisa lambat
1 komentar
Komentar Lobste.rs
Semoga Daniel dan yang lain bisa melewati situasi sulit ini tanpa dampak buruk besar pada kesehatan atau keluarga mereka
Namun, akan cukup menarik melihat bagaimana ini berkembang. Ini bukan pertama kalinya metode analisis otomatis baru tiba-tiba menemukan banyak kerentanan di berbagai proyek FOSS, dan sekarang rasanya mirip dengan saat greybox fuzzing muncul pada 2010-an. Tampaknya ada tiga kemungkinan perkembangan: A) para pengembang memasukkan LLM ke dalam alur riset keamanan sehingga jumlah kerentanan baru yang ditemukan LLM turun drastis, sementara kerentanan yang tidak bisa dijangkau LLM terus ditemukan, seperti pada skenario fuzzer. B) Mirip A, tetapi setelah LLM menyapu semuanya, penemuan kerentanan pada dasarnya berhenti, yaitu skenario “LLM menyelesaikan riset keamanan”. C) Kerentanan terus ditemukan pada tingkat tinggi di proyek besar seperti curl, dan jumlah bug pada proyek berkode ratusan ribu baris pada dasarnya tak terbatas, yaitu skenario “balas dendam Tony Hoare”
Pada snapshot tertentu dari suatu codebase, hanya bisa ada sejumlah terbatas bug keamanan. Setelah ruang pencarian bug keamanan habis, banjir itu akan mereda, dan setelahnya mungkin hanya tersisa bug yang sedikit demi sedikit muncul dari penggabungan kode, test harness baru, atau perbaikan model
Terkait skenario C untuk proyek curl, saya rasa bug yang ditemukan cenderung berdampak rendah karena standar pengujian keamanan dan teknik penemuan bug tradisional yang sudah tinggi sebelumnya. Ini menunjukkan bahwa investasi berkelanjutan dalam penemuan bug tetap membuahkan hasil dalam jangka panjang. Hal ini akan tetap benar, apa pun metode penemuan yang ada hari ini atau di masa depan
Meminjam kata-kata Marcus Hutchins, “penemuan bug tidak pernah menjadi bottleneck; bottleneck-nya adalah keputusan organisasi untuk tidak berinvestasi pada peneliti keamanan”. LLM hanya membuat investasi itu lebih murah, dan organisasi sebenarnya selalu bisa berinvestasi lebih banyak untuk menemukan lebih banyak bug. Pada akhirnya ini soal kebijakan
Perusahaan yang membuat teknologi LLM sedang merusak bukan hanya dunia alami, tetapi juga dunia perangkat lunak. Harga hardware melonjak sehingga komputasi personal itu sendiri ikut terancam, begitu juga para pengembang open source beritikad baik yang membuat sesuatu karena mereka memang ingin membuatnya
Sepertinya ada dana tanpa batas untuk merendahkan dan merusak proyek open source yang dikelola komunitas, tetapi sama sekali tidak ada uang untuk menangani dampak setelahnya, dan itu menarik
Menurut saya ini membuktikan bahwa Zig benar. CVE yang ditemukan LLM sebaiknya diabaikan saja, dan biarkan yang mau menanganinya yang mengurusnya
Saya tahu itu bukan tepat inti persoalannya, tetapi masalah CVE dari LLM adalah orang lain yang memakai alat yang sama kemungkinan besar juga bisa menemukan hal yang sama. Jika masalah yang serius benar-benar ditemukan, itu berarti lebih banyak orang bisa membuat sesuatu yang berbahaya dengannya
Tentu ini tidak berarti hal yang sama berlaku untuk banjir isu berdampak rendah atau non-keamanan pada curl. Tetap saja, seseorang harus benar-benar menilai isu mana yang berprioritas tinggi, dan itu membawa kita kembali ke langkah pertama
Zig masih sangat aktif dikembangkan, dan setiap kali mereka mematangkan fitur seperti incremental compilation atau asynchronous I/O, ada kemungkinan besar mereka memasukkan bug baru, sambil sekaligus menghapus bug yang muncul karena implementasi sebelumnya belum lengkap
Pada tahap pengembangan seperti ini, jika seseorang menjalankan sesuatu seperti Mythos terhadap Zig dengan pendekatan “temukan semua bug dan jangan membuat kesalahan”, akan keluar laporan dalam jumlah besar, tetapi keseluruhan hasil itu kemungkinan pada dasarnya tidak berguna bagi kami. Nilai utama laporan bug saat ini adalah memberi sinyal bahwa ada pengguna yang terhambat pada use case tertentu, dan jika kami memutuskan untuk memprioritaskannya, kami bisa membantu pengguna itu keluar dari kebuntuannya
Bukan berarti keadaan ini akan berlangsung selamanya. Banyak fitur compiler penting sedang diselaraskan, dan ketika sudah stabil, menemukan dan memperbaiki semua bug akan menjadi prioritas utama. Pada saat itu, fakta bahwa bug itu diketahui akan menjadi penting terlepas dari cara menemukannya, tetapi masalah itu akan ditangani saat waktunya tiba
Sementara itu, kebijakannya sederhana: melarang LLM
Saya bisa memahami pelarangan kontribusi LLM, tetapi saya tidak setuju. Kerentanan keamanan tetaplah kerentanan, terlepas dari bagaimana ia ditemukan
Menurut saya cara Daniel adalah yang terbaik. Memperbaiki bug yang bisa diperbaiki agar pengguna lebih aman, sambil menjelaskan bahwa biaya untuk melakukannya besar dan meminta dukungan. Kemungkinan kecil dia akan membaca ini, tetapi saya juga ingin mendukung dan menganjurkan agar dia membatasi beban kerja demi memprioritaskan kesehatan fisik dan mentalnya. Sebagian besar dunia akan mengerti, dan sepertinya hanya sedikit orang yang akan mengeluh
Tampaknya ada dua hal penting yang hilang di sini. 1) Perusahaan LLM atau Project Zero bukan pihak yang memasukkan bug keamanan itu ke dalam kode. 2) Memperbaiki bug keamanan bukan untuk perusahaan LLM atau Project Zero, melainkan untuk pengguna. Jika bug keamanan dieksploitasi, pengguna yang dirugikan
Khusus untuk bug yang ditemukan LLM, sudah ada sinyal bahwa orang lain yang memakai LLM yang sama di berbagai proyek open source mengirim laporan duplikat. Karena itu, jika pihak bertahan melepaskan tangan, kita harus mengasumsikan pihak penyerang juga akan mengetahui bug yang ditemukan LLM
“Saya iri pada proyek-proyek yang pernah merilis bug mengerikan yang sempat membakar dunia untuk sementara. Mereka mendapat perhatian, dan sebagian bahkan memperoleh dana serta kekuatan finansial untuk memiliki staf dan mempekerjakan beberapa engineer full-time. Kadang saya berpikir mungkin lebih baik kalau kami juga punya satu seperti itu”
Hal seperti ini juga terjadi di banyak tempat kerja. Tim yang gagal mendapat tambahan orang, sementara tim yang berjalan baik harus melakukan lebih banyak dengan orang lebih sedikit justru karena tidak ada hal mengerikan yang terjadi
Saya tidak yakin apakah ini cocok untuk proyek seperti curl, tetapi apakah feature freeze selama periode tertentu agar mereka bisa fokus hanya pada laporan bug/CVE yang masuk akan membantu?
Dengan kumpulan fitur yang tetap, jumlah potensi bug/CVE mestinya terbatas, dan jika terus diperbaiki rasanya akan mendekati 0
Bagaimanapun, semoga mereka beruntung. Menjaga perangkat lunak sepenting itu pada masa seperti ini pasti tidak mudah
Dampaknya pada kepuasan pengembang, secara berurutan, adalah naik, tetap, lalu turun
Feature freeze adalah alat yang sangat baik untuk membantu menyelesaikan rilis dengan baik, tetapi bukan alat yang baik untuk mengurangi tekanan pada pengembang yang bekerja mandiri dan menentukan arahnya sendiri