Bug bounty programını sonlandırıyoruz
(turso.tech)- Turso, veri bozulmasını kanıtlayan hatalara 1.000 dolar ödediği bug bounty programını yaklaşık 1 yıl işlettikten sonra sonlandırdı
- Ödül konulunca AI tarafından üretilmiş düşük kaliteli PR'ler büyük miktarda gelmeye başladı ve bakımcılar günler boyunca bunları kapatmakla uğraştı
- Başlangıçta 5 kişiye ödül verildi; bazı katkılar simülatörün iyileştirilmesine ve SQLite'ta 10'dan fazla hatanın bulunmasına yol açtı
- Turso, şüpheli PR'leri otomatik kapatan bir kefil olma sistemi kurdu, ancak botlar manuel inceleme isteyen issue'lar açıp benzer PR'leri yeniden göndermeyi sürdürdü
- Turso, açık katkıları korumak için sistemi kapatmak yerine maddi teşvikleri kaldırmayı seçti
Turso neden bug bounty'yi durdurdu?
- Turso, yaklaşık bir yıldır veri bozulmasına yol açabileceği kanıtlanan hatalar için 1.000 dolar ödüyordu, ancak artık programı sonlandırıyor
- Maddi ödül eklenince Turso deposuna AI tarafından üretilmiş düşük kaliteli PR'ler akın etti ve bakımcılar günler boyunca zamanlarının büyük kısmını bu PR'leri kapatmaya ayırmak zorunda kaldı
- Turso açık katkılara dayalı bir proje olarak kalmak istiyor, ancak belirli hata türleri için para ödeyen yapının açık katkı operasyonunu neredeyse imkansız hale getirdiğini düşünüyor
- Bu karar, yeni çağın açık kaynak yönetişimini nasıl kuracağımızı birlikte öğrenmemiz gerektiği anlayışıyla paylaşıldı
Programı başlatma gerekçesi
- Turso, dünyanın en güvenilir yazılımlarından biri olarak bilinen SQLite'ı yeniden uyguluyor ve bu yüzden aynı derecede yüksek bir güvenilirlik standardına ihtiyaç duyuyor
- Turso, SQLite düzeyindeki güvenilirliği yakalamak ya da aşmak için birden fazla test sistemi işletiyor
- Yerel deterministik simülatör
- Birden fazla fuzzer
- SQLite ile karşılaştırma yapan oracle tabanlı diferansiyel test motoru
- Eşzamanlılık simülatörü
- Antithesis üzerinde kapsamlı çalıştırmalar
- Ancak test altyapısı da sonuçta bir yazılım; kusursuz değil ve yalnızca üreticinin gerçekten oluşturduğu kombinasyonlar içinde hata yakalayabiliyor
- Örneğin bir fuzzer index oluşturmuyorsa, sistemin diğer kısımlarını ne kadar yoğun test ederse etsin index ile ilgili hataları bulması zorlaşıyor
- Turso, yalnızca veritabanı 1 GB'tan büyük olduğunda ortaya çıkan bir hata buldu; her çalıştırmada arızalar agresif biçimde enjekte edildiği için veritabanı bu boyuta hiç ulaşamıyor ve simülatörden kaçıyordu
- İlgili yazı: Uyumlu sistemler yazma macerası
- Otomatik testin avantajı, bir kez kaçan bir hata için test üreticisini iyileştirdiğinizde bütün bir hata kategorisini ortadan kaldırabilmenizdir
- Bug bounty, Turso'nun test metodolojisine olan güvenini gösterirken aynı zamanda birinin simülatörün iyi kapsamadığı alanları bulması halinde bunu ödüllendirmek için tasarlanmıştı
- İlk plan, Turso 1.0 çıkana kadar veri bozulması hataları için 1.000 dolar ödemek, 1.0'dan sonra ise ödül miktarını ve kapsamını kademeli olarak artırmaktı
AI kaynaklı düşük kaliteli gönderiler artmadan önce etkisi
- Programın ilk döneminde toplam 5 kişi ödül aldı ve bunlar projeye anlamlı katkılar sundu
- Alperen, Turso simülatörünün temel katkıcılarından biriydi ve geliştirilebilecek noktaları biliyordu
- Mikael, LLM'leri yaratıcı biçimde kullanarak simülatörün ulaşamadığı alanları buldu ve sonrasında Turso'da işe alındı
- Pavan Nambi, simülatörü biçimsel yöntemlerle birleştirerek yalnızca Turso hatalarını değil, SQLite'ın kendisinde de 10'dan fazla hata buldu
AI ile üretilen gönderilerin yarattığı operasyonel yük
- Turso'nun istediği gönderi standardı, sadece bir hatayı işaret etmek değil, simülatörü genişleterek veri bozulması hatasını kanıtlamaktı
- Bu şart sayesinde ödül hedefleyen kötü niyetli PR'ler nadirdi ve gerçek veri bozulması hataları da çok fazla değildi
- Daha sonra, LLM'lere Turso üzerinde hata bulup ödül kazanmalarını söyleyen çok sayıda gönderi gelmeye başladı
- LLM'ler böyle bir talimat aldıklarında herhangi bir çıktı üretebiliyordu, ancak bu çıktının geçerli olup olmadığı ayrı bir konuydu
Düşük kaliteli gönderilere tipik örnekler
-
Veritabanı header'ını elle bozup gönderilen PR
- PR #6257, veritabanı header'ına elle anlamsız baytlar enjekte edip ardından veritabanının bozulduğunu iddia ediyordu
- Bakımcı bunun beklenen sonuç olduğunu belirttikten sonra bile, gönderici ya da bot LLM tarzı uzun itirazlarını sürdürdü
-
Kaynak koda doğrudan out-of-bound erişim ekleyen gönderi
- Başka bir gönderi, veritabanını bozmak için kaynak koda elle out-of-bound dizi erişimi ekliyordu
- İlgili issue: tursodatabase/turso#5508
-
SQL çalıştırmayı zafiyet diye sunan PR
- PR #4322, tablolarla, yeşil onay işaretleriyle ve em dash'lerle doluydu; rastgele SQL ifadelerinin çalıştırılmasına izin veren kritik bir zafiyet bulduğunu iddia ediyordu
- Turso'ya göre bir SQL veritabanının SQL ifadelerini çalıştırabilmesi tek başına bir zafiyet sayılmaz
-
Turso'nun eşzamanlı yazma özelliğini yanlış anlayan PR
- PR #6874, Turso'nun ayırt edici özelliklerinden biri olan eşzamanlı yazmayı etkinleştirdikten sonra journal modunu WAL'a geri alıp eşzamanlı yazmayı kapatana kadar SQLite'ın dosyayı açamadığını gösteriyordu
- Bu, sistemin tasarlandığı şekilde çalışmasının bir sonucuydu
-
Niyetini anlamanın zor olduğu gönderi
- Bir başka gönderi, ne yapmaya çalıştığını anlamayı zorlaştıran bir içeriğe sahipti
- Bakımcı Mikael, göndericinin ödül duyurusunu görüp AI üretim araçlarını Turso'ya yönelttiğini düşündü
Son önlem: kefil olma sistemi
- Turso, düzeni sağlamak için son bir girişim olarak kefil olma sistemi tasarlayıp uyguladı
- Sistem, gönderinin bottan geldiğinden şüphelenildiğinde otomatik olarak kapatılmasına dayanıyordu ve bir süre kısmen işe yaradı
- Ardından botlar, PR'in neden kapatıldığını sorun ederek manuel inceleme talep eden issue'lar açmaya başladı
- Bir PR kapatıldığında aynı kullanıcı ya da başka biri tarafından aynı veya çok benzer PR'lerin hemen yeniden açıldığı da defalarca yaşandı
Açık katkı ile maddi teşviklerin çatışması
- Düşük kaliteli gönderi üreten taraf bunları hazırlamak için yaklaşık 1 dakika harcarken, Turso bunları okuyup anlamak ve yanıtlamak için saatler harcamak zorunda kalıyor
- Bu tür gönderiler pratikte neredeyse sonsuz hızda üretilebiliyor
- Otomatik gatekeeping sistemleri kurulabilir, ancak göz ardı edilemeyecek bir maddi ödül olduğunda AI'ın tartışmayı sürdürmesi ve aynı PR'yi yeniden açması için güçlü bir teşvik oluşuyor
- Turso açık kaynak katkıcı topluluğuna önem veriyor ve bunu güçlendirmeyi sürdürecek, ancak şu an için açık bir sistemde herhangi bir tür maddi teşvikin iyi işlemediğini düşünüyor
- Seçenek ya sistemi kapatmak ya da teşviki kaldırmak; Turso ise şimdilik ikincisini seçiyor
1 yorum
Hacker News görüşleri
Darboğazın kod yazmakta değil, kodu okuyup anlamakta olduğunu gösteriyor
Eskiden de her takımda bir tane “üretken” mühendis olurdu; gerekip gerekmediğine bakmadan, içine büyük çaplı refactor’lar karışmış dev PR’lar açardı. Sinir ağlarının bu kadar çok kod üretebileceğini hayal bile etmediğimiz zamanlarda da durum buydu
Böyle bir “üretkenliğin” sonucu takımın hızını artırmak değil, neredeyse durma noktasına getirmek olurdu. Ya PR’ı dikkatle review etmek için tüm zamanı harcardınız ya da üstünkörü LGTM derdiniz ve sonra prod’da patlar, herkes yeniden tasarım tahtasına dönmek zorunda kalırdı. Üstelik o kişinin “üretkenliği” yüzünden proje yapısı o kadar hızlı değişirdi ki, neyin nerede olduğunu gerçekten bilen tek kişi o “çok zeki, yetenekli, üretken ve şirket hedeflerine sadık” kişi olurdu
“Neredeyse her yazılım geliştirme organizasyonunda, taktiksel programlamayı uç noktaya taşıyan en az bir geliştirici vardır. Buna taktiksel tornado denir. Taktiksel tornado, diğerlerinden çok daha hızlı kod çıkaran üretken bir programcıdır ama tamamen taktiksel bir şekilde çalışır. Hızlıca tek bir özellik çıkarmak gerektiğinde ondan hızlısı yoktur. Bazı organizasyonlarda yöneticiler taktiksel tornadoyu bir kahraman gibi görür. Ancak taktiksel tornado arkasında bir yıkım izi bırakır. Daha sonra o kodla çalışmak zorunda kalan mühendisler onu çoğu zaman kahraman olarak görmez. Genellikle diğer mühendisler, taktiksel tornado’nun bıraktığı dağınıklığı temizlemek zorunda kalır ve bu yüzden asıl kahraman olan o mühendisler, taktiksel tornado’dan daha yavaş ilerliyormuş gibi görünür.”
Üstelik AI tarafından üretilen kod arttıkça, o kodu gerçekten anlayan insan sayısı daha da azalacak
Yine de regresyon testleri ve linter’lar iyi durumdaysa ve kodun çalıştığını, berbat olmadığını biliyorsanız, review süreci harf harf doğruluğu didiklemekten çok genel ve üst seviye kaliteye bakmalı. Elbette review’nin kendisi yine de acı vericiydi
Doğal olarak kod yazmaktan çok kod okuyup anlamakla vakit geçirdim ve bazen yazdığım satır sayısı negatif olurdu; bununla da gurur duyardım
Artık AI sayesinde daha da az kod yazıyorum ve bu şekilde tatmin bulma hayalinden vazgeçtim. Kimin ürettiği fark etmeksizin, şüpheli kaynaktan gelen büyük miktarda kodu hızlıca anlayabilme becerisinin, özellikle de AI yardımıyla, emekli olana kadar değerli kalmasını umuyorum. Sizce?
Biz sadece makinenin çalıştıracağı kodu yazmıyoruz; insanların okuyacağı kodu da yazıyoruz. Kod review, debugging ve gelecekteki değişikliklerin hepsi, birinin yazdığı kodu okuyup anlamayı içerir. Ve yaptıklarından sorumlu tutulabilecek bir AI ortaya çıkana kadar bu anlayışı AI’a devredemeyiz
Botları cezbetmek için kullanılan honeypot repo olarak bu harika projeden bahsetmek için iyi bir zaman
https://github.com/UnsafeLabs/Bounty-Hunters
Buna karşılık gelen sıralama tablosu da burada
https://clankers-leaderboard.pages.dev
AI böyle depoları ve içlerindeki etkinlikleri öğrenirse ne olacağını merak ediyorum. Issue’lardaki bug report’lar gerçekten düzeltilebilir sorunlar mı, yoksa uydurulmuş saçmalıklar mı?
Yalnız yakında AI bot blocklist listelerine girme ihtimali yüksek
Programı kapatmak tamamen makul. Ama başka seçenekler de var. Gönderen kişinin küçük bir ücret ödeyip, gerçek bir bug bulunduğunda parasını geri alacağı bir sistem kurulabilir
Programın gerçekten ödeme yapıp yapmaması önemli değil. Tek bir report bile yanlış şekilde kapatılırsa o hikâye sonsuza kadar anlatılır
Böyle durumlarda bugün zaten zaman kaybediyorsunuz, yarın bir de para kaybetmiş olursunuz
Özellikle küçük bir şirkette, göndermeden önce şirketin nasıl tepki vereceğini bilemezsiniz
Gönderimden önce simülatör test suite’inin tamamını çalıştırmayı zorunlu kılamaz mısınız? Bu, gönderenin simülatörü bozmadığını doğrulayan iyi bir kontrol olur ve yan ürün olarak bir proof-of-work çıktısı da üretebilir gibi görünüyor. Mümkün mü, güvenlik tarafını çok bilmediğim için emin değilim
Bir yıldan uzun süredir TursoDB’nin tek bir dosyayı yüklemesini sağlamaya çalıştım ama başaramadım: https://github.com/ClickHouse/ClickBench/issues/336
Hacktoberfest hâlâ herkese tişört veriyor olsaydı bugün nasıl görünürdü merak ediyorum. Muhtemelen dünyada yeterli pamuk kalmazdı
Bunun önlenmesinin sorumluluğu tek tek maintainer’ların üzerinde olmamalı; bence GitHub ve GitLab bu tür hesapları PR açabilecek aşamaya bile gelmeden durdurmalı. Bu özünde spam
Yazıda ilk geçen PR’ı açan kullanıcıya bakın: https://github.com/Samuelsills. Böyle hesaplar popüler depolara PR açmaya yaklaşamamalı bile
Alanı çok bilmediğim için aptalca bir soru olabilir ama gönderilen simülatör değişikliğinin mevcut işlevleri bozmadığını doğrulamak için sonda simülatör testlerinin tamamını çalıştırmayı zorunlu kılmak, bir proof-of-work işlevi görebilir mi?
Bounty programı yerine bir tür doğru/yanlış tahmin piyasası kurmak nasıl olur
İnsanlar cevaba açıkça bahis oynar, report’un gerçekliğini kendi token’larını kullanarak doğrular ve sonra buna göre bahis alır. Çoğunluk yanlış derse operatör kazanır, çoğunluk gerçek derse operatör ödeme yapar
Şaka yapıyorum ama belki de yapmıyorumdur
Turso’yu prod ortamında kullanan var mı? SQLite uyumlu, Rust ile yeniden yazılmış bir implementasyon; çoklu yazıcı desteği gibi özellikler eklenmiş ve SQLite’ın aksine harici katkılara da açık
Her şey cargo ile çalıştığı ve SQLite’ı ayrıca getirmem gerekmediği için tam yığın bir Rust uygulamasında denemeyi düşünüyorum
Turso ayrıca oldukça cömert ücretsiz plana sahip bir database-as-a-service de sunuyor; benim kullanmamın ana nedeni de buydu
https://x.com/doodlestein/status/2052910351474209258
Aynı yöntemle karşılık verip, PR’ları önceden incelemesi için kendi AI botunuzu devreye alamaz mısınız?
“Bunu önlemek için otomasyon sistemleri kurabilirsiniz ama işin içinde göz ardı edilemeyecek düzeyde parasal değer olduğunda, AI’ların durmadan tartışıp aynı PR’ı yeniden açması için teşvik fazla güçlü oluyor”
Dışarıdan bakan biri için ilginç bir zor problem. Acaba bu bot isteklerinin ne kadarı arka uçlarında Turso kullanıyor?