Vouch - système de gestion de la confiance pour les contributeurs open source

• L’open source a traditionnellement fonctionné sur un modèle de trust and verify
• Avec la généralisation des outils d’IA, la barrière d’entrée à la contribution a pratiquement disparu, et l’ancien modèle de confiance implicite ne fonctionne plus
• Système de gestion de la confiance pour l’open source conçu pour ne permettre la participation qu’après une garantie explicite de confiance (vouch) avant toute contribution
• Les contributeurs de confiance peuvent vouch pour d’autres utilisateurs, et les acteurs malveillants peuvent être explicitement bloqués via denounce
  • denounce est conservé comme un registre public, que d’autres projets peuvent consulter
  • Qui peut vouch/denounce, et selon quels critères, est laissé à la décision de chaque projet
  • Le système n’impose aucune vision particulière, et les décisions de politique relèvent de la communauté
• Toutes les données de confiance sont versionnées avec le code dans un fichier texte unique (VOUCHED) au sein du dépôt, garantissant transparence et portabilité
• À long terme, la structure vise le partage d’informations de confiance entre projets via une Web of Trust
  • Le choix d’accepter tel quel le jugement d’un projet amont revient au projet aval
  • Les projets qui multiplient les vouch/denounce de manière inconsidérée peuvent être naturellement exclus du réseau de confiance
• Intégration simple avec GitHub Actions, avec une gestion possible depuis les commentaires d’issue ou de PR via des mots-clés comme lgtm et denounce
• Ghostty a basculé son modèle de contribution vers un système fondé sur le vouch
• Implémenté en s’inspirant du projet Pi, actuellement au stade expérimental

Commandes fournies

• Fichiers locaux
  • vouch.nu check <user>: vérifier l’état de vouch/denounce d’un utilisateur
  • vouch.nu add <user>: vouch pour un utilisateur
  • vouch.nu denounce <user>: denounce un utilisateur
• Intégration GitHub
  • vouch.nu gh-check-pr <pr>: vérifier l’état de l’auteur de la PR et traiter automatiquement
  • vouch.nu gh-manage-by-issue <issue> <comment>: vouch/denounce à partir d’un commentaire d’issue

[kuthia]

J’ai l’impression que le système lui-même devra gagner en autorité pour être accepté.

[xguru]

Comme le sujet suscite de l’intérêt tout en semblant prêter à confusion, une FAQ distincte a été préparée. https://x.com/mitchellh/status/2020628046009831542

• Les débutants et les nouveaux participants ont du mal à contribuer
  • Il n’y a absolument aucune raison pour qu’il soit difficile d’obtenir un vouch
  • L’objectif principal de Vouch est d’empêcher les participations irréfléchies et sans effort
  • Dans mes projets, y compris celui-ci, il suffit de se présenter dans une issue et d’expliquer brièvement comment on souhaite contribuer pour obtenir un vouch
  • En bref, comme dans la vie sociale ordinaire, se présenter suffit pour obtenir un vouch
  • En revanche, si quelqu’un abuse de ses droits au sein du groupe, il sera sanctionné
• C’est vulnérable à l’ingénierie sociale
  • Un utilisateur ayant reçu un vouch n’obtient que le droit de participer au projet
  • Il n’obtient pas les droits de fusionner des pull requests, de pousser du code ou de faire des releases
  • Toutes ces actions restent limitées par les processus de revue existants et les contrôles du système
  • De plus, seuls les administrateurs et les collaborateurs peuvent recommander des utilisateurs
  • Donc, même si un utilisateur problématique reçoit une recommandation, il ne peut pas en recommander d’autres
• Il n’existe pas de procédure d’appel pour une dénonciation.
  • La procédure d’appel dépend de chaque sous-projet
  • Dans mes projets, il suffit de nous contacter, via Discord, e-mail ou tout autre moyen, de parler avec nous comme une personne et de reconnaître son erreur pour avoir une nouvelle chance. Ce n’est pas compliqué
• L’idée centrale de ce projet est de minimiser les barrières naturelles existantes en permettant à l’IA de fournir des informations aux gens via des appels d’API
• Dans un projet communautaire centré sur l’humain, une interaction humaine n’est nécessaire qu’aux frontières

[GN⁺]

Avis sur Hacker News

• Je pense qu’il est dangereux de supposer qu’un utilisateur de confiance dans un projet devient automatiquement digne de confiance dans un autre. Ce type de structure peut être exploité pour des attaques sur la chaîne d’approvisionnement. Un attaquant peut gagner la confiance comme « bon contributeur » dans plusieurs projets, puis s’approcher du projet ciblé. Si cette confiance croisée est automatisée, tout compte ayant déjà obtenu la confiance peut devenir une cible. Il vaudrait mieux partir d’une liste de méfiance plutôt que d’une « liste de confiance ».

  • À en juger par la description, l’objectif de ce système semble moins relever de la sécurité au sens strict que d’un filtre anti-spam destiné à bloquer des contributions de mauvaise qualité générées par l’IA.
  • Cette inquiétude est un peu exagérée. Vouch n’est qu’une barrière limitant le droit de participation, pas un mécanisme qui donne le droit de fusionner du code. Ensuite, la procédure de revue existante reste inchangée. Au final, il faut plutôt y voir une couche de réduction du bruit.
  • Qu’un attaquant fasse semblant d’être irréprochable pendant longtemps pour se construire une réputation, c’est déjà une réalité. En général, les gens finissent par remarquer quand il change. C’est une situation du genre xkcd 810.
  • Si quelqu’un perd la confiance, elle disparaît aussi dans tous les projets qui lui faisaient confiance. C’est un concept proche d’un filtre anti-spam, pas d’un niveau de confiance comparable à une signature de clé PGP. Le but n’est pas d’arrêter un attaquant étatique, mais de bloquer les PR spam générées par l’IA.
  • Ce n’est pas un système parfait, mais je pense que c’est une « amélioration qui vaut bien cet inconvénient ». Pour un vrai contributeur, un petit effort supplémentaire en vaut la peine. Moi aussi, je serais prêt à l’accepter.

• Je pense qu’il serait bien d’imposer un coût de 1 $ pour soumettre une PR. Si la PR est valable, le mainteneur rembourse. Aujourd’hui, communiquer est devenu trop facile, donc la communication de basse qualité déborde. Ce n’est pas seulement sans valeur, c’est un préjudice qui grignote le temps.

  • Ce type de raisonnement mène finalement au concept de staking du monde crypto. On bloque des tokens, puis on les récupère si la PR est fusionnée. C’est élégant techniquement, mais dès que l’argent entre en jeu, la conception du produit se corrompt. Il ne faut surtout pas faire ça.
  • « Si tu veux lire mon commentaire, paie 1 $ » : c’est une blague, mais elle révèle bien l’essence de l’idée.
  • Faire payer la communication a aussi des effets négatifs. L’important, c’est le bon équilibre du coût. Une « discussion de mauvaise qualité » avec des proches, ce n’est pas grave, mais j’aimerais bien qu’il y ait moins de communication Twitter de la part des politiques.
  • Au fond, c’est un problème d’externalisation des coûts. On le retrouve dans la fabrication, la communication, la génération de code, partout. Aujourd’hui, même la réputation personnelle ne coûte presque plus rien.
  • Avec un tel système, je crois que je n’enverrais tout simplement pas de PR. Beaucoup de PR restent déjà sans réponse ; s’il faut en plus payer, je ferais juste la correction dans un fork. Si rien n’incite au remboursement, c’est encore plus injuste. Même avec un service d’entiercement, ça devient compliqué. Je veux juste corriger un bug, pas subir toute cette procédure.

• Je me demande comment un nouveau contributeur sans réseau pourrait franchir la barrière à l’entrée. Même s’il y a beaucoup de bruit produit par l’IA, ce n’est pas la bonne solution.

  • Dans mon projet OSS, je préfère qu’on propose d’abord quelque chose via une issue ou une discussion plutôt que par PR. Les PR créent souvent des situations où il est difficile de refuser alors que cela ne correspond pas à l’orientation du projet.
  • On peut aussi demander au contributeur d’expliquer son patch en visioconférence. J’ai déjà filtré des candidats frauduleux de cette manière. Aujourd’hui, le FOSS est presque devenu un jeu de détection de fraude.
  • On dirait une structure qui restreint l’accès par étapes. Par exemple, valider d’abord dans un environnement de staging, puis autoriser l’accès à la production. C’est déjà une pratique courante dans le monde ops.
  • Tout dépend de la configuration de Vouch. Certains peuvent tout fermer, d’autres peuvent laisser ouvertes les issues et les discussions tout en limitant seulement les PR. Il suffit d’adapter cela aux pratiques de chaque projet, comme Linux.

• Je ne suis pas d’accord avec l’idée que « l’open source fonctionne sur un système de confiance puis de vérification ». Idéalement, il faudrait pouvoir juger à partir du code lui-même. Quand je regarde une PR, je décide en quelques secondes si elle doit être fusionnée ou non. Le plus difficile, c’est d’écrire poliment les raisons du refus. (Référence : dépôt openpilot)

  • J’ai regardé récemment le code d’openpilot, et la structure de msgq/cereal, Params, visionipc est intéressante.
  • Quand on a le temps, on relit ; quand on ne l’a pas, on fait confiance.

• Je me demande comment le projet Vouch éviterait de devenir une bulle fermée comme Bluesky. Depuis l’élection, Bluesky se contracte progressivement. Ce type de filtrage social peut aussi bloquer de nouvelles contributions.

  • C’est vrai qu’il y a eu une baisse après l’élection, mais il y a toujours plus d’utilisateurs qu’avant. Les statistiques montrent un schéma de pic puis stabilisation. En plus, le but de Vouch est précisément de relever la barrière à l’entrée, donc ils ne semblent sans doute pas trop s’inquiéter de ce problème.
  • Chaque projet peut avoir son propre système de vouch. La communauté peut aussi exprimer son opposition via des issues ou des PR.
  • Il y a aussi le point de vue suivant : « Et si ça créait une bulle à la Bluesky ? » → « C’est peut-être justement l’objectif. »
  • Il est intéressant de noter que les comptes les plus bloqués sur Bluesky sont des comptes officiels du gouvernement. Cela montre un aspect des communautés fermées.

• On ironise sur le fait qu’un tel système ne pourrait évidemment jamais être détourné dans une communauté open source sans aucun drama. Je me demande s’ils partagent carrément une liste noire de développeurs.

• Je pense qu’un système fondé sur la confiance ne peut fonctionner que s’il implique nécessairement du risque. Si je garantis quelqu’un et qu’il cause des problèmes, ma réputation doit aussi en souffrir. À l’inverse, si j’accuse quelqu’un sans fondement alors que c’est une bonne personne, ma réputation doit baisser. Sinon, les garanties seront abusées de manière irresponsable.

  • C’est pour cela qu’il faut être prudent. Mais si je garantis quelqu’un et que cela donne un bon résultat, ma réputation peut aussi en bénéficier. Les relations humaines fonctionnent comme ça. Ce type de structure pourrait peut-être être implémenté comme un graphe de confiance fondé sur la blockchain.
  • Comme quand on recommande quelqu’un en entreprise, on le garantit parce qu’on y gagne aussi si l’on travaille ensemble.
  • Si la personne que j’ai garantie apporte une bonne contribution et que mon score augmente aussi, ce serait motivant.
  • Mais une telle structure risque aussi, comme dans des cas à la Epstein, d’absoudre à tort quelqu’un simplement parce qu’il a beaucoup de connexions. À l’inverse, une personne compétente mais introvertie pourrait être exclue.
  • On peut voir ce type de réseau de confiance comme un problème de parcours de graphe. Via les relations des personnes en qui j’ai confiance avec celles en qui elles ont confiance, on peut calculer une confiance indirecte.

• Ce système me fait penser à une application de rencontre. Il y a trop de candidats surexcités mais inadaptés à filtrer, et on finira probablement par voir apparaître des schémas comme la participation payante, la géolocalisation, la vérification d’identité et la notation sociale. Ces temps-ci, c’est fatigant de voir des gens chercher à gagner de la réputation sur GitHub en multipliant les demandes de contribution sans intérêt.

• J’imagine une structure de forge minimale qui ne garderait que ce que Git ne sait pas faire nativement. Le cœur, c’est l’identité (Identity), les attestations signées (Attestation) et la politique (Policy). Parmi ces éléments, Vouch traite des signatures sur les personnes — une signature disant « cette personne est digne de confiance » est structurellement identique à une signature disant « ce commit a passé les tests ». Autrement dit, c’est une couche de politique qui contrôle la participation elle-même. Ce type de fonctionnalité devrait exister comme métadonnées dans le dépôt plutôt que sur une plateforme fermée comme GitHub. Je me demande jusqu’où ce concept évoluera dans cinq ans.

  • Si ces métadonnées étaient stockées sous une forme standardisée, comme le dossier .github/, on pourrait avoir un modèle de confiance indépendant des plateformes. À l’ère où le code généré par les LLM augmente, ce type d’infrastructure de réputation pourrait devenir un élément essentiel d’Internet.

• Au début, ça paraissait correct, mais j’ai l’impression qu’au final on retombe sur une structure où seules les personnes de confiance peuvent contribuer.

  • Ce n’est peut-être pas tant l’innovation que une exécution bien conçue qui compte ici, et en ce sens cela a de l’intérêt.
  • Cela ressemble aux anciens killfiles d’Usenet ou aux listes RBL anti-spam. (wiki killfile, DNS blocklist)
  • Ce type de structure convient mieux aux projets de grande taille. Il permet de bloquer par défaut les PR de mauvaise qualité et de réserver l’accès à ceux qui ont construit une relation de confiance avec les mainteneurs principaux.