Comment le flag `--author` de Git a permis de bloquer le spam des bots IA dans un dépôt GitHub

 (archestra.ai)
2 points par GN⁺ 10 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le dépôt Archestra a vu affluer des commentaires et PR sans intérêt à mesure que les contributions assistées par IA augmentaient, ce qui a noyé les vraies discussions et alourdi la charge de maintenance
  • Une issue avec une prime de 900 $ était un espace d’échange pour de vrais contributeurs, mais les commentaires de bots IA l’ont fait grimper jusqu’à 253 commentaires, avec parfois une attitude agressive
  • L’issue de prise en charge du provider x.ai a reçu 27 PR fermées et non fusionnées, et la plupart n’avaient même pas été testées par leurs auteurs
  • La restriction prior contributor de GitHub ne permettait pas de distinguer les vrais nouveaux développeurs des bots IA, ce qui a conduit l’équipe à ajouter les utilisateurs approuvés comme auteurs de commits sur main via Git --author
  • L’onboarding repose désormais sur des règles d’usage éthique de l’IA et un CAPTCHA, puis sur une GitHub Action qui crée un commit de liste blanche, en donnant la priorité à la qualité plutôt qu’à des métriques d’activité gonflées

Comment le spam des bots IA a envahi un dépôt open source

  • Le dépôt Archestra a constaté que, malgré la croissance des métriques GitHub liées aux contributions assistées par IA, la réalité sur le terrain était une baisse de la qualité des contributions et une charge de maintenance croissante
  • L’issue assortie d’une prime de 900 $ était un espace où de vrais contributeurs proposaient des plans, posaient des questions et tentaient d’avancer sur le travail, mais l’arrivée massive de bots IA a fait monter le total à 253 commentaires
  • Des comptes IA laissaient des plans d’implémentation sans valeur et adoptaient même parfois un ton agressif envers les mainteneurs, polluant ainsi les échanges
  • Les membres de l’équipe qui surveillaient le dépôt recevaient des notifications à chaque commentaire IA, tandis que les échanges de vrais contributeurs comme @ethanwater, @developerfred et @Geetk172 étaient noyés
  • L’issue sur la prise en charge du provider x.ai a reçu 27 pull requests fermées et non fusionnées, dont la plupart n’avaient même pas été testées par leurs auteurs
  • Un membre de l’équipe devait consacrer une demi-journée chaque semaine à trier les PR non testées et les issues hallucinées, faute de quoi le dépôt devenait rapidement un espace peu accueillant pour les vrais contributeurs

Une approche par liste blanche pour contourner les limites de GitHub

  • Les limites des premières réponses

    • Archestra a d’abord créé un petit bot appelé London-Cat pour calculer la réputation des contributeurs
    • London-Cat calculait cette réputation à partir des PR fusionnées et de quelques autres signaux, et aidait à identifier les contributeurs, comme dans cet exemple
    • Cette approche a échoué à bloquer le spam en tant que tel
    • L’AI sheriff développé ensuite a, comme dans cet exemple, fini par fermer aussi certaines vraies PR

  • Bloquer l’activité sans onboarding

    • Les commentaires et propositions IA sans intérêt ont continué, poussant de vrais contributeurs à partir, au point de remettre en question aussi bien l’usage de primes pour attirer des contributions que la pratique consistant à donner des exercices techniques aux candidats au recrutement
    • Archestra a durci sa réponse afin de faire du dépôt un espace confortable et sûr pour les vrais contributeurs, les utilisateurs responsables de l’IA, les débutants comme les ingénieurs expérimentés
    • Les utilisateurs qui n’ont pas suivi l’onboarding ne peuvent désormais plus créer d’issues, ouvrir des PR ni publier de commentaires
    • Pour une startup financée par des VC, les métriques d’activité GitHub sont sensibles, mais Archestra accorde plus d’importance à la qualité qu’à des indicateurs gonflés par de l’AI slop

  • Les limites des paramètres GitHub

    • GitHub ne propose pas de moyen simple pour gérer directement une liste blanche des auteurs de commentaires ou des créateurs de PR dans un dépôt open source
    • Le paramètre « Limit to prior contributors » empêche les utilisateurs n’ayant jamais commité auparavant sur main de commenter sur les issues et PR
    • Ce paramètre ne sait pas distinguer les bots IA des vrais développeurs nouvellement arrivés pour travailler sur une prime, et traite donc les deux comme de simples non-contributeurs existants

  • Une liste blanche via le flag --author

    • GitHub considère comme prior contributor le compte GitHub lié à l’author d’un commit sur la branche main
    • Un commit Git contient deux champs d’identité, author et committer, qui peuvent être différents
    • Le flag --author de Git permet de créer un commit attribué à quelqu’un d’autre ; si l’adresse e-mail correspond au compte GitHub concerné, GitHub rattache le commit à ce profil et lui accorde le statut de contributeur
    • Chaque compte GitHub dispose d’une adresse e-mail noreply au format <id>+<username>@users.noreply.github.com
    • Après récupération de l’ID utilisateur via l’API, il suffit de définir l’auteur du commit avec cette adresse
    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"
    • Une fois ce commit poussé sur main, l’utilisateur externe apparaît comme author et le compte Archestra comme committer ; GitHub considère alors immédiatement cet utilisateur comme prior contributor et lui accorde le droit de commenter

  • Le flux d’onboarding en pratique

    • https://archestra.ai/contributor-onboard - L’onboarding se fait sur le site web avec des règles d’usage éthique de l’IA et un CAPTCHA
    • GitHub Action - Lors de la soumission, l’ID GitHub de l’utilisateur est récupéré, son handle est ajouté au fichier EXTERNAL_CONTRIBUTORS.md, puis un commit dont cet utilisateur est l’auteur est poussé sur main
    • Utilisateur - Il est ajouté à la liste blanche et obtient l’accès au dépôt
    • Tandis que GitHub met en avant une forte croissance des métriques globales, y compris pour l’activité générée par IA, les équipes de projets open source doivent, elles, nettoyer elles-mêmes l’AI slop de leur dépôt et même concevoir des solutions de contournement pour préserver un niveau réel de participation
    • L’AI slop ne se contente pas de démotiver les personnes qui veulent bien contribuer en les reléguant dans le bruit ; il introduit aussi des risques de sécurité, comme dans le repo LiteLLM, où des attaquants ont tenté de susciter des échanges avec des bots IA

À lire aussi

1 commentaires

 
GN⁺ 10 시간 전
Commentaires sur Hacker News

  • Les contributeurs d’un dépôt obtiennent des privilèges plus élevés, notamment la possibilité de contourner l’exigence d’approbation pour l’exécution des PR issues d’un fork, donc cette approche a des implications de sécurité négligées
    La documentation GitHub avertit aussi que, dans les paramètres qui « exigent une approbation uniquement pour les premiers contributeurs », un utilisateur n’a plus besoin d’approbation dès qu’un commit ou une PR lui appartenant a été fusionné au moins une fois dans le dépôt, et qu’un acteur malveillant peut satisfaire cette condition en faisant accepter une modification anodine, comme une simple correction de faute de frappe

    • C’est vrai. Une personne qui ne fait pas partie de l’organisation n’est pas digne de confiance, donc exiger une approbation pour tous les contributeurs externes devrait être le paramètre par défaut
    • Ce n’est pas une implication de sécurité
      Si un dépôt devient fragile simplement parce qu’une PR totalement inoffensive de quelqu’un y a été fusionnée, alors il faut considérer que ce dépôt était déjà dans un état fragile

  • Le vrai problème, c’est que GitHub ait laissé cela être possible. Si des exigences vraiment minimales avaient été imposées à la création de commentaires et de PR, on n’en serait sans doute pas là
    Et comme on peut supprimer des issues, j’aimerais aussi qu’on puisse supprimer les PR

    • Il y a actuellement un travail en cours pour permettre aux administrateurs d’archiver les PR
      L’objectif est de donner aux mainteneurs un meilleur contrôle sur la manière dont ils gèrent les contributions au dépôt. Les PR archivées ne seraient visibles que par les administrateurs, tout en laissant aux mainteneurs l’accès à l’historique des contributeurs pour l’audit ou pour les exigences organisationnelles et de conformité. Je me demande si une telle fonctionnalité serait utile
    • Ce jugement me semble juste. Tout comme ce n’est pas à chacun de « se débrouiller » pour ne pas recevoir de spam par e-mail, ce n’est pas un problème que la communauté open source ou chaque projet individuel devrait devoir résoudre seul
    • Je ne vois pas bien l’avantage de supprimer une PR plutôt que de la fermer. En la fermant, on peut signaler quelles PR ne sont pas acceptées, alors qu’en la supprimant on perd cet avantage

  • Le spam de PR est un gros problème pour les dépôts qui proposent des primes. GitHub devrait peut-être empêcher temporairement de créer des PR aux comptes dont plus de 95 % des PR sont rejetées

    • J’aimerais bien que GitHub mette en place, par exemple, un système de jetons à PR unique
      Si quelqu’un participe à une discussion utile et montre de bonnes idées pour résoudre une issue ou ajouter une fonctionnalité, on pourrait lui donner un premier jeton PR, puis quelques autres si la qualité de ses PR est bonne, jusqu’à éventuellement le faire passer au statut de contributeur pouvant créer librement des PR. Un système similaire pour les issues serait bien aussi, mais je ne vois pas très bien à quoi cela devrait ressembler quand les issues servent de point de départ aux contributions par PR. Cela dit, GitHub/MS veut vendre des abonnements Copilot et des tokens, et les PR générées par des LLM font aussi partie de ce modèle économique, donc ça semble peu probable en pratique
    • GitHub n’a aucune incitation à bloquer l’IA. C’est un peu comme demander à une régie publicitaire d’intégrer un bloqueur de pub à son propre navigateur
    • Le problème, c’est que les bots peuvent créer autant de nouveaux comptes GitHub qu’ils veulent et continuer à spammer. Malgré tout, cela pourrait être une défense simple acceptable comme point de départ
    • GitHub et Microsoft contribuent activement à ce problème, alors pourquoi reconnaîtraient-ils leur propre responsabilité ?

  • Je me demande si un système de score fondé sur Elo pourrait aider à réduire ce type de problème
    L’idée serait d’évaluer les personnes ayant fusionné avec succès des PR sur un projet donné, celles dont les issues ont été reconnues comme réelles, celles dont la qualité des réponses peut être mesurée par les réactions des autres utilisateurs, etc., en pondérant même cela par l’importance du projet où l’activité a eu lieu. Le critère ne serait pas humain contre IA, mais contribution réellement utile et efficace contre contribution de faible effort ou assimilable à du spam. Les issues et les PR pourraient être triées ou filtrées selon ce score Elo. Ici, Elo n’est qu’une métaphore pour un score contextuel, pas une proposition de transposer le système Elo tel quel
    Les scores négatifs viendraient des signalements d’autres utilisateurs sur du contenu assimilable à du spam ou sur des issues non reconnues, et il faudrait sans doute une zone intermédiaire accordant un score neutre ou légèrement positif aux cas de bonne foi évidente qui n’aboutissent pas à une PR fusionnée, aux issues soumises dans le mauvais dépôt, ou encore aux bonnes PR qui nécessitaient un travail préparatoire préalable

    • Elo est étonnamment facile à manipuler
      Par exemple, il y avait réellement en prison un assez bon joueur d’échecs qui a constitué un groupe de joueurs ayant obtenu un Elo élevé en le battant, puis s’en est servi pour faire monter encore son propre score. Il suffit de répéter le procédé
      Tout système manipulable finira par être manipulé par l’IA. Même avec l’approche décrite dans l’article, si une IA obtient le statut de contributeur, elle peut faire monter d’autres IA au même statut, et on retombe dans le même problème. Il n’y a même pas besoin d’objectif rationnel derrière cela. Les trolls trollent, et les trolls qui disposent de bots IA peuvent y consacrer une énergie infinie. Plus on essaie de les arrêter, plus ils y trouvent du plaisir. J’aimerais avoir une réponse à ce problème, mais je ne la connais pas
    • Pour ceux qui s’interrogent sur Elo, précision utile : Elo n’est pas un acronyme, c’est le nom d’une personne. Détails ici : https://en.wikipedia.org/wiki/Elo_rating_system
    • C’est Elo, pas ELO. Elo n’est pas un acronyme
      https://en.wikipedia.org/wiki/Elo_rating_system
    • Je construis quelque chose de similaire et je collecte actuellement des données
      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
      Le plus gros obstacle, c’est la limitation de débit de GitHub. À ce rythme, il faudra encore deux mois pour atteindre 98 % de couverture, mais après cela la maintenance devrait être assez simple
    • Cela rappelle un peu Vouch de Mitchell Hashimoto : https://github.com/mitchellh/vouch

  • Voilà le résultat d’avoir répété à tout le monde à quel point l’IA sait bien écrire du code
    Ce sont les vendeurs d’IA qui ont lancé ça, et, étrangement, beaucoup de développeurs indépendants ont suivi le mouvement, y compris certains très respectés dans l’industrie. Le fait que Facebook licencie maintenant des gens en disant que c’est parce que l’IA est tellement performante ne fait qu’ajouter de l’huile sur le feu. Résultat, certaines personnes sont persuadées que leur ami IA produit un code extraordinaire et le soumettent à des projets déjà complètement débordés

    • Les cowboy coders ont peut-être simplement obtenu des codeuses cow-girls virtuelles et se sont mis à en vendre à tout le monde
      Qu’un développeur solo soit respecté ou non ne signifie pas qu’il possède forcément toutes les compétences indispensables pour ne pas agir en cowboy. Cela peut venir d’un manque d’expérience ou simplement d’un manque d’aptitudes naturelles. Cela dit, je n’adhère pas entièrement à ce récit, parce qu’il y a eu dès le « début » une forte impulsion descendante

  • Le fait que ce soit un domaine .ai est ironique

    • Je ne trouve pas ça particulièrement ironique. Le propos n’est pas que l’IA est mauvaise, mais qu’elle peut être mal utilisée
    • J’aimerais que le site corrige un peu son code de défilement. C’est tellement agaçant que je n’arrive pas à lire l’article
    • C’est un peu comme si une entreprise fondée sur des déchets IA disait : « Je ne savais pas que l’IA allait transformer mon projet en décharge ! »
    • Ce n’est pas seulement le domaine. C’est aussi une stack orientée agents. Autrement dit, on peut utiliser les produits de cette société pour générer exactement le type de PR dont elle se plaint ici

  • La solution à tout serait-elle finalement davantage de catgirls ? [1] La preuve de travail a été conçue à l’origine pour lutter contre le spam par e-mail, et le spam de PR n’est que le dernier cas d’une longue tradition
    1- https://anubis.techaro.lol

    • La preuve de travail ne marche pas ici, pas plus qu’elle n’a marché pour l’e-mail
      L’effort nécessaire pour produire une preuve de travail valide finit toujours, quelle que soit l’implémentation, par pénaliser les utilisateurs légitimes. Ceux qui ont intérêt à envoyer du spam pourront toujours le faire plus vite et plus efficacement
      Votre laptop est trop lent pour soumettre une PR ? Il suffit de louer de la puissance de hachage à quelqu’un, et vous avez alors créé un système où l’on paie un propriétaire de botnet pour publier une correction de typo sur un dépôt GitHub. Si HashCash n’a pas été utilisé dans le monde réel, ce n’est pas pour rien. C’est mignon en théorie, mais les incitations sont tellement absurdes que cela ne fonctionne qu’en supposant un vide idéal où personne ne triche
    • Anubis n’est pas vraiment un chat. Dans la mythologie égyptienne d’origine, Anubis est un dieu de la mort avec une tête de canidé. Les catgirls et dog girls d’anime peuvent sembler proches au premier regard
    • Anubis me semble destiné à bloquer les crawlers, pas les agents qui créent des PR. Ici, la preuve de travail ne fonctionnera pas : les agents feront simplement le calcul

  • Le style des documents d’onboarding laisse voir les marques habituelles de l’IA. On repère aussi dans les citations des tirets cadratins et des tournures du type « ce n’est pas A, c’est B »
    Je comprends qu’il puisse s’agir de combattre le feu par le feu, ou tout simplement, comme cela a déjà été dit, d’un manque de temps. Mais dans l’ensemble, cela donne quand même l’impression d’une réponse incomplète et un peu bancale

    • L’ensemble du billet semble clairement généré par LLM
      On voit bien qu’une personne a structuré les idées, mais demander à un LLM de « transformer ça en article de blog » me paraît être du contenu à faible effort qui n’a pas sa place sur HN. Cela dit, cela a au moins lancé une discussion sur le fait que l’approche de base, consistant à « restreindre aux contributeurs », pouvait être une mauvaise idée du point de vue de la sécurité
    • Utiliser l’IA sur son propre projet et être submergé par des contributions IA envoyées par d’autres personnes ou par des bots, ce sont deux problèmes différents

  • En lisant la phrase « si l’e-mail correspond au compte GitHub, GitHub rattache le commit au profil et accorde le statut de contributeur », je me suis demandé si cela ne casserait pas lorsque l’adresse e-mail du contributeur change
    J’ai contribué pendant des années à plusieurs projets avec des adresses e-mail qui n’existent plus aujourd’hui
    Mais en réalité, il semble qu’on n’utilise pas l’adresse e-mail figurant dans les commits git d’origine de l’auteur, mais une adresse générée par GitHub dont la partie unique contient l’ID et le nom d’utilisateur GitHub. Dans ce cas, cela pourrait continuer à fonctionner même si l’auteur change d’adresse e-mail. Cela pourrait en revanche casser si le contributeur perd l’accès à son compte et doit en recréer un autre, mais ce cas est probablement moins fréquent

  • À la question « faut-il arrêter de donner des exercices de test amusants aux candidats ? », la réponse est oui

    • Cette entreprise semble payer lorsque l’exercice est terminé, donc ce n’est peut-être pas si mal
    • Développeurs : les entretiens au tableau blanc ne mesurent pas des choses liées au travail réel, il faut arrêter
      Aussi les développeurs : ne nous faites pas résoudre de vrais problèmes
    • Je ne sais même pas pour qui c’est censé être amusant