Git’in `--author` bayrağıyla GitHub deposundaki yapay zeka bot spam’i nasıl engellendi

 (archestra.ai)
2 puan yazan GN⁺ 10 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Archestra deposu, yapay zeka tabanlı katkılar arttıkça anlamsız yorum ve PR’ların akınına uğradı; gerçek tartışmalar görünmez hale geldi ve bakım yükü büyüdü
  • 900 dolarlık ödüllü issue, aslında gerçek katkıcıların tartışma alanıydı; ancak yapay zeka bot yorumlarıyla 253 yoruma kadar şişti ve saldırgan tavırlar da ortaya çıktı
  • x.ai provider desteği issue’suna kapatılmış ve birleştirilmemiş 27 PR geldi; bunların çoğu katkıcılar tarafından test bile edilmemişti
  • GitHub’ın prior contributor kısıtı, yeni gelen gerçek geliştiriciler ile yapay zeka botlarını ayıramadığı için Git --author ile onaylı kullanıcılar main commit’lerinin author alanına eklendi
  • Onboarding sürecinde etik yapay zeka kuralları ve CAPTCHA’nın ardından GitHub Action ile bir whitelist commit’i oluşturuluyor; şişirilmiş etkinlik metrikleri yerine kaliteye öncelik veriliyor

Yapay zeka bot spam’i açık kaynak depolarını nasıl ele geçirdi

  • Archestra deposunda, GitHub’ın yapay zeka tabanlı katkı metriklerindeki büyümenin aksine, sahada katkı kalitesi düşerken bakım yükü arttı
  • 900 dolarlık ödül konulan issue, gerçek katkıcıların plan önerdiği, soru sorduğu ve işi denediği bir alandı; ancak yapay zeka botları üşüşünce toplam 253 yoruma çıktı
  • Yapay zeka hesapları anlamsız uygulama planları bıraktı ve hatta bakımcılara karşı saldırgan tavırlar sergileyerek tartışmayı kirletti
  • Depoyu izleyen ekip üyeleri her yapay zeka yorumunda bildirim aldı; @ethanwater, @developerfred, @Geetk172 gibi gerçek katkıcıların konuşmaları arada kayboldu
  • x.ai provider desteği issue’suna kapatılmış ve merge edilmemiş 27 pull request geldi; bunların çoğunda katkıcılar test bile yapmamıştı
  • Ekipten bir kişi, test edilmemiş PR’ları ve halüsinasyon ürünü issue’ları temizlemek için her hafta yarım gününü harcamak zorunda kaldı; bu temizlik aksadığında depo gerçek katkıcılar için hızla elverişsiz bir yere dönüşüyordu

GitHub kısıtlarını aşan whitelist yöntemi

  • İlk önlemlerin sınırları

    • Archestra önce katkıcı itibarını hesaplamak için London-Cat adlı küçük bir bot geliştirdi
    • London-Cat, merge edilen PR’lar ve bazı sinyallere dayanarak katkıcı itibarını hesaplıyordu; örnekte görüldüğü gibi katkıcıları ayırt etmede yardımcı oldu
    • Ancak bu yaklaşım spam engelleme konusunda başarısız oldu
    • Sonraki adım olarak geliştirilen AI sheriff ise örnekte görüldüğü gibi bazı gerçek PR’ları da kapattı

  • Onboarding olmadan etkinliği engelleme

    • Anlamsız yapay zeka yorumları ve önerileri sürerken gerçek katkıcılar uzaklaştı; bunun üzerine ödülle katkı teşvik etme yöntemi ve iş adaylarına test görevi verme yaklaşımı bile yeniden değerlendirildi
    • Archestra, gerçek katkıcılar, sorumlu yapay zeka kullanıcıları, yeni başlayanlar ve deneyimli mühendislerin hepsi için rahat ve güvenli bir depo oluşturmak amacıyla önlemleri sıkılaştırdı
    • Artık onboarding’den geçmeyen kullanıcıların issue oluşturması, PR açması ve yorum yazması engelleniyor
    • VC yatırımı almış bir startup için GitHub etkinlik metrikleri hassas bir konu olsa da Archestra, yapay zeka slop ile şişirilmiş metriklerden çok kaliteyi önemsiyor

  • GitHub ayarlarının sınırları

    • GitHub’da açık kaynak depolar için yorum yazanları veya PR açanları doğrudan whitelist’e almanın basit bir yolu yok
    • “Limit to prior contributors” ayarı, daha önce main’e commit yapmamış kullanıcıların issue ve PR yorumları yazmasını engelliyor
    • Bu ayar, yapay zeka botları ile ödüllü işler için yeni gelen gerçek geliştiricileri ayıramıyor; ikisini de mevcut katkıcı olmayan kullanıcılar olarak görüyor

  • --author bayrağıyla whitelist oluşturma

    • GitHub, main branch’teki commit’in author alanına bağlı GitHub hesabını prior contributor olarak değerlendiriyor
    • Git commit’lerinde author ve committer olmak üzere iki kimlik alanı bulunur ve bu iki değer farklı olabilir
    • Git’in --author bayrağı kullanılarak başka bir kişiye atfedilmiş bir commit oluşturulabilir; e-posta ilgili GitHub hesabıyla eşleşirse GitHub bu commit’i o profile bağlar ve katkıcı statüsü verir
    • Her GitHub hesabının <id>+<username>@users.noreply.github.com biçiminde bir noreply e-postası vardır
    • Kullanıcının ID’si API ile sorgulandıktan sonra commit author olarak bu e-posta biçimi atanır
    gh api users/their-username --jq '.id'  
git commit \  
--author="their-username <ID+their-username@users.noreply.github.com>" \  
-m "chore: add their-username to external contributors"
    • Bu commit main’e push edildiğinde dış kullanıcı author, Archestra hesabı ise committer olarak görünür; GitHub da bu kullanıcıyı prior contributor sayarak anında yorum yetkisi verir

  • Gerçek onboarding akışı

    • https://archestra.ai/contributor-onboard - Web sitesinde etik yapay zeka kuralları ve CAPTCHA içeren onboarding yapılıyor
    • GitHub Action - Gönderim sırasında kullanıcının GitHub ID’si sorgulanıyor, EXTERNAL_CONTRIBUTORS.md dosyasına handle ekleniyor ve author alanı ilgili kullanıcı hesabı olan bir commit main’e push ediliyor
    • Kullanıcı - whitelist’e alınarak depoya erişim yetkisi kazanıyor
    • GitHub, yapay zeka üretimli etkinlikleri de içeren büyük ölçekli metrik artışları raporlarken açık kaynak proje ekipleri depodaki AI slop’u bizzat temizlemek ve gerçek katılımcı seviyesini korumak için geçici çözümler üretmek zorunda kalıyor
    • AI slop, iyi katkı yapmak isteyen insanları gürültünün içine iterek motivasyonlarını düşürmekle kalmıyor; LiteLLM repo örneğinde olduğu gibi, saldırganların yapay zeka botlarıyla konuşma başlatmaya çalıştığı güvenlik risklerini de beraberinde getiriyor

İlgili okumalar

1 yorum

 
GN⁺ 10 시간 전
Hacker News yorumları

  • Depo katkıcıları daha yüksek yetkilere sahip olduğundan, örneğin fork PR çalıştırmalarında onay gereksinimini atlayabildiklerinden, bu yaklaşımın gözden kaçan güvenlik etkileri var
    GitHub belgeleri de, “yalnızca ilk kez katkı yapanlardan onay iste” ayarında, depoya daha önce commit’i ya da PR’ı merge edilmiş bir kullanıcının artık onaya ihtiyaç duymayacağını ve kötü niyetli bir kullanıcının basit bir yazım hatası düzeltmesi gibi zararsız bir değişikliği kabul ettirerek bu koşulu sağlayabileceğini söylüyor

    • Doğru. Kurum üyesi olmayan kimseye güvenilemeyeceği için varsayılan ayarın tüm dış katkıcılar için onay iste olması gerektiğini düşünüyorum
    • Bu bir güvenlik etkisi değil
      Sırf birinin tamamen zararsız tek bir PR’ı depoya merge edildi diye güvensiz hale geliyorsa, o depo zaten baştan güvensizdir

  • Sorun, GitHub’ın buna izin vermiş olması. Yorum yazma ve PR oluşturma için çok temel gereksinimler koymuş olsaydı iş buraya gelmezdi
    Ayrıca issue’lar silinebildiği gibi PR’lar da silinebilmeli

    • Şu anda yöneticilerin PR’ı arşive alabilmesi üzerinde çalışıyoruz
      Amaç, bakımcıların depo katkılarını nasıl yönettikleri üzerinde daha iyi kontrol sahibi olması. Arşivlenen PR’lar yalnızca yöneticilere görünecek, ancak denetim ya da kurumsal/uyumluluk gereksinimleri için katkıcı kaydına bakımcılar erişmeye devam edebilecek. Böyle bir özellik yararlı olur mu merak ediyoruz
    • Bu değerlendirme doğru. Tıpkı spam e-postaları almamanın bireyin “kendi başının çaresine bakacağı” bir mesele olmaması gibi, bu da açık kaynak topluluğunun ya da tek tek projelerin kendi kendine çözmesi gereken bir sorun değil
    • PR’ı kapatmak yerine silmenin ne kazandırdığını anlamıyorum. Kapalı bırakmak hangi PR’ların kabul edilmediğine dair bir sinyal verir; silince bu avantaj kaybolur

  • PR spam’i, ödül veren depolar için büyük bir sorun. PR’larının %95’inden fazlası reddedilen hesapların GitHub tarafından geçici olarak PR açması engellenmeli olabilir

    • GitHub’da örneğin tek PR’lık token veren bir sistem olsa güzel olurdu
      Biri anlamlı bir tartışmaya katılır ve bir issue’yu ya da özelliği çözmek için iyi fikirler gösterirse, başta ona bir PR token’ı verirsin; PR kalitesi iyiyse birkaç tane daha verirsin; sonunda da serbestçe PR açabilen bir katkıcıya yükseltirsin. Issue’lar için de benzer bir sistem iyi olurdu ama issue bir PR katkısının başlangıç noktası olduğunda nasıl görünmesi gerektiğinden emin değilim. Yine de GitHub/MS’in Copilot abonelikleri ve token satmak istediğini, LLM üretimi PR’ların da bunun iş modelinin bir parçası olduğunu düşünürsek, bunun gerçekten gelmesi pek olası görünmüyor
    • GitHub’ın AI engellemesi için bir teşviki yok. Bu, bir reklam şirketinden kendi tarayıcısına reklam engelleyici koymasını istemek gibi
    • Sorun şu ki botlar durmadan yeni GitHub hesapları açıp spam göndermeye devam edebilir. Yine de başlangıç için fena olmayan basit bir savunma olabilir
    • GitHub ve Microsoft bu soruna aktif olarak katkıda bulunuyor; neden kendi hatalarını kabul etsinler ki?

  • Bunun gibi sorunları azaltmak için Elo tabanlı bir puan sistemi işe yarar mı diye merak ediyorum
    Belirli bir projeye PR’ı başarıyla merge edilmiş kişiler, gerçek issue’ları kabul edilmiş kişiler ya da diğer kullanıcıların tepkileriyle yanıt kalitesi ölçülen kişiler puanlanabilir; hatta bunun üzerine, etkinliğin geçtiği projenin önem katsayısı da eklenebilir. Bu, insan ile AI ayrımı değil; gerçekten yararlı ve etkili katkılarla düşük çabalı/spam katkıları ayırmanın bir yolu olabilir. Issue’lar ve PR’lar Elo puanına göre sıralanabilir ya da filtrelenebilir. Burada Elo, bağlama dayalı bir puanın mecazı; gerçek Elo sistemini bire bir kopyalamayı önermiyorum
    Negatif puanlar spam içerik ya da kabul görmemiş issue’ların diğer kullanıcılar tarafından işaretlenmesinden gelebilir; açıkça iyi niyetli ama merge edilmiş PR’a dönüşmeyen, doğru depo için olmayan ya da önce başka uygulama/altyapı gerektiren iyi PR’lar gibi durumlar içinse nötr ya da hafif pozitif puan veren bir ara bölge gerekli görünüyor

    • Elo’yu manipüle etmek şaşırtıcı derecede kolaydır
      Örneğin, hapishanede gerçekten epey iyi satranç oyuncuları vardı ve bunlardan biri, kendisini yenerek yüksek Elo alan bir oyuncu havuzu oluşturdu; sonra da onları kullanarak kendi puanını daha da yükseltti. Bu süreç tekrar tekrar yapılabilir
      Manipüle edilebilen her sistemin yolunu AI bulacaktır. Asıl yazıdaki yaklaşımda da bir AI katkıcı statüsünü kazanırsa diğer AI’ları da katkıcı yapabilir ve aynı sorun yeniden başlar. Bunun için bir amacı olması bile gerekmez. Troller trollük yapar ve AI botu olan troller sonsuz enerji harcayabilir. Onları durdurmaya ne kadar uğraşırsan, onlar için o kadar eğlenceli olur. Keşke bu sorunun bir cevabı olsa ama bilmiyorum
    • Merak edenler için ekleyeyim: Elo bir kısaltma değil, kişinin soyadıdır. Ayrıntılar burada: https://en.wikipedia.org/wiki/Elo_rating_system
    • ELO değil Elo. Elo bir kısaltma değil
      https://en.wikipedia.org/wiki/Elo_rating_system
    • Benzer bir şey yapıyorum ve şu anda veri topluyorum
      Frontier users: 527,865
      Light indexed: 527,865
      Ready to queue: 9,083
      Fast scores ready: 0
      Activity events 24h: 30,266
      Fast scores completed 24h: 19,123
      Deep jobs completed 24h: 3,043
      Fast-score ETA: n/a
      Deep-hydrate ETA: 69h
      Stale running jobs: 0
      GitHub backpressure jobs: 19,113
      High automation signals: 4,608
      Medium automation signals: 1,327
      Completed jobs: 74,714
      En büyük engel GitHub hız limiti. Bu hızla %98 kapsama ulaşmak iki ay daha sürecek gibi görünüyor ama sonrasında bakımın oldukça basit olması gerekir
    • Mitchell Hashimoto’nun Vouch’una biraz benziyor gibi: https://github.com/mitchellh/vouch

  • AI’nin ne kadar iyi kod yazdığını herkese anlata anlata gelinen nokta bu
    Bunu AI satanlar başlattı; tuhaf bir şekilde bağımsız geliştiriciler de, hatta sektörde epey saygı gören bazıları da buna topluca atladı. Facebook’un şimdi insanları işten çıkarırken sebebin AI’nin çok iyi olması olduğunu söylemesi de yangına körükle gidiyor. Artık AI arkadaşının müthiş kod ürettiğine ikna olmuş insanlar var ve bu kodu tamamen yönetilemez hale gelmiş projelere gönderiyorlar

    • Belki de kovboy kodcular, sanal kovboy kız kodcular edinip bunu herkese sattı
      Saygın olup olmamasından bağımsız olarak, tek kişilik geliştiricilerin her zaman kovboylaşmamayı sağlayacak temel yetkinliklere sahip olduğunu sanmıyorum. Bu bazen deneyim eksikliği, bazen de doğuştan gelen yetersizlik olabilir. Ama bu anlatıya da tamamen inanmıyorum; çünkü daha “erken” dönemde güçlü bir tepeden inme itiş vardı

  • .ai alan adı olması ironik

    • Bunu özellikle ironik bulmuyorum. Burada söylenen AI kötü demek değil; kötüye kullanılabileceği demek
    • Keşke site scroll kodunu biraz düzeltsa. O kadar sinir bozucu ki yazıyı okuyamıyorum
    • Bu, “AI’nin projeme çöp dolduracağını bilmiyordum!” diyen, AI çöpü üzerine kurulu bir şirkete benziyor
    • Sadece alan adı da değil. Bu bir agentic stack. Yani bu şirketin ürününü kullanarak, burada yakındıkları türden PR’ları bizzat üretebilirsin

  • Her şeyin çözümü sonunda daha fazla catgirl mü? [1] Proof of work aslında e-posta spam’ine karşı geliştirilmişti ve PR spam’i de bu uzun geleneğin son örneği sadece
    1- https://anubis.techaro.lol

    • Proof of work burada da, e-postada çalışmadığı gibi çalışmaz
      Geçerli bir proof of work üretmenin maliyeti, hangi uygulama olursa olsun, her zaman normal kullanıcıya daha fazla yük bindirir. Spam atmak için teşviki olan kişi ise bunu her zaman daha hızlı ve daha verimli yapabilir
      Dizüstü bilgisayarın çok yavaş olduğu için PR gönderemiyor musun? O zaman birinden hash gücü kiralarsın ve sonuçta GitHub deposuna yazım hatası düzeltmesi gönderebilmek için botnet sahibine para ödenen bir sistem kurmuş olursun. HashCash’in gerçek dünyada kullanılmamasının bir sebebi var. Kulağa sevimli geliyor ama ancak herkesin hile yapmadığı bir vakumu varsayarsan çalışabilecek kadar teşvik yapısı saçma
    • Anubis aslında kedi değil. Orijinal Mısır mitolojisindeki Anubis ölüm tanrısıdır ve köpekgil başına sahiptir. Anime catgirl ile dog girl ilk bakışta benzer görünebilir
    • Anubis’in PR oluşturan ajanlara değil, crawler’ları engellemeye yönelik olduğunu düşünüyorum. Burada proof of work işe yaramaz; ajan hesaplamayı zaten yapar

  • Onboarding belgesinin üslubunda tipik bir AI izi var. Alıntılarda em dash ve “A değil, B” türü cümleler görünüyor
    Ateşi ateşle söndürmeye çalışıyor olabilirler ya da daha önce dendiği gibi vakitleri yoktur, bunu anlıyorum. Yine de genel olarak eksik, yarım kalmış bir tepki gibi hissettiriyor

    • Yazının tamamı açıkça LLM üretimi gibi görünüyor
      Bir insanın düşüncelerini toparlayıp koyduğu belli ama LLM’e “bunu bir blog yazısına dönüştür” demek bana HN’ye uygun olmayan düşük çabalı içerik gibi geliyor. Yine de temel yaklaşım olan “katkıcılara sınırla” fikrinin güvenlik açısından kötü bir fikir olabileceği yönünde bir tartışma üretmiş oldu
    • Kendi projende AI kullanmakla, başkalarının ya da botların gönderdiği AI katkıları altında ezilmek farklı meseleler

  • “E-posta GitHub hesabıyla eşleşirse GitHub commit’i profile bağlar ve katkıcı statüsü verir” kısmını görünce, katkıcının e-posta adresi değişirse bunun bozulup bozulmayacağını merak ettim
    Çünkü yıllar boyunca artık var olmayan e-posta adresleriyle çeşitli projelere katkıda bulundum
    Ama anladığım kadarıyla, yazarın asıl git commit’ine kaydedilmiş e-posta adresi kullanılmıyor; onun yerine GitHub kullanıcı kimliği ve kullanıcı adını benzersiz kısım olarak içeren GitHub tarafından üretilmiş bir adres kullanılıyor gibi. Böyleyse yazar e-posta adresini değiştirse bile bu korunabilir. Yine de katkıcı hesap erişimini kaybedip yeni bir hesap açmak zorunda kalırsa bozulabilir ama bu muhtemelen daha nadirdir

  • “Adaylara eğlenceli test ödevleri vermeyi bırakmalı mıyız?” sorusunun cevabı evet

    • Bu şirket, ödevi tamamlayana ödeme yapıyor gibi görünüyor; o yüzden o kadar da kötü olmayabilir
    • Geliştiriciler: whiteboard mülakatları gerçek işle ilgili şeyleri ölçmüyor, bırakın bunu
      Yine geliştiriciler: insanlara gerçek sorun çözdürmeyin
    • En başta kimin için eğlenceli olduğu bile belli değil