- Setelah menjalankan bug bounty selama sekitar 1 tahun dengan hadiah $1.000 untuk bug yang terbukti menyebabkan kerusakan data, Turso kini menghentikan program tersebut
- Begitu ada imbalan uang, PR berkualitas rendah buatan AI membanjiri repositori, dan para maintainer menghabiskan berhari-hari hanya untuk menutupnya
- Pada tahap awal, Turso memberi hadiah kepada 5 orang, dan sebagian kontribusi tersebut menghasilkan perbaikan simulator serta penemuan lebih dari 10 bug di SQLite
- Turso sempat memakai sistem vouching untuk menutup otomatis PR yang dicurigai, tetapi bot terus membuka issue permintaan tinjauan manual dan mengirim ulang PR serupa
- Untuk mempertahankan kontribusi terbuka, Turso memilih menghapus insentif finansial alih-alih menutup sistem
Mengapa Turso menghentikan bug bounty
- Selama hampir 1 tahun, Turso membayar $1.000 untuk bug yang terbukti dapat menyebabkan kerusakan data, tetapi kini program itu dihentikan
- Setelah ada hadiah uang, repositori Turso dibanjiri PR berkualitas rendah buatan AI, dan para maintainer harus menghabiskan sebagian besar waktu mereka selama berhari-hari untuk menutup PR semacam itu
- Turso ingin tetap menjadi proyek dengan kontribusi terbuka, tetapi menilai bahwa struktur pemberian uang untuk jenis bug tertentu membuat pengelolaan kontribusi terbuka nyaris mustahil
- Keputusan ini diumumkan dengan kesadaran bahwa kita perlu bersama-sama belajar membangun tata kelola open source di era baru
Latar belakang dimulainya program
- Turso sedang mengimplementasikan ulang SQLite, yang dikenal sebagai salah satu perangkat lunak paling andal di dunia, sehingga membutuhkan standar keandalan yang sama tinggi
- Turso menjalankan berbagai sistem pengujian untuk menyamai atau melampaui tingkat keandalan SQLite
- simulator deterministik native
- beberapa fuzzer
- mesin differential testing berbasis oracle yang membandingkan dengan SQLite
- simulator konkurensi
- eksekusi ekstensif di Antithesis
- Infrastruktur pengujian pada akhirnya juga merupakan perangkat lunak, jadi tidak sempurna, dan hanya bisa menangkap bug dalam kombinasi yang benar-benar dihasilkan oleh generator
- Misalnya, jika fuzzer tidak membuat indeks, maka meskipun bagian lain dari sistem diuji dengan sangat keras, bug terkait indeks akan sulit ditemukan
- Turso menemukan bug yang hanya muncul ketika database lebih besar dari 1GB, tetapi karena setiap eksekusi menyuntikkan kegagalan secara agresif, database tidak pernah tumbuh sampai ukuran itu sehingga lolos dari simulator
- Keuntungan pengujian otomatis adalah bahwa meskipun ada bug yang sempat lolos, dengan memperbaiki generator pengujian, kita bisa menghilangkan seluruh kategori bug tersebut
- Bug bounty adalah mekanisme untuk menunjukkan kepercayaan Turso pada metodologi pengujiannya, sekaligus memberi imbalan jika ada orang yang menemukan area yang tidak tertangani dengan baik oleh simulator
- Rencana awalnya adalah membayar $1.000 untuk bug kerusakan data hingga rilis Turso 1.0, lalu setelah 1.0 secara bertahap memperluas nilai hadiah dan cakupan targetnya
Dampaknya sebelum lonjakan kiriman berkualitas rendah dari AI
- Pada fase awal program, total 5 orang menerima hadiah, dan mereka memberi kontribusi yang bermakna bagi proyek
- Alperen adalah salah satu kontributor inti untuk simulator Turso dan tahu bagian mana yang masih bisa ditingkatkan
- Mikael menggunakan LLM secara kreatif untuk menemukan area yang tidak bisa dijangkau simulator, dan kemudian direkrut ke Turso
- Pavan Nambi menggabungkan simulator dan teknik formal untuk menemukan bukan hanya bug di Turso, tetapi juga lebih dari 10 bug di SQLite sendiri
Beban operasional akibat kiriman buatan AI
- Standar kiriman yang diinginkan Turso bukan sekadar menunjuk bug, melainkan memperluas simulator untuk membuktikan bug kerusakan data
- Berkat syarat ini, PR buruk yang hanya mengejar hadiah jarang muncul, dan bug kerusakan data yang nyata juga tidak banyak
- Setelah itu, muncul banjir kiriman yang menginstruksikan LLM untuk mencari bug di Turso dan mendapatkan hadiah
- Saat diberi instruksi seperti itu, LLM akan menghasilkan apa pun, tetapi apakah hasilnya valid adalah persoalan lain
Contoh kiriman berkualitas rendah
-
PR yang merusak header database secara manual
- PR #6257 mengklaim database rusak setelah menyuntikkan byte sampah secara manual ke header database
- Bahkan setelah maintainer menjelaskan bahwa hasil tersebut sudah jelas, pengirim atau bot tetap melanjutkan bantahan panjang khas LLM
-
Kiriman yang langsung menambahkan akses out-of-bound ke source code
- Kiriman lain secara manual menambahkan akses array out-of-bound ke source code untuk merusak database
- issue terkait: tursodatabase/turso#5508
-
PR yang mengklaim eksekusi SQL sebagai kerentanan
- PR #4322 penuh dengan tabel, tanda centang hijau, dan em dash, serta mengklaim telah menemukan kerentanan kritis yang memungkinkan eksekusi pernyataan SQL arbitrer
- Turso menilai bahwa fakta bahwa database SQL mengizinkan eksekusi pernyataan SQL itu sendiri tidak bisa dianggap sebagai kerentanan
-
PR yang salah memahami fitur concurrent write milik Turso
- PR #6874 mengaktifkan concurrent write, salah satu pembeda Turso, lalu menunjukkan bahwa SQLite tidak bisa membuka file sampai mode jurnal dikembalikan ke WAL dan concurrent write dinonaktifkan
- Itu adalah hasil dari sistem yang bekerja sesuai rancangan
-
Kiriman yang sulit dipahami maksudnya
- Kiriman lainnya berisi hal-hal yang sulit dipahami tujuannya
- Maintainer Mikael menilai bahwa pengirimnya menargetkan Turso dengan alat buatan AI setelah melihat pengumuman hadiah
Respons terakhir: sistem vouching
- Sebagai upaya terakhir untuk menata keadaan, Turso merancang dan menerapkan sistem vouching
- Sistem ini menutup otomatis kiriman yang dicurigai berasal dari bot, dan untuk sementara cukup efektif
- Setelah itu, bot mulai membuka issue yang meminta tinjauan manual dengan mempersoalkan alasan PR mereka ditutup
- Beberapa kali juga terjadi hal yang sama atau sangat mirip: ketika satu PR ditutup, pengguna yang sama atau pengguna lain segera membuka kembali PR yang identik atau sangat mirip
Benturan antara kontribusi terbuka dan insentif finansial
- Pihak yang membuat kiriman berkualitas rendah hanya perlu sekitar 1 menit untuk membuatnya, tetapi Turso harus menghabiskan berjam-jam untuk membaca, memahami, dan menanggapinya
- Kiriman seperti ini pada praktiknya bisa dibuat dengan laju yang nyaris tak terbatas
- Sistem gatekeeping otomatis memang bisa dibuat, tetapi jika ada hadiah uang yang cukup besar, AI akan terus punya insentif untuk berdebat dan membuka kembali PR yang sama
- Turso menghargai komunitas kontributor open source dan akan terus memperkuatnya, tetapi untuk saat ini mereka menilai bahwa segala bentuk insentif finansial tidak bekerja baik dalam sistem terbuka
- Pilihannya adalah menutup sistem atau menghapus insentif, dan untuk sekarang Turso memilih yang kedua
1 komentar
Komentar Hacker News
Ini menunjukkan bahwa hambatannya bukan pada menulis kode, melainkan pada membaca dan memahaminya
Dulu pun, di tiap tim biasanya ada satu insinyur yang “produktif” yang gemar mengajukan PR raksasa berisi refactor besar-besaran, entah memang perlu atau tidak. Itu sudah terjadi bahkan sebelum orang membayangkan jaringan saraf bisa menghasilkan kode sebanyak ini
Hasil dari “produktivitas” seperti itu bukan mempercepat tim, melainkan hampir membuatnya berhenti total. Waktu habis untuk meninjau PR dengan teliti, atau orang asal bilang LGTM lalu semuanya meledak di production dan semua orang harus kembali ke papan gambar. Ditambah lagi, karena “produktivitas” orang itu, struktur proyek berubah terlalu cepat sehingga satu-satunya orang yang benar-benar tahu letak semuanya hanyalah satu orang yang “sangat pintar, berbakat, produktif, dan setia pada tujuan perusahaan” itu
“Hampir setiap organisasi pengembangan perangkat lunak memiliki setidaknya satu pengembang yang mendorong pemrograman taktis hingga ke titik ekstrem: tactical tornado. Tactical tornado adalah programmer produktif yang menghasilkan kode jauh lebih cepat daripada orang lain, tetapi bekerja sepenuhnya secara taktis. Untuk membuat satu fitur cepat, tidak ada yang lebih cepat darinya. Di beberapa organisasi, manajer memperlakukan tactical tornado seperti pahlawan. Namun tactical tornado meninggalkan jejak kehancuran. Para insinyur yang nantinya harus bekerja dengan kode itu sering kali tidak menganggapnya pahlawan. Biasanya insinyur lainlah yang harus membersihkan kekacauan yang ditinggalkan tactical tornado, dan karena itu para insinyur yang sebenarnya heroik itu terlihat bergerak lebih lambat daripada tactical tornado.”
Apalagi, semakin banyak kode yang dihasilkan AI, semakin sedikit pula orang yang benar-benar memahaminya
Tetap saja, jika regression test dan linter sudah sangat baik sehingga kita tahu kodenya berjalan dan tidak buruk-buruk amat, maka review seharusnya lebih berfokus pada kualitas tingkat tinggi secara keseluruhan daripada membedah akurasi tiap karakter. Tentu saja review-nya sendiri tetap menyakitkan
Secara alami saya lebih banyak membaca dan memahami kode daripada menulisnya, dan kadang jumlah baris kode yang saya hasilkan justru negatif, dan saya bangga akan itu
Sekarang, berkat AI, saya jadi menulis lebih sedikit kode, dan saya sudah menyerah pada mimpi mencari rasa pencapaian dengan cara itu. Entah dibuat mesin atau manusia, kemampuan untuk cepat memahami sejumlah besar kode dari sumber yang meragukan semoga tetap bernilai sampai saya pensiun, apalagi jika dibantu AI. Bagaimana menurut kalian?
Kita tidak hanya menulis kode yang akan dijalankan mesin, tetapi juga kode yang akan dibaca manusia. Code review, debugging, dan perubahan di masa depan semuanya melibatkan membaca dan memahami kode yang ditulis seseorang. Dan sampai ada AI yang bisa dimintai pertanggungjawaban atas tindakannya, pemahaman itu tidak bisa didelegasikan ke AI
Ini saat yang tepat untuk menyebut proyek bagus ini sebagai repositori honeypot untuk memancing bot
https://github.com/UnsafeLabs/Bounty-Hunters
Leaderboard terkait ada di sini
https://clankers-leaderboard.pages.dev
Saya penasaran apa yang akan terjadi jika AI belajar dari repositori seperti itu dan aktivitas di dalamnya. Apakah laporan bug di issue itu benar-benar masalah yang bisa diperbaiki, atau cuma omong kosong yang dikarang?
Hanya saja, besar kemungkinan tak lama lagi akan masuk daftar blokir bot AI
Menutup program ini sepenuhnya masuk akal. Namun ada opsi lain. Buat pengirim membayar biaya kecil, lalu dikembalikan jika ditemukan bug nyata
Apakah program itu benar-benar membayar hadiah atau tidak, itu tidak penting. Begitu satu laporan saja ditutup secara keliru, cerita itu akan diulang tanpa henti
Dalam kasus seperti itu, sekarang pun orang sudah kehilangan waktu, dan nantinya mereka juga akan kehilangan uang
Apalagi untuk perusahaan kecil, sebelum mengirimkan laporan kita tidak tahu bagaimana reaksi mereka
Mungkin saja sebelum pengiriman diwajibkan menjalankan seluruh test suite simulator? Itu bisa jadi pemeriksaan yang baik untuk memastikan pengirim tidak merusak simulator, dan sekaligus mungkin menghasilkan artefak proof-of-work. Apakah itu memungkinkan, saya kurang tahu karena tidak terlalu paham sisi keamanan
Sudah lebih dari setahun saya mencoba membuat TursoDB memuat satu file, tapi gagal: https://github.com/ClickHouse/ClickBench/issues/336
Saya penasaran seperti apa jadinya Hacktoberfest sekarang jika mereka masih memberi semua orang kaus. Mungkin kapas di seluruh dunia tidak akan cukup
Tanggung jawab menghentikan ini seharusnya tidak dibebankan pada maintainer individu; menurut saya GitHub dan GitLab harus memblokir akun seperti ini sebelum mereka sampai pada tahap bisa membuka PR. Ini pada dasarnya spam
Lihat pengguna yang membuat PR pertama yang disebut di tulisan itu: https://github.com/Samuelsills. Akun seperti ini seharusnya tidak boleh mendekati kemampuan membuka PR ke repositori terkenal
Saya tidak terlalu paham bidang ini jadi mungkin pertanyaan bodoh, tetapi jika pada akhirnya diwajibkan menjalankan seluruh test simulator untuk memastikan perubahan simulator yang diajukan tidak merusak fungsi yang ada, apakah itu bisa berfungsi sebagai proof-of-work?
Bagaimana kalau alih-alih program bounty dibuat semacam pasar prediksi benar/salah
Orang bertaruh secara terbuka pada jawabannya, lalu masing-masing memakai token mereka sendiri untuk memverifikasi substansi laporan dan membeli taruhan. Jika mayoritas menilai itu salah, operator menang; jika mayoritas menilai itu benar, operator membayar
Ini bercanda, tapi mungkin juga tidak sepenuhnya bercanda
Adakah yang pernah memakai Turso di production? Ini implementasi kompatibel SQLite yang ditulis ulang dalam Rust, dengan tambahan fitur seperti dukungan multi-writer, dan tidak seperti SQLite, terbuka juga untuk kontribusi eksternal
Saya sedang mempertimbangkan memakainya di aplikasi Rust full-stack, karena semuanya bisa berjalan lewat cargo dan tidak perlu membawa SQLite secara terpisah
Turso juga menawarkan database-as-a-service dengan paket gratis yang sangat murah hati, dan itu alasan utama saya memakainya
https://x.com/doodlestein/status/2052910351474209258
Kenapa tidak melawan dengan cara yang sama dan menerapkan bot AI sendiri untuk meninjau PR lebih dulu?
“Kita bisa menyiapkan sistem otomatis untuk menghentikan ini, tetapi jika ada nilai uang yang cukup besar sehingga sulit diabaikan, insentif untuk membuat AI terus berdebat dan membuka kembali PR yang sama akan terlalu kuat”
Dari sudut pandang orang luar, ini masalah pelik yang menarik. Kira-kira berapa banyak agen di balik permintaan bot itu yang memakai Turso di backend mereka sendiri?