Wie mit dem Git-Flag `--author` AI-Bot-Spam in GitHub-Repositories gestoppt wurde

 (archestra.ai)
2 Punkte von GN⁺ 10 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das Archestra-Repository wurde mit der Zunahme von AI-basierten Beiträgen von sinnlosen Kommentaren und PRs überflutet, wodurch echte Diskussionen untergingen und der Wartungsaufwand stieg
  • Das $900-Bounty-Issue war eigentlich ein Raum für Diskussionen echter Beitragender, wuchs durch Kommentare von AI-Bots aber auf 253 Kommentare an, teils mit aggressivem Verhalten
  • Zum Issue für x.ai-Provider-Support gingen 27 PRs ein, die geschlossen und nicht gemergt wurden; die meisten Beitragenden hatten sie nicht getestet
  • Die GitHub-Beschränkung prior contributor kann neue echte Entwickler nicht von AI-Bots unterscheiden, daher wurden freigegebene Nutzer per Git --author als Autor von Commits auf main hinzugefügt
  • Das Onboarding erstellt nach Regeln für ethische AI und CAPTCHA per GitHub Action einen Whitelist-Commit und priorisiert Qualität vor aufgeblähten Aktivitätsmetriken

Wie AI-Bot-Spam Open-Source-Repositories vereinnahmte

  • Im Archestra-Repository nahm entgegen GitHubs Wachstumszahlen für AI-basierte Beitragsmetriken in der Praxis die Qualität der Beiträge ab, während der Wartungsaufwand stieg
  • Das mit $900 Bounty versehene Issue war ursprünglich ein Ort, an dem echte Beitragende Pläne vorschlugen, Fragen stellten und Arbeit ausprobierten, wurde aber durch den Ansturm von AI-Bots auf insgesamt 253 Kommentare aufgebläht
  • AI-Konten hinterließen sinnlose Umsetzungspläne und zeigten gegenüber Maintainern sogar aggressives Verhalten, wodurch die Diskussion verunreinigt wurde
  • Teammitglieder, die das Repository beobachteten, erhielten Benachrichtigungen zu jedem AI-Kommentar, während Gespräche echter Beitragender wie @ethanwater, @developerfred und @Geetk172 untergingen
  • Zum Issue für x.ai-Provider-Support gingen 27 Pull Requests ein, die geschlossen und nicht gemergt wurden; die meisten waren von den Beitragenden nicht einmal getestet worden
  • Ein Teammitglied musste jede Woche einen halben Tag dafür aufwenden, ungetestete PRs und halluzinierte Issues aufzuräumen; ohne diese Pflege wäre das Repository schnell zu einem unfreundlichen Ort für echte Beitragende geworden

Die Whitelist-Methode als Umgehung der GitHub-Beschränkungen

  • Grenzen der ersten Reaktion

    • Archestra baute zunächst einen kleinen Bot namens London-Cat, um den Ruf von Beitragenden zu berechnen
    • London-Cat berechnete den Ruf von Beitragenden anhand gemergter PRs und einiger Signale und half wie im Beispiel bei der Identifizierung von Beitragenden
    • Dieser Ansatz scheiterte jedoch bereits an der Spam-Abwehr selbst
    • Der im nächsten Schritt gebaute AI sheriff schloss wie im Beispiel sogar einige echte PRs

  • Aktivitäten ohne Onboarding blockieren

    • Da sinnlose AI-Kommentare und Vorschläge weiter zunahmen, wanderten echte Beitragende ab, und sogar die Praxis, Beiträge über Bounties anzuregen oder Bewerbern Testaufgaben zu geben, wurde neu überdacht
    • Archestra verschärfte die Maßnahmen, um ein Repository zu schaffen, das für echte Beitragende, verantwortungsvolle AI-Nutzer, Einsteiger und erfahrene Engineers gleichermaßen angenehm und sicher ist
    • Nutzer ohne durchlaufenes Onboarding dürfen nun keine Issues erstellen, PRs öffnen oder Kommentare schreiben
    • Für VC-finanzierte Startups sind GitHub-Aktivitätsmetriken zwar sensibel, Archestra bewertet jedoch Qualität höher als durch AI slop aufgeblähte Kennzahlen

  • Grenzen der GitHub-Einstellungen

    • GitHub bietet keine einfache Möglichkeit, in Open-Source-Repositories Verfasser von Kommentaren oder PR-Ersteller direkt per Whitelist zu verwalten
    • Die Einstellung “Limit to prior contributors” verhindert Kommentare zu Issues und PRs von Nutzern, die noch nie zuvor auf main committet haben
    • Diese Einstellung kann AI-Bots nicht von echten neuen Entwicklern unterscheiden, die für Bounty-Arbeit dazukommen; beide werden als Nutzer ohne bisherigen Beitrag behandelt

  • Whitelist mit dem Flag --author

    • GitHub bewertet GitHub-Konten, die als author eines Commits auf dem Branch main verknüpft sind, als prior contributor
    • Ein Git-Commit hat die beiden Identitätsfelder author und committer, und diese Werte können unterschiedlich sein
    • Mit dem Git-Flag --author kann ein Commit erstellt werden, der einer anderen Person zugeschrieben ist; wenn die E-Mail mit dem GitHub-Konto übereinstimmt, verknüpft GitHub den Commit mit diesem Profil und verleiht den Status als Beitragender
    • Jedes GitHub-Konto hat eine noreply-E-Mail im Format <id>+<username>@users.noreply.github.com
    • Nach dem Abruf der Benutzer-ID per API wird der Commit-Autor mit diesem E-Mail-Format gesetzt
    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"
    • Wird dieser Commit nach main gepusht, erscheint der externe Nutzer als author, das Archestra-Konto als committer, und GitHub behandelt diesen Nutzer sofort als prior contributor und gewährt Kommentierrechte

  • Der tatsächliche Onboarding-Ablauf

    • https://archestra.ai/contributor-onboard - Auf der Website wird ein Onboarding mit Regeln für ethische AI und CAPTCHA durchgeführt
    • GitHub Action - Beim Absenden wird die GitHub-ID des Nutzers abgefragt, der Handle in die Datei EXTERNAL_CONTRIBUTORS.md eingetragen und ein Commit, bei dem das Konto dieses Nutzers der Author ist, nach main gepusht
    • Nutzer - Wird auf die Whitelist gesetzt und erhält Zugriffsrechte auf das Repository
    • Während GitHub weiterhin starkes Metrikwachstum meldet, einschließlich AI-generierter Aktivität, müssen Open-Source-Projektteams AI slop in ihren Repositories selbst wegräumen und sogar Umgehungslösungen bauen, um ein Niveau echter Beteiligung aufrechtzuerhalten
    • AI slop drängt Menschen, die gute Beiträge leisten wollen, in den Lärm und demotiviert sie nicht nur, sondern bringt auch Sicherheitsrisiken mit sich, wie im LiteLLM repo, wo Angreifer versuchten, Gespräche über AI-Bots anzustoßen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 10 시간 전
Hacker-News-Kommentare

  • Mitwirkende an einem Repository erhalten höhere Berechtigungen, etwa indem sie die Pflicht zur Genehmigung für das Ausführen von Fork-PRs umgehen können, daher hat dieser Ansatz übersehene Sicherheitsauswirkungen
    Auch die GitHub-Dokumentation warnt davor, dass bei einer Einstellung wie „Genehmigung nur für Erstbeitragende erforderlich“ Nutzer, deren Commit oder PR auch nur einmal in ein Repository gemergt wurde, keine Genehmigung mehr benötigen und ein böswilliger Nutzer diese Bedingung erfüllen kann, indem er eine harmlose Änderung wie die Korrektur eines Tippfehlers akzeptieren lässt

    • Stimmt. Wer nicht zur Organisation gehört, ist nicht vertrauenswürdig, daher sollte Genehmigung für alle externen Mitwirkenden erforderlich der Standard sein
    • Das ist keine Sicherheitsauswirkung
      Wenn ein Repository instabil wird, nur weil ein völlig harmloser PR von jemandem hineingemergt wurde, dann war dieses Repository bereits vorher instabil

  • Das Problem ist, dass GitHub so etwas überhaupt ermöglicht. Hätte man schon beim Kommentieren und Erstellen von PRs nur sehr grundlegende Anforderungen eingeführt, wäre es nicht so weit gekommen
    Und ich wünschte, man könnte PRs auch löschen, so wie man Issues löschen kann

    • Derzeit wird an einer Funktion gearbeitet, mit der Admins PRs archivieren können
      Ziel ist, Maintainern mehr Kontrolle darüber zu geben, wie sie Beiträge zum Repository verwalten. Archivierte PRs sind nur für Admins sichtbar, und die Aufzeichnungen über Beitragende sollen für Audits oder organisatorische bzw. Compliance-Anforderungen weiter zugänglich bleiben. Mich würde interessieren, ob so eine Funktion hilfreich wäre
    • Diese Einschätzung ist richtig. Genauso wie es nicht Sache einzelner Personen ist, „selbst herauszufinden“, wie sie keine Spam-Mails bekommen, ist das kein Problem, das die Open-Source-Community oder einzelne Projekte selbst lösen sollten
    • Ich verstehe nicht, was der Vorteil wäre, einen PR zu löschen statt ihn zu schließen. Wenn man ihn schließt, signalisiert das, welche PRs nicht akzeptiert werden; beim Löschen fällt dieser Vorteil weg

  • PR-Spam ist ein großes Problem für Repositories, die Bounties anbieten. Vielleicht sollte GitHub Accounts, bei denen mehr als 95 % der PRs abgelehnt werden, vorübergehend daran hindern, PRs zu erstellen

    • Es wäre gut, wenn GitHub zum Beispiel ein System für Ein-PR-Tokens hätte
      Wenn jemand an einer sinnvollen Diskussion teilnimmt und gute Ideen zur Lösung eines Issues oder Features zeigt, gibt man ihm zunächst ein PR-Token; ist die Qualität des PR gut, gibt man ein paar weitere, und am Ende wird die Person zu einem Mitwirkenden hochgestuft, der frei PRs erstellen kann. Für Issues wäre ein ähnliches System ebenfalls gut, aber wenn Issues der Ausgangspunkt für PR-Beiträge sind, ist unklar, wie das aussehen sollte. GitHub/MS will aber vermutlich lieber Copilot-Abos und Tokens verkaufen, und LLM-generierte PRs sind Teil dieses Geschäftsmodells, daher scheint es unwahrscheinlich, dass so etwas wirklich kommt
    • GitHub hat keinen Anreiz, AI zu blockieren. Das ist ungefähr so, als würde man von einer Werbefirma verlangen, in ihren eigenen Browser einen Werbeblocker einzubauen
    • Das Problem ist, dass Bots beliebig neue GitHub-Accounts anlegen und weiter spammen können. Trotzdem könnte das als einfacher erster Schutz brauchbar sein
    • GitHub und Microsoft tragen aktiv zu diesem Problem bei; warum sollten sie also ihr eigenes Fehlverhalten eingestehen?

  • Ich frage mich, ob ein Elo-basiertes Bewertungssystem helfen würde, solche Probleme zu verringern
    Man könnte Personen danach bewerten, ob sie in bestimmten Projekten erfolgreich PRs gemergt haben, ob ihre Issues tatsächlich anerkannt wurden, ob die Qualität ihrer Antworten durch Reaktionen anderer Nutzer messbar ist, und das Ganze noch mit der Bedeutung der Projekte gewichten, in denen diese Aktivität stattfand. Das wäre kein Kriterium Mensch gegen AI, sondern eines zur Unterscheidung zwischen tatsächlich hilfreichen, effektiven Beiträgen und Low-Effort- bzw. Spam-Beiträgen. Issues und PRs könnten nach Elo-Werten sortiert oder gefiltert werden. Elo ist hier nur als Metapher für eine kontextbasierte Bewertung gemeint, nicht als Vorschlag, das tatsächliche Elo-System 1:1 zu übernehmen
    Negative Punkte könnten aus Meldungen anderer Nutzer über Spam-Inhalte oder nicht anerkannte Issues entstehen, und für den Zwischenbereich bräuchte es wohl neutrale oder leicht positive Werte, etwa für klar gut gemeinte Beiträge, die nicht bis zu einem gemergten PR kamen, für Issues im falschen Repository oder für gute PRs, die von einer Vorabimplementierung abhingen

    • Elo lässt sich erstaunlich leicht manipulieren
      Es gab zum Beispiel tatsächlich einen ziemlich guten Schachspieler im Gefängnis, der sich einen Pool von Spielern schuf, die hohe Elo-Werte bekamen, indem sie ihn besiegten, und diese dann nutzte, um seinen eigenen Wert weiter nach oben zu treiben. Diesen Vorgang kann man einfach wiederholen
      Jedes manipulierbare System wird von AI auch manipuliert werden. Selbst beim Ansatz des Originalartikels könnte eine einzige AI, sobald sie Mitwirkendenstatus erlangt hat, weitere AIs zu Mitwirkenden hochziehen, und dann beginnt dasselbe Problem von vorn. Dafür braucht es nicht einmal einen Zweck. Trolle trollen, und Trolle mit AI-Bots können unendlich Energie hineinstecken. Je mehr man versucht, sie aufzuhalten, desto mehr Spaß macht es ihnen. Ich wünschte, ich hätte eine Antwort auf dieses Problem, aber ich kenne keine
    • Für alle, die sich wegen Elo wundern: Elo ist kein Akronym, sondern ein Nachname. Mehr dazu hier: https://en.wikipedia.org/wiki/Elo_rating_system
    • Es heißt Elo, nicht ELO. Elo ist kein Akronym
      https://en.wikipedia.org/wiki/Elo_rating_system
    • Ich baue gerade etwas Ähnliches und sammle aktuell Daten
      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
      Das größte Hindernis sind die GitHub-Rate-Limits. Mit diesem Tempo wird es noch zwei Monate bis zu 98 % Abdeckung dauern, aber danach dürfte die Pflege recht einfach sein
    • Klingt ein wenig ähnlich wie Vouch von Mitchell Hashimoto: https://github.com/mitchellh/vouch

  • Das ist das Ergebnis davon, dass allen eingeredet wurde, wie gut AI Code schreiben könne
    Die Leute, die AI verkaufen, haben damit angefangen, und seltsamerweise sind auch unabhängige Entwickler, darunter viele in der Branche durchaus respektierte Personen, massenhaft darauf aufgesprungen. Dass Facebook jetzt Leute entlässt und behauptet, AI sei so gut, gießt zusätzlich Öl ins Feuer. Jetzt gibt es Menschen, die überzeugt sind, ihr AI-Freund produziere großartigen Code, und sie reichen diesen Code in Projekten ein, die ohnehin schon völlig unüberschaubar geworden sind

    • Vielleicht haben Cowboy-Coder virtuelle Cowgirl-Coder bekommen und sie an alle verkauft
      Unabhängig davon, ob jemand respektiert ist oder nicht, heißt Ein-Personen-Entwicklung nicht automatisch, dass jemand immer die nötigen Kernkompetenzen besitzt, kein Cowboy zu sein. Das kann an mangelnder Erfahrung liegen oder an fehlender natürlicher Eignung. Ganz glaube ich diese Erzählung aber nicht, denn schon „früh“ gab es starken Druck von oben

  • Es ist ironisch, dass es eine .ai-Domain ist

    • Ich finde das nicht besonders ironisch. Es geht nicht darum zu sagen, AI sei schlecht, sondern darum, dass sie missbraucht werden kann
    • Ich wünschte, die Website würde ihren Scroll-Code etwas reparieren. So nervt sie mich, dass ich den Artikel nicht lesen kann
    • Das ist wie eine Firma, die auf AI-Müll basiert und sagt: „Ich hätte nie gedacht, dass AI mein Projekt zumüllt!“
    • Nicht nur die Domain. Das ist ein agentischer Stack. Mit anderen Worten: Man kann die Produkte dieser Firma benutzen, um genau die Art von PRs zu erzeugen, über die sie sich hier beklagt

  • Ist die Lösung für alles am Ende mehr catgirls? [1] Proof of Work sollte ursprünglich E-Mail-Spam bekämpfen, und PR-Spam ist nur das neueste Beispiel in dieser langen Tradition
    1- https://anubis.techaro.lol

    • Proof of Work funktioniert hier genauso wenig wie damals bei E-Mail
      Der Aufwand, einen gültigen Proof of Work zu erzeugen, benachteiligt in jeder denkbaren Implementierung immer legitime Nutzer. Wer einen Anreiz zum Spammen hat, kann das immer schneller und effizienter tun
      Ist dein Laptop zu langsam, um einen PR einzureichen? Dann mietest du dir eben Hash-Power, und damit hätte man ein System geschaffen, in dem man Botnet-Besitzern Geld zahlt, um Tippfehlerkorrekturen in GitHub-Repositories einzureichen. Es gibt einen Grund, warum HashCash sich in der Praxis nicht durchgesetzt hat. Es klingt niedlich, funktioniert aber nur, wenn man einen luftleeren Raum annimmt, in dem niemand betrügt; die Anreize sind einfach absurd
    • Anubis ist eigentlich keine Katze. In der ägyptischen Mythologie war Anubis der Gott des Todes und hatte den Kopf eines hundeartigen Tiers. Anime-catgirls und dog girls können auf den ersten Blick ähnlich aussehen
    • Ich verstehe Anubis eher als etwas zum Blockieren von Crawlern, nicht von Agenten, die PRs erstellen. Hier funktioniert Proof of Work nicht; der Agent rechnet es einfach aus

  • Der Stil der Onboarding-Dokumentation hat den typischen AI-Tonfall. Auch in den Zitaten sieht man em dashes und Formulierungen der Art „nicht A, sondern B“
    Ich verstehe, dass das ein Versuch sein könnte, Feuer mit Feuer zu bekämpfen, oder dass man, wie schon gesagt wurde, vielleicht einfach keine Zeit hatte. Trotzdem wirkt das insgesamt wie eine unzureichende halbgare Reaktion

    • Der gesamte Beitrag wirkt klar LLM-generiert
      Man merkt, dass jemand Gedanken hineingesteckt hat, aber ein LLM zu bitten, „mach daraus einen Blogpost“, erschien mir immer als Low-Effort-Content, der nicht zu HN passt. Immerhin hat es eine Diskussion darüber ausgelöst, dass der Grundansatz „auf Mitwirkende beschränken“ aus Sicherheitssicht eine schlechte Idee sein könnte
    • AI im eigenen Projekt zu nutzen und von AI-Beiträgen anderer Menschen oder Bots überrollt zu werden, sind zwei verschiedene Probleme

  • Als ich las: „Wenn die E-Mail-Adresse mit dem GitHub-Account übereinstimmt, verknüpft GitHub den Commit mit dem Profil und verleiht Mitwirkendenstatus“, dachte ich sofort: Bricht das nicht, wenn sich die E-Mail-Adresse des Beitragenden ändert?
    Ich habe über die Jahre zu mehreren Projekten mit E-Mail-Adressen beigetragen, die inzwischen nicht mehr existieren
    Tatsächlich scheint aber nicht die in den ursprünglichen Git-Commits des Autors verzeichnete E-Mail-Adresse verwendet zu werden, sondern eine von GitHub erzeugte Adresse, deren eindeutiger Teil die GitHub-Benutzer-ID und den Benutzernamen enthält. Dann könnte es auch dann bestehen bleiben, wenn der Autor seine E-Mail-Adresse ändert. Es könnte allerdings brechen, wenn ein Beitragender den Zugriff auf sein Konto verliert und ein neues Konto anlegen muss, aber das dürfte wohl seltener sein

  • Auf die Frage „Sollten wir aufhören, Bewerbern lustige Testaufgaben zu geben?“ lautet die Antwort: ja

    • Dieses Unternehmen scheint für die Bearbeitung dieser Aufgabe zu bezahlen, also ist es vielleicht nicht ganz so schlimm
    • Entwickler: Whiteboard-Interviews messen nichts, was mit der tatsächlichen Arbeit zu tun hat, also hört auf damit
      Ebenfalls Entwickler: Lasst uns keine echten Probleme lösen
    • Ich frage mich ohnehin, für wen das überhaupt lustig sein soll