Baskı
(daniel.haxx.se)- curl bakımı, kamu yararı, mühendislik zorluğu ve kalite hedeflerinin birleştiği tam zamanlı bir işe dönüştü ve haftada yaklaşık 50 saat sürüyor
- curl, yaklaşık 30 milyar kurulum tabanına sahip bir aktarım kütüphanesi ve aracı; güvenlik hatalarının kullanıcılara yayılmaması gerektiği için üzerindeki yük büyük
- Şu anda güvenlik raporu akışı 2024'e göre 4-5 kat, 2025'in ise iki katı düzeyde; ortalama olarak günde birden fazla rapor geliyor ve bunların hemen ele alınması gerekiyor
- Güvenlik süreci; iddiaların doğrulanmasını, önem derecesinin değerlendirilmesini, yama yazılmasını, eklendiği zamanın tespit edilmesini, danışma metninin hazırlanmasını ve araştırmacılarla güvenlik ekibiyle iletişimi kapsıyor
- Planlanan sürüme kadar şimdiden doğrulanmış 12 zafiyet bekliyor; benzeri görülmemiş baskı altında finansman ve insan kaynağı desteğinin sınırları ortaya çıkıyor
curl'e karşı sorumluluk duygusu ve uzun vadeli bakım
- Açık kaynak çalışması, para ya da gösterişli bir yaşam için değil; toplumsal anlamı, kamu yararı ve herkes için çalışır hale getirme mühendislik zorluğu nedeniyle sürdürülen bir iş
- curl üzerindeki çalışma 2019'dan beri tam zamanlı hale geldi ve genelde haftada yaklaşık 50 saat; gündüzleri ve geç geceleri, hafta içi ve hafta sonlarını kapsayacak şekilde sürüyor
- curl'ün hedefi, mümkün olan en iyi aktarım kütüphanesi ve aracı olmak; açık kaynakta kalite, performans ve güvenlik açısından en üst düzey projelerden biri haline gelmek
- curl tek kişinin projesi değil; ekip üyeleri olmasaydı bugünkü curl de olmazdı, ancak birçok kişi hâlâ curl'ü güçlü biçimde Daniel Stenberg'in şahsıyla ilişkilendiriyor
- curl'e yönelik eleştiriler, kişinin bizzat desteklediği ya da aldığı karar ve seçimlere yönelik eleştiriler gibi hissediliyor; curl, hayatı kalıcı olarak değiştiren kişisel bir projeye dönüştü
- 2026 sonlarında curl projesi 30. yılını dolduracak ve dünya genelindeki curl kurulum sayısı yaklaşık 30 milyar olarak anılıyor
Güvenlik raporlama ortamındaki değişim
- Son birkaç yılda curl güvenlik raporlama ortamı, aptal LLM'lere yönelik şikâyetlerden AI slop raporlarına, bug bounty'nin sona ermesine, ardından 2026 Mart civarında başlayan yüksek kaliteli kaosa doğru değişti
- İnternet ürünlerinde, yazılım altyapısında ve açık kaynakta büyük güvenlik hataları tekrarlandıkça, curl'ün her yerde bulunduğu gerçeği ve böyle bir şeyin curl'de ya da kullanıcılarında yaşanmaması gerektiği yönündeki baskı da artıyor
- curl projesi daha fazla inceleme, test ve kılavuz ekleyerek kusurların sızma ya da sistemi batırma ihtimalini azar azar düşürdü
Yüksek doğrulama seviyesi ve kalan risk
- Mythos'un ilk taramada yalnızca düşük önem dereceli tek bir sorun bulması sonrasında, curl'ün hayal edilebilecek ölçüde en çok incelenen, fuzzing uygulanan ve doğrulanan kodlardan biri olduğu değerlendirmesi tekrarlandı
- Bu durum tesadüf ya da şans değil; onlarca yıllık inatçı çalışmanın, ayrıntılara gösterilen özenin ve bitmeyen yinelemeli iyileştirmenin sonucu
- İnceleme ve doğrulamanın fazla olması, hata ya da güvenlik sorunu olmadığı anlamına gelmiyor; curl, birçok protokol, işletim sistemi ve CPU mimarisi üzerinde yüksek derecede paralel ağ işlemleri yapan yüz binlerce satır C kodundan oluşuyor
- Sorunlar bulundukça düzeltiliyor ve yamalar yayımlanıyor; süreç sürekli tekrarlanıyor
- Yaklaşık 30 milyarlık küresel kurulum tabanı, telefonlarda, tabletlerde, otomobillerde, TV'lerde, yazıcılarda, oyun konsollarında ve mutfak cihazlarında curl'ün birden çok kez yer alabileceği anlamına geliyor
- Geçmişte büyük hatalar nedeniyle dünyayı bir süreliğine alevlendiren projeler ilgi gördü; bazıları finansman ve insan kaynağı kazanarak birden fazla tam zamanlı mühendisi istihdam edebildi
Eşi benzeri görülmemiş güvenlik raporu hacmi
- Şu anda güvenlik raporu akış hızı 2024'e göre 4-5 kat, 2025'in ise iki katı; ortalama olarak günde birden fazla rapor geliyor
- Rapor kalitesi öncekine göre çok daha yüksek ve çoğu oldukça ayrıntılı ve uzun yazılıyor
- Raporlar gelmeye devam ettiği için mümkün olduğunca gelir gelmez ele alınmaları gerekiyor; geliş hızına yakın bir tempoda işlenmezlerse potansiyel güvenlik sorunları listesi sürekli birikiyor
- Kontrol edilemeyen bir potansiyel güvenlik sorunu listesi zihinsel yük yaratıyor
- Şu anda zamanın çoğu, HackerOne üzerinden bildirilen güvenlik sorunları listesini işlemeye gidiyor
- Başlıca işler; iddiaların doğrulanması, önem derecesinin değerlendirilmesi, yama yazılması, hatanın ne zaman eklendiğinin belirlenmesi, zafiyetin anlaşılması, ayrıntılı güvenlik danışma metinlerinin hazırlanması ve güvenlik araştırmacılarıyla curl güvenlik ekibiyle iletişim kurulması
Sağlık ve ekip üzerindeki baskı
- İlk kez eşi, çalışma süresi ve dengesiz iş-yaşam durumu konusunda endişe duydu; çevresindekiler de bu büyük akışın nasıl yönetildiğini ve tükenmişlik olasılığını merak ediyor
- Ekip üyeleriyle ilgili kaygı da arttı ve yakında nefes alacak zaman yaratmak için çalışma saatlerini azaltmak gerekebilir
- Mevcut durum, curl projesi ve güvenlik ekibi üyelerinin daha önce hiç yaşamadığı türden bir baskı
- Güvenlik sorunlarının ele alınması, projedeki diğer her şeyin önüne geçen yüksek öncelikli bir iş; sorumluluk duygusu, vicdan ve yapılan işten duyulan gurur nedeniyle göz ardı edilmiyor
- curl dünya çapındaki cihazlara dağıtılmış bir yazılım olduğu için, içindeki güvenlik sorunlarını düzeltme yükümlülüğü güçlü biçimde hissediliyor
- Planlanan sürüme kadar sürüm döngüsünün yaklaşık yarısı kalmışken şimdiden doğrulanmış 12 zafiyet var; bu da bekleyen 12 CVE duyurusu anlamına geliyor
- Bu, proje için yeni bir rekor ve 2026 yılı yarıya bile gelmeden kamuya açık CVE sayısının 30'a ulaşacağı anlamına geliyor
- Bu gidişle 2026 boyunca curl için yayımlanacak toplam CVE sayısının en az bunun iki katı olması bekleniyor
Gerekli destek ve yapısal sınırlar
- Kısa vadede, hâlihazırda ele alınması gereken iş o kadar fazla ki anında yardım almak için artık geç kalınmış durumda
- curl veya libcurl'ü ticari yazılım ve hizmetlerde kullanıp bunlara bağımlı olan şirketler daha fazla finansman sağlarsa, iş yükünü paylaşmak için daha fazla geliştiriciye ödeme yapılabilir
- Destek sözleşmeleri üzerinden işverenin masrafı karşılaması da mümkün bir destek yolu
- Zaten böyle destek veren müşteriler var; bu sayede bazı üyeler curl üzerinde tam zamanlı çalışabiliyor
- Ancak bu alanda anlamlı bir değişimin yakında gerçekleşeceğine dair bir beklenti yok; benzeri görülmemiş bu durum ve daha zor safhalarda bile sonunda fırtınayı yine kendi başlarına atlatmaları muhtemel
- curl projesi bir şirkete ait değil ve herhangi bir çatı kuruluşa da bağlı değil
- Bu yapı bazen kaynak kıtlığı yaratıyor, ama aynı zamanda mümkün olan en yüksek özgürlük ve esnekliği sağlıyor
- Projenin hareket ölçütü, dünya ve curl kullanıcıları için curl'ü mümkün olduğunca iyi hale getirmeye odaklı
Olumlu taraflar ve mevcut durum
- Hataları ve sorunları düzeltmek başlı başına iyi bir şey; bildirilen her sorun, yakında düzeltilmiş bir sorun anlamına geliyor
- Raporlar arttıkça curl daha iyi bir ürüne dönüşüyor
- Son birkaç yılda bulunan curl zafiyetlerinin tamamı LOW veya MEDIUM önem derecesiyle değerlendirildi ve çok ciddi zafiyetler neredeyse hiç bulunmadı
- Bu, gelecekte yeniden HIGH çıkmayacağı anlamına gelmiyor, ancak en azından nadir olduğu söylenebilir
- En son yüksek önem dereceli curl CVE'si, Ekim 2023'te yayımlanan CVE-2023-38545 idi
- curl ekibi şu anda baskı altında ve zaman zaman yanıtlar yavaş olabilir
1 yorum
Lobste.rs görüşleri
Daniel ve diğerlerinin bu zor durumu sağlıkları veya aileleri üzerinde büyük bir olumsuz etki olmadan atlatmasını umuyorum.
Yine de bunun nasıl gelişeceğini görmek oldukça ilginç olacak gibi. Yeni otomatik analiz yöntemlerinin çeşitli FOSS projelerinde bir anda çok sayıda zafiyet bulması ilk kez olmuyor; şu anki durum, 2010’larda graybox fuzzing ortaya çıktığında yaşanana benziyor. Olası üç senaryo görüyorum: A) geliştiriciler LLM’leri güvenlik araştırması akışına dahil eder, böylece LLM’lerin bulduğu yeni zafiyet sayısı ciddi biçimde azalır ama LLM’lerin ulaşamadığı zafiyetleri bulan fuzzer senaryosu sürer. B) A’ya benzer ama LLM’ler bir kez taradıktan sonra zafiyet bulmanın fiilen durduğu, yani “LLM güvenlik araştırmasını çözdü” senaryosu. C) curl gibi büyük projelerde zafiyetler yüksek oranda bulunmaya devam eder ve yüz binlerce satırlık projelerdeki hata sayısının fiilen sonsuz olduğunu gösteren “Tony Hoare’un intikamı” senaryosu
Belirli bir kod tabanının anlık görüntüsünde yalnızca sonlu sayıda güvenlik hatası olabilir. Güvenlik hatalarını arama alanı tükendiğinde bu sel dinecek, sonrasında ise kod birleştirmeleri, yeni test harness’leri veya model iyileştirmelerinden gelen hatalar azar azar kalacaktır.
curl projesindeki C senaryosuna gelince, mevcut güvenlik testleri ve geleneksel hata bulma teknikleri için çıta zaten yüksek olduğundan bulunan hataların düşük önem derecesinde olduğunu düşünüyorum. Bu da hata bulmaya sürekli yatırım yapmanın uzun vadede karşılığını vermeye devam ettiğini gösteriyor. Bugün ya da gelecekte hangi keşif yöntemi kullanılırsa kullanılsın durum bu.
Marcus Hutchins’in sözünü ödünç alırsak, “darboğaz hiçbir zaman hata bulma olmadı; darboğaz, kurumların güvenlik araştırmacılarına yatırım yapmamayı seçmesi oldu” görüşüne daha yakınım. LLM’ler sadece bu yatırımı daha ucuz hale getirdi; kurumlar aslında zaten daha fazla yatırım yapıp daha fazla hata bulabilirdi. Sonuçta bu bir politika kararı
LLM teknolojisi geliştiren şirketler yalnızca doğal dünyayı değil, yazılım dünyasını da yıkıma uğratıyor. Donanım fiyatları fırlarken kişisel bilişimin kendisi bile tehdit altında; bir şeyler üretmek istedikleri için üreten iyi niyetli açık kaynak geliştiricileri de öyle.
Mevcut topluluk tarafından yönetilen açık kaynak projelerini küçümseyip bozmak için sonsuz para varmış gibi görünüyor ama sonrasındaki enkazı toplamak için harcanacak hiç para yok; bu da ilginç.
Bence bu, Zig’in haklı olduğunu kanıtlıyor. LLM’in bulduğu CVE’lerle hiç uğraşmamak, isteyenin ilgilenmesine bırakmak gerekir
Bunun tam olarak ana mesele olmadığını biliyorum ama LLM CVE’lerinin sorunu, aynı aracı kullanan başka herhangi birinin de muhtemelen aynı şeyi bulabilecek olması. Gerçekten ciddi bir sorun bulunursa, daha fazla kişinin bunu zararlı bir şey üretmek için kullanabileceği anlamına gelir.
Elbette bu, curl’deki çok sayıdaki düşük önem dereceli veya güvenlikle ilgili olmayan sorunlar için birebir aynı şekilde geçerli demek değil. Yine de hangi sorunların gerçekten yüksek öncelikli olduğuna karar vermek gerekir; o zaman da yine başa dönmüş oluruz
Zig hâlâ aktif olarak geliştiriliyor ve örneğin artımlı derleme ya da asenkron I/O gibi özellikler somutlaştıkça yeni hatalar ekleme olasılığı yüksek; aynı zamanda önceki uygulamaların eksikliğinden kaynaklanan bazı hatalar da ortadan kalkıyor.
Geliştirmenin bu aşamasında biri Zig üzerinde Mythos benzeri bir şeyi çalıştırıp “tüm hataları bul ve hiç hata yapma” yaklaşımını benimsese muhtemelen çok büyük miktarda rapor üretir, ama bunların tamamı bizim için fiilen işe yaramaz olabilir. Şu anda hata raporlarının asıl değeri, belirli bir kullanım senaryosunda tıkanmış bir kullanıcının varlığına işaret etmesi; öncelik vermeye karar verirsek o kullanıcının önünü açabiliyoruz.
Bu durum elbette sonsuza kadar sürmeyecek. Önemli derleyici özelliklerinin çoğu yerine oturuyor ve istikrar sağlandığında tüm hataları bulup düzeltmek en yüksek öncelik olacak. O noktada, hatanın nasıl bulunduğundan bağımsız olarak biliniyor olması önemli hale gelecek; ama bu mesele o zaman ele alınacak.
O zamana kadar politika basitçe LLM yasağı
LLM katkılarını yasaklamayı anlıyorum ama katılmıyorum. Güvenlik açıkları, nasıl keşfedildiklerinden bağımsız olarak güvenlik açığıdır.
Daniel’in yaptığının en iyi yaklaşım olduğunu düşünüyorum: düzeltilebilecek hataları düzeltmek, kullanıcıları daha güvenli hale getirmek ve bunun maliyetinin yüksek olduğunu açıkça söyleyerek destek istemek. Bu yazıyı okuma ihtimali düşük olsa da, fiziksel ve zihinsel sağlığını korumak için iş yükünü sınırlamasını da destekler ve tavsiye ederim. Dünyanın büyük kısmı bunu anlayacaktır; muhtemelen yalnızca küçük bir kesim şikâyet eder
Burada iki temel nokta eksik gibi görünüyor. 1) LLM şirketleri ya da Project Zero bu güvenlik hatalarını koda koymadı. 2) Güvenlik hatalarını düzeltmek, LLM şirketleri ya da Project Zero için değil, kullanıcılar içindir. Güvenlik hataları istismar edilirse zararı kullanıcılar görür.
Özellikle LLM’in bulduğu hatalarda, aynı LLM’i kullanan başka kişilerin farklı açık kaynak projelerinde mükerrer raporlar gönderdiğini gösteren işaretler zaten var. Dolayısıyla savunmacılar geri çekilirse saldırganların da LLM’in bulduğu hatalardan haberdar olacağını varsaymak gerekir
“Geçmişte dünyayı bir süreliğine ateşe veren korkunç bir hatayı yayımlayan projeleri kıskanıyorum. Onlar ilgi gördü ve bazıları fon ve mali güç elde ederek personel tuttu, birden fazla tam zamanlı mühendis işe aldı. Bazen bizim de böyle bir şeyimiz olsaydı daha iyi olurdu diye düşünüyorum.”
Bu birçok iş yerinde de yaşanır. Başarısız olan ekiplere daha fazla insan verilirken, iyi giden ekipler sırf korkunç bir şey yaşanmadığı için daha az kişiyle daha fazla iş yapmak zorunda kalır
curl gibi bir proje için uygun olur mu bilmiyorum ama belirli bir süre özellik dondurma uygulayıp yalnızca gelen hata/CVE raporlarına odaklanmak yardımcı olur mu?
Sabit bir özellik kümesi varsa, potansiyel hata/CVE sayısı sonlu olmalı ve bunlar düzeltildikçe sayı 0’a yaklaşmalı gibi geliyor.
Her halükârda onlara bol şans diliyorum. Bu kadar önemli bir yazılımı sürdürmenin dönemi kolay olmayacak
Geliştirici memnuniyeti üzerinde sırasıyla artış, korunma ve azalma etkisi yaratır.
Özellik dondurma, bir sürümü iyi şekilde tamamlamayı sağlayan harika bir araçtır; ancak kendi yönünü belirleyerek çalışan geliştiricilerin üzerindeki baskıyı azaltmak için iyi bir araç değildir