URL: https://linuxfr.org/users/gouttegd/journaux/gitea-contre-les-bots Title: Gitea contre les bots Authors: gouttegd Date: 2021年02月11日T22:54:22+01:00 License: CC By-SA Tags: gitea Score: 32 ’jour Nal, En tant que développeur de logiciels libres à mes heures perdues, j’ai ma propre instance [Gitea](https://gitea.io/) pour héberger mes dépôts. (J’ai aussi un compte Github, mais je ne l’utilise que pour contribuer à des projets tiers déjà hébergés là-bas, pas pour mes propres dépôts.) Cette instance n’a *pas* vocation à héberger d’autres dépôts que les miens. Je ne suis pas un [CHATON](https://chatons.org/fr/) (comme dirait un procureur américain fâché avec ses filtres Zoom), et n’ai pour l’instant pas l’intention de mettre les ressources de mon petit serveur à disposition d’autres utilisateurs pour héberger leurs dépôts. Pour autant, je ne veux pas empêcher quiconque trouvant un bogue dans un des mes projets[^1] ou ayant une amélioration à suggérer[^2] de créer un rapport de bogue ou une demande de fonctionnalité directement sur Gitea. Mon canal de prédilection pour recevoir ce genre de choses est normalement l’e-mail, mais Gitea fournissant (entre autres) un *issue tracker*, ce serait quelque peu dommage de ne pas l’utiliser. Ce qui implique de permettre à Quiconque d’avoir un compte utilisateur sur mon instance, et c’est là que les problèmes commencent. Il se trouve qu’avoir une instance Gitea sur laquelle les inscriptions sont ouvertes au tout venant, c’est se retrouver avec une armée de comptes fantômes manifestement créés par des *bots*. Du coup, première question, Nal : À ton avis, c’est quoi l’intérêt de la manœuvre pour les maîtres des *bots* en question ? À quoi ça peut bien leur servir de se créer des comptes sur des forges logicielles où la seule chose qu’ils peuvent faire est de créer des rapports de bogue ? Si encore ils créaient des rapports factices dans lesquels ils glisseraient des liens vers des sites fournisseurs de pilules bleues, je pourrais comprendre, mais même pas : une fois créés, ces comptes ne font *rien*. C’est quoi le phoque ? Gitea offre plusieurs façons de gérer la création de comptes utilisateurs : **Porte ouverte:** Inscription directe via le simple remplissage d’un formulaire sur le site, sans plus de formalités. Faut-il préciser que c’est une très mauvaise idée ? (C’est quand même la configuration par défaut de Gitea.) **Confirmation par e-mail requise:** L’inscription n’est validée qu’après que l’utilisateur a suivi un lien dans un email envoyé à l’adresse fourni lors de l’inscription. C’est l’option `REGISTER_EMAIL_CONFIRM = true` de Gitea. Absolument inefficace contre les *bots* créateurs de comptes fantômes, en tout cas contre suffisamment d’entre eux pour que dans les faits je ne voie pas de différence entre cette option et la précédente. **Confirmation par un administrateur:** L’inscription n’est validée qu’après que l’administrateur du site (bibi) l’a examinée et manuellement confirmée. C’est l’option `REGISTER_MANUAL_CONFIRM = true`. Problèmes : ça devient rapidement pénible (sur mon instance le rythme de création de comptes tourne autour d’une trentaine par jours minimum), et surtout les informations fournies dans la demande de confirmation ne permettent absolument pas de distinguer une inscription légitime d’une inscription émanant d’un *bot*. (Un indice quand même, si vous choisissez cette voie : une demande d’ouverture de compte associée à une adresse Gmail émane *systématiquement* d’un *bot*, vous pouvez tirer à vue sans états d’âmes — manifestement Gmail n’a *pas* d’utilisateurs humains, en tout cas je n’ai jamais rien vu qui le suggère.)> Accessoirement l’option `REGISTER_MANUAL_CONFIRM` est présentement inopérante, [le correctif](https://github.com/go-gitea/gitea/pull/14455) arrivera dans Gitea 1.14.0. **Test de Turing "natif":** Le formulaire d’inscription inclut une *CAPTCHA* à résoudre, générée par Gitea. Activé avec le couple d’options `ENABLE_CAPTCHA = true` et `CAPTCHA_TYPE = image`. Peut être combiné avec la confirmation par email ou la confirmation manuelle. Problème : c’est [totalement inefficace](https://github.com/go-gitea/gitea/issues/12582). **Test de Turing par Google:** Le formulaire d’inscription inclut une *CAPTCHA* à résoudre, générée par Google ([service reCAPTCHA](https://developers.google.com/recaptcha/intro)). Activé avec le couple d’options `ENABLE_CAPTCHA = true` et `CAPTCHA_TYPE = recaptcha`, plus les options `RECAPTCHA_SECRET` et `RECAPTCHA_SITEKEY` à renseigner. Je n’ai pas encore essayé. **Test de Turing par hCaptcha:** Similaire au précédent, mais la CAPTCHA est fournie par [hCaptcha](https://www.hcaptcha.com/) au lieu de Google. Activé avec le couple d’options `ENABLE_CAPTCHA = true` et `CAPTCHA_TYPE = hcaptcha`, plus les options `HCAPTCHA_SECRET` et `HCAPTCHA_SITEKEY` à renseigner. Je n’ai pas encore essayé. **Utilisation de fournisseurs d’identité tiers:** Gitea permet la création de comptes authentifiés par des fournisseurs d’identité externes via *OAuth2*. Sont notamment supportés Google, GitHub, Facebook, Twitter, Nextcloud... Les fournisseurs acceptés sont à définir dans la rubrique *Authentication Source* de l’interface de configuration de Gitea ou via la commande `gitea admin auth add-oauth` en ligne de commande. On peut optionnellement rendre obligatoire le passage par un de ces fournisseurs (c’est-à-dire, ne pas autoriser la création de comptes locaux) avec l’option `ALLOW_ONLY_EXTERNAL_REGISTRATION = true`. Je n’ai pas encore essayé.> La possibilité d’utiliser GitHub notamment est potentiellement intéressante, vu que de nombreux développeurs sont déjà sur GitHub, et quelqu’un souhaitant juste me signaler un bogue pourrait apprécier de ne pas avoir à créer un compte sur mon instance Gitea juste pour ça. Les adeptes de Nextcloud pourraient eux apprécier de pouvoir utiliser leur compte dans le *Federated Cloud*. Dernière possibilité, enfin, la plus radicale : **Pas de création de nouveaux comptes initiée par l’utilisateur:** Seul l’administrateur peut créer des comptes. C’est l’option `DISABLE_REGISTRATION = true`. C’est ce que je fais présentement, avec un message invitant quiconque souhaite contribuer à mes projets à me contacter directement pour me demander gentiment que je leur ouvre un compte. Pas très satisfaisant dans la mesure où cette étape est probablement suffisamment repoussante pour quelqu’un qui voulait juste se rendre utile en signalant un bogue... Voilà pour les options possibles. Ce que je me demande maintenant (et ce que je *te* demande, Nal), c’est que faire ? Imagine que tu veuilles rapporter un bogue sur un petit logiciel sans importance (mais que tu aimerais bien voir corrigé quand même), qu’est-ce que tu préférerais ou que serais-tu prêt à accepter ? * Envoyer un email au développeur pour qu’il t’ouvre un compte sur sa forge (la situation actuelle – mais si tu fais ça, ce serait sans doute encore beaucoup plus simple de rapporter le bogue directement dans l’e-mail...). * Prouver ton humanité en te pliant à un exercice imposé par Google ou hCaptcha. Le cas échéant, une raison particulière de préférer l’un ou l’autre ? (Pour ma part : je n’aime pas la seule idée de passer par un service tiers, quel qu’il soit. Avantage de Google : j’ai déjà un compte chez eux donc je peux créer un reCAPTCHA en un instant. Avantage de hCaptcha : ce n’est pas Google, et s’il faut passer par un service tiers ce serait bien de ne pas utiliser toujours le même.) * Avoir la possibilité de te connecter via ton compte GitHub/Google/Twitter/Facebook/Nextcloud/etc. * Ne plus utiliser que des logiciels hébergés sur GitHub, parce que bon l’idéalisme du web décentralisé ça va bien cinq minutes mais maintenant il faut être réaliste. [^1]: Pour absurde que soit cette hypothèse, mes projets étant évidemment dépourvus de bogue. [^2]: Pour farfelue que soit cette hypothèse, mes projets étant déjà parfaits et non-susceptibles d’être améliorés.

AltStyle によって変換されたページ (->オリジナル) /