- rsync bakımı, güvenlik raporlarındaki patlama ve yapay zeka kullanımı tartışmasının çakışmasıyla; testler, kod kapsamı, çoklu platform CI, güvenlik taramaları ve derinlemesine savunma gerektiren bir duruma gelmiş durumda
- Yeni Python test paketi, mevcut kabuk betiği yapısını değiştiriyor ancak tasarım ve doğrulama planı bakımcı tarafından yürütülüyor; Claude, Codex ve Gemini ise tekrarlı işlerde yardımcı olarak kullanıldı
- 3.4.3 sürümü, güvenlik düzeltmelerine öncelik verirken mevcut testlerin ve manuel testlerin yakalayamadığı bazı geçerli ama alışılmadık kullanım senaryolarında regresyonların ortaya çıktığı bir sürüm oldu
- pytest, başka projelerde yoğun kullanılmış olsa da rsync test paketinin belirli gereksinimlerine uymadığı için ayrı bir yaklaşım tasarlandı; LLM'lerin dikkatli kullanılması gerektiği ama faydalı araçlar olduğu düşünülüyor
- Gelecek yön, regresyonları hafifletecek 3.4.4 ile büyük güvenlik değişikliklerini içerecek 3.5.0 arasında belirleniyor; openrsync ise yeni test paketinde 98 testten 85'inde başarısız durumda
Güvenlik raporlarındaki patlama ve savunmanın güçlendirilmesi
- rsync bakımcısı, son dönemde diğer açık kaynak paket geliştiricileri gibi üzerine yağan güvenlik raporlarıyla uğraşıyor; bu raporların çoğu yapay zeka üretimi olsa da dikkatli ve yüksek seviyeli bazı manuel analizler de bulunuyor
- Raporlardaki artış büyüdükçe rsync için daha kapsamlı bir test paketi, kod kapsamı analizi, daha fazla platformda CI testleri, kasıtlı güvenlik sorunu taramaları ve derinlemesine savunma teknikleri gerekli hale geldi
- Bakımcı emekli olmuş durumda ve daha fazla yelken yapmak istiyor, ancak gereken iş yükü nedeniyle çeşitli yapay zeka araçlarını kullandı ve bu seçiminden pişman değil
Python test paketi ve yapay zeka destekli çalışma
- Mevcut kabuk betiği tabanlı rsync test paketi Python ile yeniden yazıldı ve temel tasarım ile doğrulama planı doğrudan bakımcı tarafından yürütüldü
- Claude tekrarlı işlerde kullanıldı, Codex ve Gemini ise çapraz kontrol için kullanıldı; süreç, basitçe “test paketini Python'a çevir” diye devredilmiş bir çalışma değildi
- Bakımcı tüm bölümleri bizzat gözden geçirdi, çok fazla CI zamanı harcayarak sistemi oturttu ve daha sonra CI bekleme süresini azaltmak için testlerin çoğunu birden fazla yerel VM üzerinde çalıştırmaya geçti
- Commit geçmişindeki
co-authored by claude ifadesinin, tüm yazılım mühendisliği çalışmasının yalnızca bir bölümünü görünür kıldığı düşünülüyor
LLM tartışması, pytest seçimi ve 3.4.3 regresyonları
- LLM'ler, nasıl çalıştıkları biliniyor diye değersiz araçlar haline gelmiyor; dikkatli kullanılmaları gerekiyor ama mevcut yazılım mühendisliği ve BT güvenliği bakım ortamında yararlı oldukları düşünülüyor
- rsync 3.4.3, güvenlik sorunlarını düzeltmeye öncelik verecek şekilde bilinçli olarak yönlendirilmiş bir sürümdü ve bu süreçte geçerli ama alışılmadık bazı kullanım senaryoları değişikliklerden etkilendi
- Etkilenen kullanım senaryoları, mevcut rsync test paketine ve manuel testlere dahil edilmemişti; GitHub deposundaki issue ve PR'lar üzerinden bildirilen regresyonlar sırayla ele alınıyor
- pytest başka projelerde sık kullanılmış olsa da rsync test paketinde gerekli bazı işlerin pytest ile çok zor olacağı düşünüldüğü için ayrı bir test yaklaşımı tasarlandı
Sonraki sürüm ve güvenlik testlerinin genişletilmesi
- Güvenlik raporları gelmeye devam ediyor ve şu anda birden fazla CVE üzerinde çalışılıyor
- Sistem geliştirme becerisi ve güvenlik bilgisi olan başka geliştiriciler de katıldı; bunların bir kısmı son dönemdeki öfke sayesinde görünür hale gelen kişiler
- Sonraki seçenekler, bazı regresyonları hafifletecek 3.4.4 ile çok daha büyük değişiklikler içeren 3.5.0 arasında; 3.5, rsync'in güvenlik standardını önemli ölçüde yükseltecek ama kapsamı büyük bir sürüm olacak
- Büyük değişiklik setlerini hızlıca uygulayabilmek için rsync gibi bir yazılımda kapsamlı bir test paketi gerekiyordu ve yeni test paketinin yeniden yazılması bu ihtiyaçtan doğdu
- 3.5 sürümünde, güvenlikle ilgili sorunları ele alan ek testler yer alacak
openrsync karşılaştırması ve kod inceleme çağrısı
- openrsync'in belirli platformlar için paketlenmesine yönelik akıma karşı, yeni rsync test paketinin openrsync üzerinde de uygulanabileceği yönünde bir yanıt verildi
- Çalıştırma örneği aşağıdaki komuttur
./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp
- openrsync şu anda 98 testin 85'inde başarısız oluyor; başarısızlıkların çoğu openrsync'te bulunmayan özelliklerden kaynaklansa da bunun iyi bir sonuç olmadığı belirtiliyor
- Daha fazla öfke saçmak yerine, kamuya açık kodun gerçekten incelenmesi ve yapıcı eleştiriler sunulmasının daha tercih edilir olduğu isteniyor
1 yorum
Lobste.rs görüşleri
Alıntıya bakınca, yazarın yelken yapmak istediği halde proje bakımının yarattığı baskıyı hissettiği ve LLM kullanarak ikisini de yapabileceği bir çözüm görmüş gibi okudum
Emekli olup yelkenin tadını çıkarırken bug düzeltmemek de sorun değil, bir açık kaynak projesindeki bug’ları düzeltmemek de sorun değil. Yeter ki bunu açık ve şeffaf biçimde söylesin. Eski deyişle “patch’lere açığız” demek yeterli. Özellikle de bol kaynağı olan şirketler o projeye bağımlıysa bu daha da geçerli
Keşke daha fazla bakımcı ve geliştirici, açık kaynak bakımında LLM “yardımı” almak zorundaymış gibi hissetmeden emekliliğin ve yelkenin tadını çıkarabilse. Yine de rsync projesinde LLM denemek istiyorsa bu onun seçimi. Ben dahil başkaları katılmasa da
Sebebi ne olursa olsun, açık kaynak geliştiricilerine eziyet edenler ücretsiz açık kaynak yazılımın bir ürün değil, bir armağan olduğunu unutuyor gibi görünüyor
Dışarıdan izleyenler beğenmiyorsa fork’layabilir. Andrew projede istediği şekilde çalışabilir ve bizim yorumlarımızla fikirlerimiz zorunlu değil
Umut veren taraf, uzun vadede rsync bakımını üstlenecek başka birinin çıkabilecek olması. Tridge geçmişte bunu zaten yeni bir bakımcıya devretmişti
OpenJS Foundation’ın bazı projelere fon ve geçiş desteği vererek tek bakımcı modelinden ekip bakımına geçiş sağladığı örneklerle ilgili bir sunumu dinleyip LWN için yazı yazdım; bugün yayımlanacak. rsync gibi projelerin buna çok daha fazla ihtiyacı var
Güvenlik sorunları büyük baskı yaratıyor, görünürlüğü yüksek oluyor ve çoğu zaman bakımcının ilgi duyduğu proje özünden uzak kalıyor
Bakım çok sorumluluk getiriyor ve hepsi keyifli değil ama özgür açık kaynak bakımcıları bunları da üstlendiğinde minnet duyuyorum. Bunu yapan çok kişi varmış gibi görünmüyor
LLM yardımı olmadan belirli bir hedefe ulaşmanın maliyeti fazla yüksek görülüyor olabilir; LLM yardımıyla bu maliyet makul hale gelebilir
Olumlu açıdan bakarsak, sağlıklı bir iş-yaşam dengesi kurmaya çalışan bir açık kaynak bakımcısı, LLM ile iş yükünü azaltıp istediği hedeflere daha kolay ulaşabilir hale gelmiştir
Seçilip alıntılanan kısım sadece girişin bir parçası ve bu yazı açıkça temel açık kaynak bakımından bahseden bir yazı değil; dikkatli ve nüanslı bir bağlam içinde yazılmış
Daha da tuhaf olan, alıntının hemen öncesindeki bağlamın atlanmış olması. Raporlar patlayınca rsync için savunma hattını ciddi biçimde yükseltmek gerektiği; çok daha kapsamlı bir test suite, code coverage analizi, daha fazla platformda CI testleri, güvenlik sorunlarının araştırılması ve savunmayı derinleştiren tekniklerin eklenmesi gerektiği anlatılıyordu
Bu durumda yazar emekli olmuş olsa da, diğer açık kaynak projelerinde işi ya da başka uğraşları olan insanlar benzer bir iş yükü artışına kapılabilir. Açıkçası bu yorumun bu kadar çok oy almasına şaşırdım ve iyi niyetle yazılmış gibi gelmiyor. En azından sadece başlığı görüp koşarak yazılmış bir yorumdan ancak biraz daha iyi, özensiz bir tepki gibi duruyor
Tacizi mazur göstermek ya da onaylamak istemem ama bu savunmada eksik kalan bir gerekçe var
Açıklama şu: yazar vibe coding için tasarımı yaptı, ortaya çıkan kodu inceledi, koda ve chatbot’lara hâkimdi, vibe coding’i dikkatli kullandı ve güvenlikle işlevsel regresyonlar arasında denge kurmaya çalıştı. Kulağa makul geliyor ama gerçekte regresyonlar oldu ve yazar nedenine kadar inemedi
“AI araçları basit işlerde iyi olduğu için onları böyle görevlere verdim” dedi ama öyle değil. Chatbot’lar aslında yazma işinde pek iyi değil. Asıl mesele bu ve yazarın bunu fark bile etmediği anlaşılıyor
Son zamanlarda sayıların gerçekten artıp artmadığını doğrulamak iyi olurdu. Regresyonların kendisi nadir bir şey değil ve bence insanlar Andrew’ya yüklenmek için bahane arıyor olabilir
Yazar, rsync 3.4.3 sürümünde bazı kullanım senaryolarında regresyonlar olduğunu kabul etti; o sürümde güvenlik sorunlarını düzeltmeye bilerek daha fazla ağırlık verdiğini ve geçerli ama sıra dışı bazı kullanım senaryolarının bu değişikliklerden etkilendiğini anlattı
Bu senaryolar mevcut rsync test suite’inde ya da kendisinin yaptığı manuel testlerde yer almıyordu; şu anda regresyonlarla ilgilendiğini ve bunları GitHub deposuna issue ya da PR olarak bildirenlere teşekkür ettiğini söyledi. Kendi kullanım senaryonuz etkilendiyse özür dilediğini ve güvenlik riskini göze alıyorsanız önceki sürümü kullanabileceğinizi de ekledi
“Yazılım mühendisliği dünyası son birkaç ayda dramatik biçimde değişti”, “BT güvenliği ve rapor seli içinde yazılımı sürdürme dünyası son birkaç haftada tamamen değişti” sözlerini yaklaşık son altı aydır durmadan duyuyorum ve bu yorucu
Bu rapor selinin sebebi LLM ise, çözüm olarak LLM aramak inanması güç derecede yanlış bir yön gibi geliyor
Yine de şu anda popüler bir şeyi sürdürmenin korkunç olacağına hemen inanabilirim. Belki de onun için en iyisi, sınırlı hesaplama zamanını daha da zorlamak yerine geri çekilip gerçek emekliliğin tadını çıkarmaktır
İnsanların iddia ettiğinin yarısı kadar bile faydalı bir araçsa, bu fayda kendini zaten gösterir diye düşünüyorum
Yine de Tridgell gibi birinin söylediklerini dinlemeye değer. Ayrıca güvenlik raporlarının “seli” ciddiye alınmalı. Kim, ne bulmuş olursa olsun güvenlik sorunu güvenlik sorunudur. Bu yüzden bu yazı, normalde gördüğüm bayat saldırılardan farklı hissettiriyor
Sonunda LLM bağımlılığının giderek arttığı bir aşağı yönlü sarmala girebiliriz
Bunun neden yanlış yön olduğunu düşünüyorsun? Hiç kimsenin LLM sahibi olmamasının daha iyi olacağını mı kastediyorsun?
LLM destekli geliştirme ille de “çöp çıktı” olmak zorunda değil
Bu yazının yazılıp paylaşılmış olmasını takdir ediyorum. Özellikle, bazı regresyonları 3.4.4 ile hafifletmeyi mi yoksa çok daha büyük değişiklikler içeren 3.5.0'a mı gitmeyi düşündüğü kısmı dikkatimi çekti
Yazar bunu okuyorsa, burada 3.4.4 doğru yaklaşım gibi görünüyor. Son sürümde regresyonlar yaşanmışken hemen büyük bir 3.5.0'a geçmek, birçok kişiye pervasızca görünecektir. İnsanların farkı daha kolay anlamasını sağlarsanız kaygılar azalır
Yeni test paketinin temel yapısını master üzerinde önce açıkça geliştirmeyi planlamış ama bunun öfkeye yol açtığını görünce bunun kötü bir fikir olabileceğini söyleyen kısım için, daha az şeffaflığın algıyı ve tepkileri iyileştireceğini sanmıyorum. Olsa olsa daha büyük tepkiyi ertelemiş olursunuz
openrsync'e yeni rsync test paketini çalıştırmasını söylemek adil değil. samba rsync protokol 32, openrsync ise protokol 27 kullanıyor ve zaten özellik tamlığı iddiasında da bulunmuyor
Medium ve Cloudflare; birbirine karışmaması gereken korkunç bir ikili
https://archive.is/qbyVA
Açık kaynak bakımcılığı nankör bir iş. Tridge, test paketindeki teknik borcu düzeltmeye ve LLM'nin tespit ettiği CVE seline sorumlu biçimde yanıt vermeye çalışmış, ama galiba Hyrum yasasına çarpmış. 3.4.4 planı daha az kötü seçenek gibi duruyor ve sonunda onunla devam etmek gerekecek gibi.
Bu konuda iki tarafa da yakınım. Bir yandan, güvenliğin ancak insanlar kodu doğrudan yazdığında sağlanabileceğini düşünüyorum
çünkü kodu yazarken o kod üzerine düşünür ve hataları erken yakalarsınız. Ben inceleme yapmaktansa kodu doğrudan yazarken çok daha iyi iş çıkarıyorum. İnceleme sırasında her satır üzerinde dikkatle düşünmediğim için pek çok şey gözden kaçıyor
Öte yandan, tacizin kabul edilemez olduğu temel gerçeğini bir kenara koyarsak, Andrew kendi boş zamanında kendi projesini istediği şekilde yürütme hakkına sahip. LLM kullanmak istiyorsa ben katılmasam da bu onun projesi ve onun takdiri. Hoşuma gitmiyorsa yedeklerimi restic ya da borgbackup üzerine taşımam veya rsync'i fork etmem gerekir
Açık olmak gerekirse, vibe coding'in kendisine karşı değilim. İş yerinde yarı zorunlu olarak kullandırılıyor ve bugünlerde işimin büyük kısmını oluşturan sıkıcı, yeni olmayan glue code yazımında idare eder. Sadece boş zamanımda kullanmıyorum
rsynczaten mükemmel uygun bir çözüm de değilçünkü dosya içeriği bozulduğunda geri yüklemeye yardımcı olmuyor. restic gibi araçlar çok daha iyi ve dosyaların önceki sürümlerini de saklayarak bu tür durumları ele alıyor. Hatta silmeleri de takip ediyor, böylece hangi dosyanın artık ilgili olmadığını da bilebiliyorsunuz
Uygulama güvenliği deneyimim var, birkaç exploit seçebilirim ve incelemede de yakalayabilirim. Ama şu anki üst seviye LLM'lerin “daha patolojik vakaları bul” diye yineleme yapması kadar iyi değilim
Bu kadar popüler yazılımlarda, kendi kodumda, kullandığım kütüphanelerde ve alternatif uygulamalarda fazla çaba harcamadan sorunlar buldum. Bir insanın ayırabileceği zaman ve inatçılık gerçekten kıyaslanamaz
Kurum genelinde sorunları önlemek, tespit etmek ve bunlara yanıt vermek için güvenlik yazılımları geniş çapta konuşlandırılmış durumda. Her alanda her zaman boşluklar vardır ve yapılacak daha çok iş bulunur. Kurumlar, mükemmel olmayabileceklerini bilseler de, hiç iyileştirme olmamasındansa güvenlik duruşunu iyileştirmeyi tercih edebilir. LLM'nin sunduğu ödünleşim de bunun bir parçası
Bu ödünleşim noktası bağlama göre değişir, ama “tüm kodlar elle yazılmalıdır” noktasına varması nadirdir
Bu, rsync gibi bir sunucu için de geçerlidir. Yazarın dediği gibi, onu daha sağlam ve dayanıklı kılmak için büyük bir refaktör gerekebilir. Eğer LLM ile yetki ayrımı yönünde refaktör yaparak daha küçük bir güven tabanlı kod elde edilebiliyorsa, bunun kapsamı dışındaki bazı hatalar kabul edilebilir
rsync'in özel bağlamını bilmiyorum, ama bu tür projelerin genelde sahip olduğu sınırlı kaynaklar içinde yazarın proje ve kullanıcılar için en iyi kararı verdiğine inanıyorum
Bunun karşılığında rclone paralellik sunuyor, bu yüzden kullanılabilir ağ bant genişliğini çok daha etkili kullanıyor
Bu, yaşanabilecek sorunların üst sınırını verir
Alt sınır ise benim bulabileceğim, başka birinin bulabileceği ya da LLM gibi başka bir şeyin bulabileceği hatalar ve zafiyetlerdir
Bir insanın kendi yazdığı C kodunu, örneğin rsync'i, gözden geçirdiği durumun bu alanda iyi bir konum olduğunu söylemek zor. Andrew'ü suçlamak gibi bir niyetim yok
Yelken açmak isteyen emekli bir bakımcıya sempati duyuyorum, ama bunun bağlamı temelden değiştirdiğini sanmıyorum
Tridgell'in bize herhangi bir çalışma borcu yok ve emekli olup yelken açmakta özgür. Bunu yapmak istiyorsa iyi olmasını dilerim. Sorumluluk hissettiği noktaya sempati duyuyorum ama satır aralarını doğru okuyorsam bunu bir ölçüde yük olarak hissediyor gibi
Ama rsync kritik bir yazılım ve onu bakımını üstlenen kişinin belli bir kalite standardını koruması gerektiğini düşünüyorum. Bakımcının yaptığı iş bu standardın altında kalıyorsa bu bir hatadır. Bu da taciz edilmeyi hak ettiği anlamına gelmez. Bir şeyin hata olduğunu söylemek, o hatayı yapan kişinin kötü olduğu ya da ona empati duymadığınız anlamına gelmez
Bu yüzden soru, AI kodlama araçlarının yaptığı işin standardı karşılayıp karşılamadığıdır. Buradaki standart kabaca şu: “Bu kalitede yapılmış olması, hiç yapılmamış olmasından daha mı iyi?” Yazılımı iyileştiriyorsa devam edilmeli, daha kötü hale getiriyorsa durulmalı. Bunun zekice bir tanım olduğunu iddia etmiyorum ama doğru tanımın bu olduğunu düşünüyorum
Tridgell'den ek çalışma talep etme hakkımız yok, ama eğer doğruysa “bu, kullanıcıları daha kötü durumda bırakıyor” deme alanımız var
Dürüst olmak gerekirse bu çalışmayı nasıl değerlendirmem gerektiğine dair tamamen netleşmiş bir fikrim yok. Bir regresyon vardı ve Tridgell bunun bir sınır durum olduğunu açıkladı, ama daha fazla bağlam olmadan bu sınır durum regresyonunun etkisini olası güvenlik sorunlarının düzeltilmesinin değeriyle nasıl karşılaştıracağımı bilmiyorum
Bazılarının aklına “WITHOUT ANY WARRANTY” gelebilir, ama bu madde burada alakasız. Bu, hukuki sorumluluğun reddidir; zanaatkârlık gururunun ya da elinden gelenin en iyisini yapmaya dair hukuk dışı beklentinin reddi değildir. Bu yorum da “WITHOUT ANY WARRANTY” ile sunuluyor, ama hata yaparsam elbette eleştirilebilirim
Onu kritik yazılım haline getiren yazar değil. Siz ya da başkası onu kullanıyorsa sorumluluk kullanıcıdadır. Yazılım beklendiği gibi çalışmıyorsa fork edebilir ya da yerine başka bir şey koyabilirsiniz. Yapamayacağınız şey, o kişiyi sizin istediğiniz tempoya göre hareket etmeye zorlamaktır
Orijinal regresyon haberini kaçıranlar için bağlam: https://github.com/RsyncProject/rsync/issues/929
Sorun bildirimi, mastodon post ekran görüntülerinden oluşuyor ve ardından yaklaşık 300'den fazla tartışmalı yorum gelmiş durumda
Açıklamaya gerek yok, sadece her zamanki gibi yapmaya devam edin. Hoşlanmayanlar hoşlanmamaya devam edecek
insanlar assembly yazmayı bıraktığından beri bundan hoşlanmamaya başladılar ve gelecekte de durmayacaklar