Haberleri sık takip eden biri değilim, yaşanan başka bir vukuattan haberim yok. Bu haberi de verdiğim kaynaktan almamıştım, "başka bir örnek olsaydı onu da paylaşırlardı" diye düşünmenize gerek yok yani.
Senin takip edip etmemen önemli değil zaten, senin için herhangi bir vurgu da yapmadım. Paylaştığın kaynaktan bahsediyorum, eğer iddia ettiği olgu için örtüşen bir örnek olsaydı bunu paylaşırdı diyorum, bunun yerine iddia ile örtüşmeyen bir durumu paylaşıyor. Sadece bir durumdan hareketle genel bir sonuç çıkartıyorsun ve başka bir örneği de yok bunun, yani özel bir durumda genel bir sonuç çıkartılamaz. Yukarıda güvenlik raporu bulunmayan bir güvenlik açığının, Debian geliştiricileri tarafından nasıl backport edildiğinin bir örneğini hali hazırda paylaşmıştım.
Sonuç olarak, işlerin çeşitli nedenlerden dolayı aksayabileceği bir gerçek. İhtimali az da olsa görüldüğü gibi gerçekleşebiliyor. Rolling-release dağıtımlarda güvenlik açıkları backport edilmediği için böyle bir ihtimal hiç bulunmuyor.
İhtimallerden bahsediyorsun sadece, yaşanmamış ve örneği bulunmayan bir şey gerçek olamaz. Chromium'daki gecikme sadece tarayıcıdaki kaynak kodun backport edilmesi süreci ile ilgili değil, bunun bağımlı olduğu bazı paketlerinde backport edilmesi süreci ile alakalı. Yani sadece bir tane örnekten bunun sürekli olabileceği sonucunu çıkartmanın, gerçekle hiç bir bağlantısı yok.
Bununla birlikte; yetersiz geliştirici sayısından dolayı yuvarlanan bir dağıtımda güvenlik düzeltmesi içeren upstream bir paketin depoya girmesi gecikebilir. Bunun gerçek olma olasılığı, senin bahsettiğinden çok daha fazla bir olasılık. Debian'da bir çok paketin bakımcı sayısı onlara ulaşıyor, hatta bazı paket gruplarının 20'den fazla bakımcısı mevcut. Bu bahsettiğin yuvarlanan dağıtımların tüm geliştirici ekip sayısından fazla. Mesela VLC paketine bakan çoklu ortam grubunun proje üyesi sayısı 50'den fazla.
Members · Debian Multimedia Team / vlc Upsteam'de kaydı olmayan bir güvenlik güncellemesinin gözden kaçması olasılığının ne kadar az olduğunu anlatmaya çalışıyorum.
Biri, resmi olmayan kullanıcı reposu, diğeri dünya çapındaki bütün Debian Stable kullanıcılarının sisteminde bulunan paketlerin hemen hemen hepsinin yüklendiği repo. İlkinde meydana gelen bir sorun kendi sorumluluğunda olduğu bilincine sahip birkaç kullanıcıyı etkiler. İkincisinde meydana gelen bir sorun milyonlarca insanın sisteminde güvenlik zafiyetine sebep olur. Karşılaştırmak bile gereksiz.
Resmi olup olmaması ne farkeder, Arch kullanıcılarının hemen hepsi bu depoyu kullanıyor ve hala herhangi bir kontrol garantisi yok. Debian'da belki onlarca yıl sonra bir örneğinin ortaya çıkmayacağı bir gecikme ile, kontrolsüz AUR'da hemen her an karşılaşma olasılığınızın bulunduğu durumu karşılaştırma yapmak bence de gereksiz. Hem de Acrobat Reader gibi çok fazla kullanıcı tarafından rağbet edilecek bir pakete trojan eklenebiliyor ve bu tesadüfen farkediliyor. Ayrıca AUR'dan yüklediğiniz herhangi bir pakette oluşabilecek olası bir güvenlik güncellemesinin kapatılıp katımayacağı dahi bir muamma. O kadar çok bakımı yapılmayan ya da bakımcısının aylarca ilgilenmediği paket var ki. Hatta aktif olup sahipsiz düşmüş sayısız AUR paketi var, yani paketi yükleyebiliyorsun ama paketin olası bir güncellemesini yapacak hiç bir kimse yok. Bence güvenlik analizcilerinin asıl bunun üstüne kafa yorması çok daha makul.
Sadece varsayımda bulunuyorsunuz. İstediğim önemli her paketi Arch repolarında bulabildim, bulamadıklarımı geliştiricinin kendi sitesinden indirip derledim. AUR da buna bir alternatif zaten, adı üstünde User Repository. Geliştirici ekibi bu reponun sorumluluğu nasıl ve neden üzerine alsın?
Neden varsayım olsun, hemen her Arch kullanıcısı AUR kullanıyor. Zaten sorun burada, kimsenin sorumlu olmadığı, şu an dahi bir zararlının dahil edilip edilmediğinin muamma olduğu ve ileride ne olabileceğinin kestirilmesi zor bir ortamdan bahsediyoruz.
Bununla birlikte senin işaret durumun elbet teoride bir karşılığı var, ama önemli olan pratikte bir karşılığının olup olmaması.
