15 puan yazan GN⁺ 2025-11-12 | 15 yorum | WhatsApp'ta paylaş
  • FFmpeg, dünya çapında medya işlemenin merkezindeki açık kaynak bir çerçeve ve VLC·Chrome·YouTube gibi büyük hizmetlerde kullanılan vazgeçilmez bir bileşen
  • Kısa süre önce Google'ın yapay zeka tabanlı güvenlik tarayıcısı, 1995 tarihli bir oyun codec'iyle ilgili önemsiz bir hatayı buldu; bunun ardından büyük şirketlerin gönüllü geliştiricilere aşırı yük bindirdiği yönündeki tartışma büyüdü
  • FFmpeg tarafı, “proje neredeyse tamamen gönüllüler tarafından sürdürülüyor” diyerek, Google'ın yalnızca zafiyet bildirmekle yetinmeyip yama sağlaması veya mali destek vermesi gerektiğini savundu
  • Google ise Project Zero'nun kamuya açıklama politikası ve Patch Rewards programını dayanak göstererek şeffaf güvenlik katkısını vurguladı; ancak FFmpeg topluluğu ödül sınırları ile pratik destek eksikliğine dikkat çekti
  • Bu tartışma, yapay zekanın ürettiği çok sayıdaki CVE ile açık kaynak bakımının sürdürülebilirliği sorununu görünür kılarak büyük teknoloji şirketlerinin sorumluluğu tartışmasına uzandı

FFmpeg ile Google arasındaki gerilimin özeti

  • FFmpeg, ses ve video dosyaları için transcoding, oynatma ve streaming desteği sunan açık kaynak bir multimedya çerçevesi
    • libavcodec, libavformat gibi temel kütüphaneler VLC, Kodi, Plex, Chrome, Firefox, YouTube ve benzerlerinde kullanılıyor
    • Ancak diğer büyük açık kaynak projelerde olduğu gibi ciddi finansman yetersizliği yaşıyor
  • X'te FFmpeg, Google, Chainguard ve güvenlik araştırmacıları arasında güvenlik açıklarının açıklanma yöntemi ve sorumluluğun kimde olduğu üzerine tartışma çıktı
    • Tartışmanın merkezinde, yapay zekanın ürettiği çok sayıdaki zafiyet raporunun çoğu zaman gerçek değerinin düşük olması yer aldı

Tartışmanın çıkış noktası: Google yapay zekasının bulduğu önemsiz hata

  • Google'ın yapay zeka ajanı, FFmpeg içinde LucasArts Smush codec decoding ile ilgili bir hata buldu
    • Bu sorun, 1995 yapımı Rebel Assault 2 oyununun yalnızca ilk 10 ila 20 karesini etkileyen orta seviye bir zafiyet
    • FFmpeg geliştiricileri bunu yamaladı, ancak verimsiz bildirimleri eleştirerek bunu “CVE slop” diye nitelendirdi
  • FFmpeg, “FFmpeg aims to play every video file ever made” diyerek kusursuz uyumluluğu hedeflediğini belirtti; ancak kodun büyük bölümünün assembly diliyle yazıldığını ve bu yüzden bakımının zor olduğunu da ekledi

Açık kaynak bakımcılarının üzerindeki yük

  • FFmpeg topluluğu, FFmpeg kullanan Google gibi büyük şirketlerin zafiyet düzeltme yükünü ücretsiz gönüllülere bıraktığını eleştirdi
    • Buna göre Google, zafiyet bildirirken yama sağlamayı veya mali destek sunmayı da beraberinde getirmeli
  • Benzer bir örnek olarak libxml2 bakımcısı Nick Wellnhofer, tekrarlayan üçüncü taraf güvenlik bildirimleri nedeniyle bakımı bırakacağını açıkladı
    • Kendisinin ifadesiyle, karşılıksız çalışan bir gönüllünün her hafta saatlerini güvenlik sorunlarına ayırması sürdürülebilir değil

Google Project Zero'nun açıklama politikası etrafındaki tartışma

  • Temmuz 2025'te Google Project Zero (GPZ), “Reporting Transparency” politikasını devreye aldı
    • Bir zafiyet bulunduktan sonra 1 hafta içinde kamuya açıklanıyor, ardından 90 günlük düzeltme süresi otomatik olarak başlıyor
    • Yama hazır olmasa bile açıklamanın yapılması, gönüllü odaklı projeler üzerinde aşırı baskı oluşturduğu gerekçesiyle eleştiriliyor
  • FFmpeg, “Yapay zekanın hobi amaçlı yazılmış kodlardaki güvenlik sorunlarını bulup gönüllülerden bunları düzeltmesini istemesi adil mi?” diye sordu
  • Google'ın Patch Rewards Program'ı mevcut olsa da FFmpeg, “ayda 3 bildirim sınırı gibi kısıtlar yüzünden bunun pratikte yardımcı olmadığını” söyledi

Zıt bakış açıları ve açık kaynağın sürdürülebilirliği

  • Chainguard'dan Dan Lorenc, güvenlik açıklarını açıklamanın da dijital kamusal varlıklara bir katkı olduğunu söyleyerek Google'ın rolünü savundu
    • Ona göre Google, açık kaynak desteğinde en aktif şirketlerden biri ve bu tür tartışmalar sponsorları daha da uzaklaştırabilir
  • Buna karşın FFmpeg tarafı, yapay zekanın ürettiği çok sayıdaki CVE'ye yanıt verecek insan gücü ve bütçenin olmadığını vurguladı
    • Güvenlik uzmanları ise FFmpeg'in internet altyapısının temel bileşenlerinden biri olduğu için zafiyet açıklamalarının gerekli olduğunu kabul ediyor
  • Yazının sonunda, “büyük şirketlerin somut desteği olmadan çekirdek açık kaynak projelerini sürdürmek mümkün değil” denilerek, libxml2 örneği üzerinden sürdürülebilir sponsorluk yapılarının gerekliliği vurgulanıyor

15 yorum

 
carnoxen 2025-11-14

Umarım bu durum WordPress vakfı ile WP Engine şirketi arasındaki ilişki gibi tamamen kopma noktasına gelmez?

 
nullptr 2025-11-14

Görünüşe göre https://daniel.haxx.se/blog/2024/…
yazısının devamı niteliğinde.
Yukarıdaki yazıda bireylerin bug bounty peşinde koşarak tamamen yanlış raporlar göndermesi söz konusuyken, FFmpeg vakasında büyük bir şirketin gönderdiği raporlar geçerli ama önemsiz nitelikte.

 
kimjoin2 2025-11-13

Google işaret etti diye mutlaka karşılık vermek zorunda mılar?

 
furyheimdall 2025-11-13

Açığın kendisi zaten ifşa edilmiş durumda olduğundan, müdahale etmekten başka çareleri yok gibi görünüyor.

 
kimjoin2 2025-11-14

Aha... Böyle bir bakış açısı olduğunu fark etmemiştim. Bildirdiğiniz için teşekkürler!
Açığın ifşa edilmesiyle bunun üzerinden saldırı gelebilecek bir durum söz konusuymuş, vay canına.

 
roxie 2025-11-13

Aslında isterseler, açığın kamuya açıklanıp açıklanmaması fark etmez, "İhtiyacın varsa kendin düzelt" de diyebilirlerdi; ama sanırım ana bakımcılar bunu yapacak karakterde olmadıkları için proje bugüne kadar bu kadar gelişebildi.

 
kimjoin2 2025-11-14

Anladım.... Sanırım söylediğiniz doğru.
Sanırım olaya fazla kendi bakış açımdan yaklaşmışım.
Söylediğiniz için teşekkür ederim!

 
GN⁺ 2025-11-12
Hacker News görüşleri
  • Yazıdaki etkileyici bir nokta şuydu. Amazon içinde FFmpeg ile ilgili bir kararı engellemek için Mark Atwood'un yöneticilerine “Onlar bir vendor değil, NDA da yok ve onlar üzerinde etkimiz yok” diye açıklama yapmak zorunda kaldığı anlatılıyordu.
    “Sadece sorun getirmeyin, çözüm de getirin” sözüne katılıyorum, ama Google'ın hata bulmaya para ayıracak bütçesi varsa, düzeltmeye de para harcayabileceğini düşünüyorum

    • Açık kaynak yazılımlardaki düzeltmelerin upstream edilmesini her zaman destekledim.
      Böylece kapalı yamalara bağımlı kalınmaz, en başta yardım alınan projeye karşılık verilmiş olur ve etik olarak da doğru olan budur.
      Ama pratikte şirket içindeki compliance veya prosedür engelleri yüzünden upstream etmek zor olabiliyordu
    • “FFmpeg tek bir e-postayla AWS'nin üç ürün hattını durdurabilir” sözü bana pek anlamlı gelmedi. Bunun somut olarak nasıl mümkün olduğunu merak ediyorum
    • Asıl sorun yazıda geçen “CVE slop”. Yama kalitesi gerçekten o düzeydeyse, düzeltmek de epey emek gerektirecek gibi görünüyor
    • Kilit nokta, Google'ın insan tutup hata araması değil, AI'ı gelişigüzel çalıştırıyor olması
  • S&P500 şirketlerinde çalışan birinin hata bildirebilmesi için belirli bir tutarda bağış yapması gereken ve belli bir miktarın altında ödeme yapılırsa belirli bir süre içinde yanıt beklenemeyeceğini söyleyen hicivsel bir lisans hayal ettim.
    Şirketler işlerine gelmediğinde yazılımı kapalı kaynak yapmaya ya da AGPL'ye çevirmeye çekinmiyor; artık bedeli doğrudan ödemelerinin zamanı geldi

  • Bir açık kaynak bakımcısı olarak, büyük şirketlerin güvenlik sorunlarını ifşa ederek sanki ücretsiz emek dayatıyormuş gibi bir izlenim verdiği duygusuna katılıyorum.
    Ama gerçekte, kim bildirmiş olursa olsun güvenlik meselesi sonunda benim çözmem gereken bir sorun.
    Bir projenin güvenliği önceliklendirmemesi de sorun değil, ama o zaman buna eşlik eden itibar riskini de göze alması gerekir

    • Eğer Google sorunları buluyor ama kimse düzeltmiyorsa, bu fiilen kötü niyetli aktörlere bedava zafiyet araştırması sunmak anlamına gelir. FFmpeg gibi temel projelerin yerine başkasını koymak kolay değil
    • Benim çıkardığım sonuç, Google'ın belli bir süre sonra koşulsuz olarak ifşa etme politikasına geçtiği.
      Ticari şirketlerden hızlı düzeltme talep etmek makul olabilir ama aynı şeyi gönüllü tabanlı OSS için istemek gerçekçi değil
    • Yazıya göre Google'ın AI'ı, FFmpeg'te LucasArts Smush codec ile ilgili bir hata bulmuş.
      Bunun 1995 tarihli bir oyunun yalnızca ilk 10-20 karesinde ortaya çıktığı söyleniyor; buna “orta ciddiyet” demek bana abartılı geliyor.
      Bakımcıların zamanını boşa harcatan bir örnek gibi duruyor
    • Esas mesele “bunu kimin bildirdiği” değil, “sorunun gerçek önemi”.
      Ciddi bir sorunsa kimin bildirdiği fark etmez, bilinmesi iyidir; önemsiz ya da hatalı bir bildirimse görmezden gelinebilir.
      Sonuçta hangi hatanın düzeltileceğine proje kendisi karar vermeli
    • Elbette Google'ın zafiyetleri açıklarken yamayı da birlikte göndermesi en ideal senaryo olurdu
  • FFmpeg ekibinin tavrını destekliyorum. Pek çok şirket FOSS'u sadece pazarlama amaçlı imaj aklama için kullanıyor ve gerçekte katkı vermiyor.
    Eskiden olsa sadece korsan kullanacak kişiler, şimdi lisans sayesinde vicdan azabı duymadan kullanıyor denebilir

    • Ama Google, FFmpeg için sürekli fuzzing ve mühendislik kaynakları ayırıyor.
      İçeride kullanmadığı codec'leri bile test etmesi tamamen kamu yararına bir iş.
      Elbette Google'ın FFmpeg'e daha fazla finansman sağlama imkânı var, ama bu bakımcıya doğrudan para verilmesi fikrine bu olay özelinde katılmıyorum
    • Bu yüzden MIT lisansının sınırlarına dikkat çeken çok kişi var.
      Serbestçe kullanılabiliyor, ama suistimale de açık.
      GPL 3'ün fazla sert olduğu söylense de, en azından sömürüyü engelleme niyeti vardı
  • Bir yanda çağa damga vuran yazılımları ücretsiz üreten insanlar, diğer yanda bundan yararlanıp tüm değeri çekip alan şirketler var.
    İlki sevgiyle, ikincisi çıkar ilişkisiyle hareket ediyor

    • Google ne yaparsa yapsın, güvenlik araştırmasının kendisi faydalıdır. Yalnız FOSS için biraz daha esnek bir politika gerekiyor
    • Google'ı geri kalan her şeyle kıyaslayınca, iyiyle kötüyü ayırmanın bu kadar kolay olduğu durum azdır
    • “Çağa damga vuran yazılım” deniyor ama dürüst olmak gerekirse FFmpeg'i bilen kişi sayısı çok fazla değil
  • Büyük şirketlerde kamuya açık zafiyet ifşası gerekli olabilir, ama kaynağı kıt OSS için risk daha büyük olabilir

    • Bu yüzden FOSS için “yama hazır olduktan sonra açıklama” politikasının daha uygun olduğunu düşünüyorum.
      Google hızlı bir düzeltme istiyorsa yamayı da birlikte göndermeli, böylece herkes kazanır
    • Ama zafiyetleri saklamak da riskli.
      Özellikle LLM'lerin bulabileceği düzeydeki zafiyetler ise, bir gün istismar edilmeleri muhtemel.
      Açıklama sayesinde kullanıcılar kendilerini savunabilir ve FFmpeg'in bunu düzeltmeyi seçmesi de gönüllü bir karardır.
      Güvenlik araştırmasının kendisi açık kaynağa yapılmış yüksek maliyetli bir katkı biçimidir.
      Araştırmacılara “yeterince katkı vermiyorsunuz” demek, aslında gönüllülerden ücretsiz emek istemek olur
    • Açıklama yapılmazsa kullanıcılar “zafiyet yok” sanrısına kapılır.
      FOSS'un şeffaflığı, güvenlik farkındalığı açısından aslında faydalı
    • Bilgi güvenliği sektöründe “güvensiz yazılım var olmamalıdır” şeklinde aşırı bir inanç yaygın.
      Gerçek dünyanın gri alanlarını kabul etmiyor
  • “Bir e-postayla üç ürün hattı durabiliyorsa”, yıllık 10-20 bin dolar civarında bir destek sigorta primi olarak bile gayet mantıklı görünüyor

    • Ama Jeff Bezos'un yatına bakınca, onun çek yazma biçimi hakkında fikir edinmek mümkün.
      Google ve Amazon ayrı ayrı sadece 50 bin dolar verse, FFmpeg geliştiricileri istikrarlı biçimde çalışabilir;
      özellikle YouTube'u işleten Google için 100-200 bin dolar ödemek zor olmamalı
  • Google güvenlik yöneticisinin FFmpeg'e yapılan katkıları sıraladığı Twitter dizisini paylaşıyorum

    • Google'ın tarafını doğrudan görmek iyi oldu. Yine de bazı eski ve mevcut çalışanların profesyonellikten uzak tepkileri hayal kırıklığı yarattı
    • Twitter'a giriş yapılmadan yalnızca ilk gönderi görünüyor ve o bile kurumsal savunma cümleleri gibi geliyor.
      Trilyon dolarlık bir şirketin personel ya da para sıkıntısı yaşadığını söylemesi ikna edici değil
  • Project Zero'nun amacını merak ediyorum.
    Sadece zafiyet bulmanın ötesinde bir nedeni olup olmadığını bilmek isterim

    • Özünde mesele PR. “Sorumlu açıklama”nın geliştiricinin hataları süresiz saklaması anlamına gelmediği mesajını vermek istiyorlar
    • Bu proje, Snowden olayı sonrasında NSA gözetimine öfkelenen Google tarafından kuruldu
    • Pratikte Google'ın kullandığı çeşitli açık kaynakların, kernel'lerin ve firmware'lerin güvenliğini artırmaya yardımcı oluyor.
      Aynı zamanda güvenlik yeteneği çekme ve itibar yönetimi açısından da işlerine yarıyor.
      Ama buna ayıracak imkân varsa, yama yazımına da yatırım yapılması gerektiğini düşünüyorum
    • Sonuçta pazarlama amacı da büyük. Araştırmacılar aidiyet hissediyor, Google da “güvenliğe yatırım yapan şirket” imajı kazanıyor
  • Söz konusu zafiyet bir Use After Free idi ve bunu Google'ın AI'ı buldu.
    Ama düzeltmesi 3 saniye bile sürmeyecek bir şeymiş gibi anlatılıyor.
    Parası çok olan bir şirketin gönüllü bir projeye spam niteliğinde hata raporları yağdırması rahatsız edici

    • Üstelik söz konusu zafiyet varsayılan olarak devre dışı olan bir codec içindeydi.
      CVE sayılacak düzeyde bile değil; sıradan bir hata raporu olması yeterliydi
    • Tabii mesele “free'yi geciktirelim” kadar basit değil.
      Bellek sızıntısını önlemek için daha karmaşık bir düzeltme gerekiyor.
      Muhtemelen bu codec için doğru yön varsayılan olarak devre dışı kalması
    • Bu tür davranışlar sadece rahatsız edici değil, açık kaynak ruhuna da aykırı
 
nobae 2025-11-13

Yemek vermişsin, şimdi de bohçayı çıkar diyorlar.
Hata raporları da sonuçta kesinlikle önemli bir katkı sayılır ama...

 
bungker 2025-11-13

Birinin gönüllü olarak mahalleyi temizlediğini, ama mahallede en çok araziye sahip nüfuzlu kişinin gelip o temizlik yapan kişiye "şurada köşede bir sigara izmariti var" demesi gibi bir his olsa gerek.

 
reagea0 2025-11-14

Ben de bu benzetmenin doğru olduğunu düşünüyorum.

 
chcv0313 2025-11-13

Yerinde bir benzetme.

 
ifmkl 2025-11-13

Buna gerçekten söylenecek bir şey var mı? Okuyunca, yalnızca çok eski belirli bir oyunun ilk 10~20 karesinde geçerli olan, orta seviyede bir güvenlik açığı olduğu görülüyor. Bunun gerçekten FFmpeg tarafı için önemli bir katkı olduğunu düşünüyor musunuz? Bence açık kaynak topluluğuna yapılacak en önemli katkı, istikrarlı geliştirmeyi mümkün kılacak şekilde sponsor olmak; özellikle de ortaya çıkan ürünü yoğun biçimde kullanan bir şirketseniz, öncelik bu olmalı gibi görünüyor.

 
hohemian 2025-11-13

İşte bu tür insanlar yüzünden XZ'ye bir arka kapı yerleştirildi.

 
secret3056 2025-11-13

Hata raporunun kendisi gerçekten S sınıfı, ama Kennedy döneminde kullanılıyor olabilecek bir video formatındaki ciddi bir açığı süre içinde gideremediler diye bunu her yerde dillendirip duruyorlar.

Yenebilecek bir şey vermek yerine, mutlaka yenmesi gereken bir şeyi verip neden süre içinde yiyemediniz diye çıkışıyorlar.

ffmpeg tarafında insan kaynağı sınırlıyken, Google'ın yapay zeka ile artık neredeyse hiç kullanılmayan formatlara dair onlarca hata raporu yağdırıp hepsini süre içinde düzeltmeleri için baskı yapması sizce doğru mu?