"Ücretli müşterilerimizin X'e ihtiyacı var, bunu ne zaman düzelteceksiniz?"

 (twitter.com/maximilianhils)
2 puan yazan GN⁺ 2023-07-16 | 1 yorum | WhatsApp'ta paylaş
  • Düzenlemeye tabi sektörlerdeki (bankalar, federal kurumlar vb.) müşterilere sahip bir kurumsal kullanıcı, açık kaynak araç mitmproxy için bir sonraki sürüm takvimini herkese açık bir issue üzerinden talep etti ve bilinen High·Critical güvenlik açıkları nedeniyle kendi müşterilerinin bu yazılımı kullanamadığını söyleyerek baskı kurdu
  • Söz konusu güvenlik açığı, mitmproxy'nin kullanmadığı bir kütüphane bölümünde bulunuyor; dolayısıyla gerçek kullanıcılar fiilen etkilenmiyor
  • Ana geliştirici bu talebi reddetmek yerine, zamanında bir yama sürümü gerekiyorsa ücretli destek sözleşmesi (support contract) yapılabileceğini söyledi ve profilindeki e-posta adresini işaret etti
  • Kurumsal kullanıcı ise bu yanıtı "şaka ya da ustaca gizlenmiş bir gasp girişimi" olarak algıladığını belirterek bir itiraz e-postası gönderdi
  • Asıl nokta, sürüm takvimi sorusunun meşru olması ama "katkı veya finansmanla buna nasıl yardımcı olabiliriz" şeklinde işbirlikçi bir tutumun gerekli olması; ilk yorumu yazan kişi daha sonra samimi bir özür gönderdi

Olayın arka planı

  • Eklenen bağlam açıklamasına göre, mitmproxy ile birlikte dağıtılan bir kütüphanede bir güvenlik açığı var; ancak bu açık mitmproxy'nin kullanmadığı bir bölümde olduğundan gerçek kullanıcıları etkilemiyor
  • Konu dışarıda viral olduktan (went viral) sonra ek bağlam da paylaşıldı

Kurumsal kullanıcının ilk talebi (GitHub issue)

  • 16 saat önce bir kullanıcı, başka bir proje üyesi olan @Prinzhorn'u anarak bir sonraki sürüm için hedef tarihi (target date) sordu
  • Bankalar, federal kurumlar gibi düzenlemeye tabi sektörlerdeki (regulated industries) müşterilerin, kurallar gereği bilinen High·Critical seviyede açıklar içeren yazılımları kullanmasının yasak olduğunu açıkladı
    • Bekleme konusunda kendi kurumsal tutumlarını belirlemek istediklerini, ancak bunun için bir tür hedef tarihe ihtiyaç duyduklarını söyledi

Ana geliştirici mhils'in yanıtı

  • Üye mhils, 15 saat önce verdiği yanıtta, şirketin uyumluluk gereksinimlerini karşılamak için zamanında bir yama sürümü ile ilgileniliyorsa bir destek sözleşmesi yapmaya istekli olduğunu belirtti
  • İletişim bilgisinin profilindeki e-posta adresinde olduğunu söyledi (":-)" ifadesiyle birlikte)

İtiraz e-postası ("Concerning response")

  • Ardından us.ibm.com alan adına ait bir adresten github@hi.ls adresine "Concerning response" başlıklı bir e-posta gönderildi (Jul 14, 2023 tarihli)
  • "Mr. Hils" diye başlayan e-postada, konuyu tırmandırmak ya da GitHub issue takipçisini gereksiz sözlerle doldurmak yerine, doğrudan bir yanıt alabilmek için hedef tarih talebini daha iyi açıklamaya çalıştığı belirtildi
    • Bu takip e-postasının rahatsız edici algılanmamasını umduğunu, böyle bir niyetinin olmadığını da açıkça ekledi
  • Vurgulanan bölümde, ana geliştiricinin yanıtının resmî proje yanıtı değil bir şaka, ya da daha kötüsü ustaca gizlenmiş bir gasp girişimi (thinly veiled extortion attempt) olduğu varsayımını dile getirdi (ardından proje resmî belgelerini incelerken cümle yarım kalıyor)

Ana geliştiricinin pozisyonunun özeti

  • Yanıtın şaka olmadığını açıkça belirtti
  • "Ücretli müşterilerimizin X'e ihtiyacı var, bunu ne zaman düzelteceksiniz" tarzı bir yaklaşımın, açık kaynak projelere kendini tanıtmanın en iyi yolu olmayabileceğini söyledi
  • Sürüm takvimi sorusunun kendi başına rahatsız edici olmadığını ve geçerli (valid) bir soru olduğunu kabul etti
    • Ancak bağlamın, "biz bunun gerçekleşmesiyle ilgileniyoruz, bunu başarmaya nasıl yardımcı olabiliriz" (katkı veya finansman) olması gerektiğini; "müşterilerimize sorun çıkarıyorsunuz" olmaması gerektiğini vurguladı

Kapanış

  • İlk yorumu yazan kişi samimi bir özür (genuine apology) gönderdi ve ana geliştirici bunu içtenlikle takdir etti
  • Herkese iyi niyet varsayımıyla hareket etmeleri (assume good intentions) ve nazik davranmaları çağrısında bulundu

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-16
Hacker News görüşleri

  • Bu issue'yu okursanız https://github.com/mitmproxy/mitmproxy/issues/6051 IBM'in talebinin tweette göründüğünden çok daha makul olduğunu görürsünüz.
    Sorun, mitmproxy'nin bir bağımlılığında CVE olması; mitmproxy Mart ayında bağımlılığı güncellemiş, ancak bu güncellemeyi içeren kararlı bir sürümü henüz yayımlamamış. IBM tarafı “ne zaman release tag'i atmayı planlıyorsunuz, müşterilere iletebileceğimiz bir takvim var mı” diye soruyor.
    Özellikle “ne zaman düzelteceksiniz” diye sormuyorlar. Zaten düzeltilecek bir şey yok; daha çok “bu bağımlılık güncellemesini içeren yeni sürümü ne zaman çıkarmayı planlıyorsunuz” diye soruyorlar.
    Bu sorunun kendi başına haksız olduğunu düşünmüyorum. Elbette böyle bir düzeltmenin belirli bir süre içinde dağıtılmasını istiyorlarsa destek sözleşmesi talep etmek de haksız değil; ama “destek sözleşmeleri için e-posta ile iletişime geçin” şeklindeki anında yanıt biraz aşırı görünüyor.

    • İlk soru kibar ve makuldü, @mhils'in yanıtı da öyleydi. Hiç makul olmayan şey, IBM tarafının sonraki e-postasında bunu “ince bir şekilde örtülmüş bir haraç girişimi” diye nitelemesiydi.
      Maximilian'ın para ödemeyen birine yayın takvimi sunma yükümlülüğü yok; IBM gerçekten bir zaman çizelgesine ihtiyaç duyuyorsa bunun için ödeme yapmasını önermesi de hiç tuhaf değil. IBM bunu bu kadar önemli görüyorsa bugün bile kendi mitmproxy iç sürümünü oluşturabilir.
    • Yayın tarihi sormak tamamen makul bir talep. Ancak benim yanıtım bağlamdan çok etkilendi.
      “Destek sözleşmeleri için e-posta ile iletişime geçin” dememin nedeni 1) o thread'de bu konu için bir patch release çıkarmayacağımızı zaten belirtmiş olmamız ve 2) karşı tarafın kendi ücretli müşterileri üzerindeki etkisini vurgulamasıydı.
      Bu yüzden orada söylenecek başka pek bir şey yoktu. Daha iyi ifade edilebileceğine katılıyorum, ama yanıtımın tamamen aşırı olduğunu hissetmiyorum.
      CVE'nin kendisi de saçma ve biz o bağımlılığın ilgili kısmını kullanmıyoruz.
    • O kısım oldukça net. Sorun, sonraki iletişimde “ince bir şekilde örtülmüş haraç” ifadesinin kullanılması; bu da makullükten çok uzak.
    • Bakım sorumlusunun açıkladığı gibi, o CVE'nin mitmproxy üzerinde fiilen etkisi yok. Sonuçta bu sadece bir güvenlik görevlisinin bir checkbox'ı temizlemesine yardımcı olmak.
      Talep eden taraf ücretsiz emekten fayda sağlarken bakım sorumlusu neden bedavaya çalışmak zorunda olsun?
      Haksız olan FrugalGuy'ın bunu kendiliğinden hakkıymış gibi gören tavrı. Bir açık kaynak bakım sorumlusundan bedavaya çalışmasını isteyip sonra bunu haraç diye suçlamak için epey özel bir ikiyüzlülük gerekir. Yarı zamanlı olarak özgür açık kaynak projesi yapan bir gönüllüye talepleri dayatamazsınız.
    • Yine de bakım sorumlusuna e-posta gönderirken kullanılan tehditkâr ton değişmiyor.

  • OP benim. Açık konuşayım: sürüm sorusunun kendisi hiç sorunlu değil, gayet geçerli.
    Ancak bağlam “biz bununla ilgileniyoruz, gerçekleşmesi için nasıl yardımcı olabiliriz” olmalı. Katkı ya da para yoluyla. “Senin yüzünden müşterilerimiz sorun yaşıyor” olmamalı.
    Talepte bulunan kişinin tek bir yanlış söz yüzünden perişan olmasını istemiyorum; büyük şirketlerin özgür açık kaynak yazılımla sağlıklı bir ilişki kurmasını istiyorum.

    • Benim projem olsaydı destek sözleşmesi önermeyebilirdim. İş hukuku ve vergi hukuku meseleleri benim için fazla karmaşık.
      Böyle bir sözleşme önermesi aslında oldukça nazik bir davranış. FrugalGuy “pull request gönder” yanıtını da alabilirdi; bundan memnun olur muydu bilmiyorum.
    • Duyguları ve insanları bir kenara koyarsak, bir yazılım projesi olarak mitmproxy'nin şu anda hemen yeni bir sürüm yayımlamasını engelleyen şeyin ne olduğunu merak ediyorum.
    • Bunu okuyunca GitHub yorumumu silmek istedim, ama thread kilitli olduğu için silemedim.
    • Katkı ya da paranın sürüm sorununu nasıl çözdüğünü anlamıyorum. Bir bug olsaydı düzeltilip patch olarak gönderilebilirdi.
      Ama sorun zaten yapılmış bir düzeltme için release olmamasıysa, bunun katkı ya da parayla nasıl çözüleceğini pek bilmiyorum.
    • Yine de bu bir haraç girişimiydi.

  • Bu, kendi “düzelttiği” şeyin ne olduğunu bile bilmeyen bilgi güvenliği aptallarının tipik örneği gibi geliyor. Otomasyon sistemi bir CVE olduğunu söyleyince bunun mutlaka “patch”lenmesi gerektiğini düşünen türden insanlar
    CVE’nin iddiasının ne olduğuna, kendi somut kullanım biçimlerinin gerçekten savunmasız olup olmadığına bakmazlar. Bilmezler, ilgilenmezler ve programcı da değillerdir. Tek bildikleri bir onay kutusunu temizlemeleri gerektiğidir
    h2database’de de benzer bir şey olmuştu. Bir “güvenlik araştırmacısı”, yapılmaması söylenen şeyi yaparsanız kötü şeyler olacağını keşfetti ve yine de CVE talep edip aldı. İnceleyince saçmalık olduğu anlaşılıyor, ama bu insanlar için önemli olan tek şey bir CVE’nin var olması
    h2database geliştiricisinin söylediği: https://github.com/h2database/h2database/issues/3686#issueco...
    “Gönüllüler tarafından geliştirilen bir açık kaynak projesini kullanan ‘büyük şirketlere’ neden zerre kadar sempati duymam gerektiğini anlamakta zorlanıyorum. Şirket parasıyla birini işe alıp halletsinler ya da benzer bir ticari kütüphaneye para ödesinler”

    • Onlar da tüm bunları bilip anladıkları hâlde umursamıyor olabilir. Belki de performansları, onay kutularını ne kadar hızlı temizledikleriyle ölçülüyordur ve fazla onaylamak yerine fazla reddetmek onlar için daha dezavantajlıdır
      Belirli bir durumda istisna verme yetkileri olsa bile, bu kararı gerekçelendirmek için daha fazla evrak doldurmaları gerekebilir. O ek evrak işleri yavaşlatır ve performans değerlendirme metriklerinde aleyhlerine işler
    • Vay, o CVE gerçekten akıl almaz
      “Parolayı komut satırıyla verirseniz sistemdeki diğer süreçler bunu ps ile görebilir”
      Çok bariz. Bu “yüksek önem dereceli” bir CVE ise bana da güvenlik araştırmacısı diyebilirsiniz. Aynı şeye izin verip yanına “bunu böyle yapmayın” uyarısı koyan en az beş altı uygulama sayabilirim
    • Tamamen katılıyorum. Regülasyonlu bir sektörde çalışıyorum ve akış şöyle
      Bilgi güvenliği ekibi raporda görünen zafiyeti yukarı taşır, yönetici paniğe kapılır
      Geliştirici sürekli güncelleme yapmak zorunda kalır. Çalışma zamanı olmayan bağımlılıklar bile buna dahildir. İstisna başvurusu yapılabilir, ama o tamamen ayrı bir baş ağrısıdır
      Sonra yönetici geliştirme işlerinin neden yavaşladığını merak eder
    • SaaS’ın hâlâ biraz “egzotik” görüldüğü bir sektörde SaaS tedarikçisinde çalışıyorum. Saçma sapan güvenlik anketleri alıyoruz; yanıtların %90’ı geçerli değil
      Kalan yanıtları gerçekten birinin inceleyip incelemediğinden de şüpheliyim

  • Benim projelerimden birinde de birden “ne zaman düzelteceksiniz”, “ben de etkileniyorum ve bu önemli” gibi yorumlarda patlama olmuştu. Böyle ani bir ilgi oldukça tuhaftı
    Sonra, yaklaşık aynı dönemde, bir şirketin yöneticisinin çalışanlarına, gerçekte olduğundan çok daha fazla kişinin etkilendiği izlenimi vererek bana baskı yapmalarını söylediğini anlatan bir özür e-postası aldım

    • En iyi yanıt “saatlik ücretim $XYZ, nakit veya çek kabul ederim” demektir

  • Görünüşe göre biri, kendi iş yerinde agresif veya tehditkâr bir üslubun çok etkili olduğunu öğrenmiş, ama buradaki pazarlık konumunun tamamen farklı olduğunu anlamamış

    • Bunu 27 yıl yaparsanız IBM’de Program Manager Secure Engineering and Incident Response pozisyonuna terfi edersiniz

  • “Ne zaman olacağını bilmem gerekiyor ki plan yapabileyim” ile “Senin çalışman sayesinde para kazanıyorum, bunu yapmalısın, lütfen acele et” arasında ince bir fark var
    Talepte bulunan kişi arka plan bilgisini çıkarsa, üslup birincisine daha yakın, ikincisine daha az yakın olurdu

    • Bunun doğru yaklaşım olduğuna katılmıyorum. Açık kaynak bir projede bir şeyin neden faydalı olduğunu açıklamakta hiçbir sorun yok
      Bu gerekçe başka birçok kullanıcı için de önemli görünüyorsa, bakım yapan kişinin bir özellik eklemeyi veya hatayı düzeltmeyi daha hızlı yapıp yapmayacağına karar vermesine yardımcı olabilir. Bir geçici çözüm varsa onu bulmaya da yardımcı olur
      Geliştiriciyi haraca bağlamak diye nitelemek haksızdı, ama ilk mesajın kendisinde sorun olduğunu düşünmüyorum

  • Açık kaynağı kullanırken bir de destek talep eden şirketlerin hak görme duygusu inanılmaz. Kullanım kısıtlaması olan lisansların daha yaygın kullanılmasını isterdim; OSI’nin de sadece “Bu açık kaynak değil!!!” demekle yetinmemesini isterdim
    Böyle lisanslar bu tür durumların önüne geçebilir

    • GNU AGPLv3, şirket avukatlarını o kadar kızdırıyor ki fiilen ticari olmayan bir lisans gibi işleyebiliyor. Ama gerçekte ticari olmayan bir lisans değil; hem OSI’nin hem de FSF’nin ölçütlerini karşılıyor
      Her hâlükârda OSI ve FSF’nin burada sert bir tutum alması iyi. Öncelikleriniz onlarınkiyle uyuşmuyorsa, sizi memnun etmek için neden değişsinler ki?
      Beğendiğiniz lisansı kullanın gitsin. Onlar onaylamasa bile. Bunun neden sorun olduğunu anlamıyorum. En başta onların değerlerini paylaşmıyorken, bu kuruluşlar neden sizin lisans tercihinize onay mührü basmak zorunda olsun?
    • Katılıyorum, ama OSI’nin masraflarını kimin karşıladığına bakmak yeterli: https://opensource.org/sponsors/
      Kurumsal sponsorlar için kullanım kısıtlamalarını desteklememek bir kusur değil, bir özellik
      Açık kaynak ve özgür yazılım tanımlarının etrafında muazzam bir dogmatizm de var. Bu tanımlara uymazsanız, üzerinize çullanılıp saldırıya uğramanız kolay; bu tanımlar da çoğu zaman kutsal metin gibi ele alınıyor. Savunucuları, 2023 gerçeklerine göre bir uyarlama gerekebileceği ihtimalini bile kabul etmek istemiyor
      Çatışmadan kaçınmak için yeni terimler oluştursanız bile, açık kaynak ve özgür yazılım savunucuları kendi dillerinde ısrar edip anlatıyı kontrol etmeye çalışıyor. O dil, kendi çevreleri içinde olumsuz çağrışımlar taşıyacak şekilde tasarlanmış
    • Kullanım kısıtlamalarının daha yaygın olmasını istemem. Hayır; LGPL, GPL ve AGPL’nin sunduğu farklı sertliklerdeki aynı koşulla paylaşımı zorunlu kılma kapsamı dışındaki “kullanım kısıtlamaları” ise istemem
      Kullanıcının yazılımı herhangi bir amaçla çalıştırma özgürlüğü özgürlük 0’dır; Stallman kullanım kısıtlamalarının neden faydalı olmadığını çok ikna edici biçimde açıklıyor: https://www.gnu.org/philosophy/programs-must-not-limit-freed...
      Garanti reddi maddelerinde olduğu gibi, özgür yazılım koşulsuz verilir. İstediğiniz gibi değiştirme özgürlüğü size hediye edilmişken bir de ücretsiz destek ve bakım talep etmek kabalıktır. Lisansı değiştirmenin böyle kaba insanları ortadan kaldıracağını sanmıyorum
    • Çoğu kişinin bu kadar şirket karşıtı olmak istediğini sanmıyorum. Öyle olsaydı en başta izin verici lisans kullanmazlardı
      Ayrıca lisans dışında, şirketlerden çok açık kaynağa daha dost olabilecek seçenekler de bulunabilir. Örneğin birinin kritik bir issue açmak için yeniden üretim kodunu herkese açık paylaşmasının gerekmesi gibi
    • Bunun sorunu nasıl çözeceğinden pek emin değilim. Muhtemelen o yazılım hâlâ iş ortamında kullanılacak ve yine işvereni adına destek talep eden biri çıkacaktır
      80’lerde desteğin genellikle ücretsiz verildiği dönemlerde bile, şirketlerin korsan yazılımlarla böyle şeyler yaptığına dair çok hikâye duydum. Bu tür numaraları azaltan tek şey ücretli destek sözleşmeleriydi
      Gerçekçi karşılık, lisans ihlali nedeniyle dava açmaktan ibaret; ama bırakın orta ölçekli şirketleri, büyük şirketlere karşı bunu yapacak imkâna sahip açık kaynak geliştiricisi pek yok

  • “FrugalGuy”ın davranışı olgunluktan uzak ve çocukça, ancak mitmproxy bakımcısı daha iyi bir yöntemle, kibar ama net biçimde, yanlış anlaşılmaya ya da drama çıkmasına yer bırakmayan bir yanıt verebilirdi
    “mitmproxy lisansı uyarınca bu yazılım hiçbir garanti olmadan olduğu gibi sağlanır; proje bakımcıları şu anda başka önceliklere ve çıktılara bağlı durumdadır”
    “Bu nedenle Github issue tracker’daki beyanlar tek başına bir issue’nun önceliklendirilmesini gerekçelendirmek için yeterli değildir. Issue önceliğini yükseltmenin tek yolu bir destek sözleşmesi yapmaktır; bu da [here] üzerinden sunulmaktadır. Koşulları ayrıca memnuniyetle görüşürüz”

    • Gerçek yanıttan özünde pek farklı görünmüyor. Hatta biraz daha kaba; belki amaç da budur. Bu yüzden gerçek yanıta kıyasla ne kattığını pek anlamıyorum
    • Gerçek yanıtı da kibar ve net buldum
    • Hayır. O yanıt da asıl kişi kadar tuhaf. Ortamı okuyamayan bir istekte bulunup bir de kibar yanıt alma hakkınız yok

  • Bir mühendisin bir yıllık maaşı kadar bir tutar, bazı şirket ölçeklerinde hiçbir şey sayılmayacak bir para; düzeltmenin birkaç hafta içinde yapılabileceğini düşünüyorum ve bu adil olur
    Ya da gerçekten para ödemek istemiyorlarsa, kendi şirketlerinden bir mühendisi birkaç ay ayırıp ücretli müşterilerinin ihtiyaç duyduğu kısmı yamalasın ve upstream’e katkıda bulunsunlar
    Düzeltme: Bir mühendisin bir yıllık toplam ücreti dediğim şey, benim sınırlı ve hatalı bir tahminimden ibaret. Tam olarak ne kadar değerinde olduğunu söyleyecek konumda değilim; ancak kod tabanına aşina olmayan bir mühendis için muhtemelen birkaç aylık emek gerekeceğini tahmin ediyorum

    • Görünüşe bakılırsa yalnızca daha yeni bir release’i build etmeleri yeterli. Düzeltme zaten yapılmış
      Ancak bunu yapmak başka uyumluluk sorunları doğurabilir; muhtemelen bu yüzden yapmamışlardır. Elbette bu açık kaynak projesinin sorunu değil

  • https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...

    • OP’nin bağlantı verdiği takip e-postası tamamen sınırı aşmış, ancak bu GitHub yazısının kendisinin sorun edilecek bir şey olduğunu düşünmüyorum. “Para ödeyin” yanıtında da sorun yoktu
      “Bir sonraki release için hedef tarih var mı?” diye basitçe sormak sorun değil. Çünkü bu bir talep değil
      “Bekleme yönünde şirket içi gerekçemizi oluşturmaya çalışıyoruz, bir hedef tarihe ihtiyacımız var” ifadesindeki “ihtiyaç”, mitmproxy geliştiricisinden talep etmek gibi değil, başka insanların ondan talep ettiği bir şey gibi okunuyor
      Bu yorumda bir istekte bulunulurken o isteğin ticari ve kişisel motivasyonu açıklanıyor. Gasp gibi kelimelerle e-posta üzerinden geri dönene kadar sorun yoktu
    • Belirli kişinin kim olduğu önemli mi?
      Orijinal yazıda hem bağlam hem işveren vardı. Yazarın bundan bilerek kaçınmaya çalıştığı açıkken gerçek GitHub issue’sunu yaymak da berbat bir davranış
    • FrugalGuy ha, diyecek söz bulamıyorum