Journal Gitea contre les bots

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes :
31
11
fév.
2021

’jour Nal,

En tant que développeur de logiciels libres à mes heures perdues, j’ai ma propre instance Gitea 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 (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 projets1 ou ayant une amélioration à suggérer2 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 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.

Test de Turing par Google: Le formulaire d’inscription inclut une CAPTCHA à résoudre, générée par Google (service reCAPTCHA). 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 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. 

  • # une option

    Posté par  . Évalué à 10 (+12/-0).

    Je n'activerais pas les fournisseurs d'identité tiers, d'expérience c'est encore pire pour les bots.

    Ce que tu peux imaginer, c'est via un cron purger chaque jour chaque compte de plus de 5 jours qui a été créé sans générer une issue ou une pull request. Je pense que la plupart des bots sont créés dans le but d'éventuellement servir si un 0day apparait sur une plateforme pour transformer la machine qui l'héberge en noeud de botnet. En attendant ils sont dormants.

    • [^] # Re: une option

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

      Je n'activerais pas les fournisseurs d'identité tiers, d'expérience c'est encore pire pour les bots.

      Ah zut. Je n’avais pas l’intention d’essayer Google de toute façon (vu le nombre de comptes fantômes associés à des adresses Gmail…), mais j’étais quand même tenté par GitHub… Merci pour le retour.

      Ce que tu peux imaginer, c'est via un cron purger chaque jour chaque compte de plus de 5 jours qui a été créé sans générer une issue ou une pull request.

      C’est ce que je faisais « manuellement » avant de désactiver purement et simplement la création de nouveaux comptes.

      Gitea n’offre malheureusement pas la possibilité de supprimer massivement les comptes « inactifs ». On peut supprimer automatiquement les comptes inactivés (ceux qui n’ont pas répondu à l’e-mail de confirmation), mais pas les comptes « activés mais inactifs ».

      Tiens, je sens comme une odeur de feature request

      • [^] # Re: une option

        Posté par  . Évalué à 3 (+1/-0).

        Ah zut. Je n’avais pas l’intention d’essayer Google de toute façon (vu le nombre de comptes fantômes associés à des adresses Gmail…), mais j’étais quand même tenté par GitHub… Merci pour le retour

        Bon pour github honnêtwment je ne sais pas car mon expérience vient de la gestion d'un forum sur un sujet qui n'a rien à voir avec l'IT.

        Gitea n’offre malheureusement pas la possibilité de supprimer massivement les comptes « inactifs ».

        J'imagine que tu peux directement taper dans la DB.

    • [^] # Re: une option

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0). Dernière modification le 12/02/21 à 22:10.

      Je n'activerais pas les fournisseurs d'identité tiers, d'expérience c'est encore pire pour les bots.

      Les bots font de l’OAuth ?

  • # Par mail

    Posté par  . Évalué à 9 (+8/-1).

    Il ne me parait pas déconnant de laisser un message dans un coin avec une adresse mail pour les rapports occasionnel et si quelqu'un est régulier tu lui fait une compte.

    Sinon je me souvient d'une "astuce" mis en place sur les "vieux" site web pour éviter les bots. Cacher un champs qui ne devrais donc pas être remplis par un humain mais uniquement par les bots. Ou même un champ visible avec "Ne pas remplir" comme libellé. Et oui les bot étaient devenu "intelligent" et vérifiait si le champ était "visible"

    • [^] # Re: Par mail

      Posté par  . Évalué à 4 (+2/-0).

      Dans la même veine, mais ici c'était pour vérifier que l'utilisateur avais bien le manuel (et donc acheté le jeu), settlers demandait de reproduire le code (en cliquant sur 3 images) se trouvant à la page N du manuel.
      Je pense avoir déjà vu cette méthode ailleurs, genre "donner les 3 premiers mots de la 2ème phrase de telle page".

  • # Listes...

    Posté par  . Évalué à 8 (+7/-0). Dernière modification le 12/02/21 à 08:18.

    À quoi ça peut bien leur servir de se créer des comptes[…]

    Le "puppetmaster" qui crée les comptes n'est pas forcément celui qui les exploitent, par contre, ça fait de jolies listes d'URL à revendre ensuite aux spammeurs…

    Dans les commentaires des sites que je gère j'ai plein de messages style "Well done ! Gôod site !"
    Le commentaire lui-même ne sert à rien, mais permet ensuite de retrouver facilement les sites "ouverts" sans modération (notez la lettre ô dans 'good', très facile à "parser" avec un "crawler")

    Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.

    • [^] # Re: Listes...

      Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

      Une autre hypothèse, c'est que ça sert à augmenter le pagerank vu que les comptes peuvent parfois spécifier un lien vers un site perso.

      Si le but était simplement d'avoir des listes de comptes, je doute qu'il y aurait autant de bots, le marché n'est pas si gros que ça.

      Je crois que Gnome (et son instance gitlab) et Fedora (via pagure, mais aussi son wiki) ont eu des soucis de spam de ce genre par le passé.

      Mais comme mon serveur est référencé quasiment nulle part et en IP v6 uniquement, j'ai pour le moment échappé aux bots.

      • [^] # Re: Listes...

        Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

        Il y a aussi des comptes en attente. L'une des façons de lutter contre le spam c'est de filtrer les actions des nouveaux inscrits. La parade ? Ne rien faire quand on s'inscrit et commencer plus tard.

        J'ai eu ça sur mon instance gitlab, des "gens" qui s'inscrivaient sans rien faire. J'ai laissé faire, je ne voyais pas trop le souci. Puis un jour, ces comptes ont commencé à utiliser le système de hook pour proposer des liens vers divers trucs à vendre. Les hooks étant en plus un truc assez discret sur gitlab, j'ai mis du temps à m'en rendre compte. L'intérêt ? Peu importe où c'est, si un moteur de recherche les référence, ces liens font augmenter le poids du site de destination dans les résultats de recherche. Ou pas, parce que le SEO est une science complexe, mais en tout cas certains spammeurs y croient !

        À noter aussi qu'avoir un compte "en attente" permet d'exploiter une faille trouvée plus tard dans les mesures antispam (typiquement les hook sur gitlab, ça a été après avoir essayé d'autres trucs plus visibles).

        • [^] # Re: Listes...

          Posté par  (site Web personnel) . Évalué à 10 (+8/-0).

          Même retour d'expérience côté LinuxFr.org… Les spammeurs bourrins qui vendent du matériel obstétrique (super étude marketing les gars…), des escortes, des taxis au Pakistan ou en Indonésie, ou des accès VPN, en premier commentaire ou contenu, et pas en français, ils sont dégagés vite. On détecte assez bien ceux qui attendent le 3è commentaire après deux commentaires louches (type "tu as trop raison", "super contenu", etc.). Mais on doit outiller de plus en plus pour virer certains autres cas (notamment a posteriori). Et malgré ça il a des tas de comptes silencieux qui sont sûrement à des spammeurs… Dans les cartons, je prévois d'ailleurs de fermer les comptes non utilisés à un moment… Puis de purger les comptes fermés n'ayant aucun contenu/commentaire/étiquetage, vu que ça ne sert pas à grand chose de les garder d'une part, et qu'on stocke des données personnelles (probablement souvent de spammeurs) pour rien.
          Cf https://linuxfr.org/news/spam-spam-spam-spam-et-aussi-le-spam pour un retour en 2018. Et il faudrait sans douter compléter avec les changements des deux dernières années…

          • [^] # Re: Listes...

            Posté par  . Évalué à 5 (+3/-0).

            Alors j'attends encore un peu avant de commencer a spammer pour ma solution d'agrandissage du penis, basée sur la poudre verte, ou mon compte est suffisamment vieux pour passer inaperçu?

            Depending on the time of day, the French go either way.

  • # Une phrase importante

    Posté par  (site Web personnel) . Évalué à -10 (+9/-28). Dernière modification le 12/02/21 à 08:40.

    En fait tu résumes tout en quelques mots :

    […] un petit logiciel sans importance […]

    Voila, c'est tout. Faire chier les gens à créer un compte pour ça (un petit patch, tu ne les embauchent pas pour qu'ils travaillent sur un gros projet) rien que pour un pseudo-principe décentralisateur, c'est irrespectueux (oui, le respect n'est pas toujours où on l'imagine) envers tes utilisateurs.

    Donc soit héberger sur GitHub, ou GitLab (si tu veux un truc intermédiaire, au moins GitLab est en grande majorité libre, en plus d'être respectueux de la compétition en n’empêchant les autres de faire du non libre comme eux peuvent le faire, et tu peux mettre chez toi un jour), ou au minimum OAuth2 pour simplifier la vie à tes utilisateurs.

    Bref, il faut que tu choisisses entre ton prosélytisme pas des plus objectifs (oui, plein de projets libres sont sur GitHub car ce n'est pas le mal anti-libre, au contraire, ou je ne sais quelle "bonne raison") et respecter les gens.

    l’idéalisme du web décentralisé

    Ce qui tue cet idéalisme du web décentralisé est que les gens mettent la charrue avant les bœufs, n'arrive déjà pas à se mettre d'accord sur des bases (un peu comme la gauche française, tous "pour le peuple" mais sans tolérer les autres et du coup plein de partis aux scores ridicules) : si au moins c'était simple à se connecter parce que tout le monde "d'accord pour décentraliser" a travaillé ensemble pour proposer des connexions faciles par exemple… Au final on a OAuth2 bien verrouillé par les "gros" (pas "connexion par OAuth2", mais "connexion par Facebook"). Rappelons-nous bien Mozilla qui avait commencé une gestion d'identité pour l'abandonner rapidement, quand Google Chrome propose une connexion très facile à plein de sites, et après on s'étonne que Firefox sombre. En attendant que les gens se mettent d'accord pour une contre-offre, pas vraiment le choix si on veut respecter les utilisateurs.

    • [^] # Re: Une phrase importante

      Posté par  . Évalué à 8 (+7/-2).

      C'est dommage que tu ais arrêté ta lecture avant le troisième paragraphe

      Mon canal de prédilection pour recevoir ce genre de choses est normalement l’e-mail,

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Une phrase importante

        Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

        Sans parler de ce passage :

        manifestement Gmail n’a pas d’utilisateurs humains, en tout cas je n’ai jamais rien vu qui le suggère.1

        Ou des notes :-)

        Pour absurde que soit cette hypothèse, mes projets étant évidemment dépourvus de bogue. Pour farfelue que soit cette hypothèse, mes projets étant déjà parfaits et non-susceptibles d’être améliorés.

        Si j'avais le niveau, le journal me donnerait carrément envie de participer au projet. Et j'en profite pour remercier son auteur qui m'a bien fait rire.


        1. À la modération de ce site, on aimerait bien que ça soit le cas, ça permettrait de filtrer à vue toutes les adresses Gmail, mais, hélas, aussi surprenant qu'il paraisse, dans le lot, on a quelques humains qui valent la peine d'être lus. 

        Designeuse de masques pour sphéniscidés.

    • [^] # Re: Une phrase importante

      Posté par  (site Web personnel) . Évalué à 5 (+4/-1).

      Faire chier les gens à créer un compte pour ça (un petit patch, tu ne les embauchent pas pour qu'ils travaillent sur un gros projet) rien que pour un pseudo-principe décentralisateur, c'est irrespectueux (oui, le respect n'est pas toujours où on l'imagine) envers tes utilisateurs.

      Quel manque de respect ? Si quelqu'un n'est pas content parce qu'il y a un petit big sur le logiciel et ne veut pas créer un compte pour le signaler, il apprend à vivre avec ou n'a qu'à développer lui même le soft.

    • [^] # Re: Une phrase importante

      Posté par  . Évalué à 6 (+5/-1).

      Donc soit héberger sur GitHub, ou GitLab (

      Ou sur https://savannah.nongnu.org/ ? Je vais être honnête, le logiciel derrière est à la ramasse, mais au moins ils ont franchi du temps, et toi, tu dis juste qu'il faudrait qu'il héberge son code sur une plate-forme centralisée avec d'autres, de ce que j'ai compris?
      Pour rappel, cette instance est plus vieille que les deux instance sus-citées. Je me souviens également de gna.org, aujourd'hui décédé.
      Du coup, ne serait-ce pas un manque de respect d'avoir été sur github dans un premier temps? Double, puisque d'une part on force à utiliser un soft proprio, hébergé par une entreprise fournissant un produit gratuit (ce qui augmente drastiquement la suspicion de l'usage des données, mais on pourrait arguer à juste titre que ce point est valable pour toute association de personnes)?
      Serait-ce également un «manque de respect»?

      D'ailleurs, est-ce vraiment un manque de respect de donner gratuitement son travail?

      N'est-ce pas, au contraire, un manque de respect d'attendre de quelqu'un qu'il se connecte sur FooBar.example.com pour partager son travail?
      Par exemple, github (qui refusent la connexion tant que vous n'avez pas récupéré un code dans un mail qu'ils vous envoient… oui, c'est nouveau, 3-4 mois, oui, ça m'est arrivé plus d'une fois, et oui, ça me casse sévère les couilles!) ou sur gitlab, dont une partie du code est propriétaire me semble (à moins qu'ils utilisent la version communautaire? Vraie question pour le coup).

      • [^] # Re: Une phrase importante

        Posté par  (site Web personnel) . Évalué à 2 (+1/-1).

        ou sur gitlab, dont une partie du code est propriétaire me semble (à moins qu'ils utilisent la version communautaire? Vraie question pour le coup).

        Pour le coup, je crois qu'ils utilisent la version communautaire.

        Personnellement, j'étais prêt à payer une licence. Quand j'ai vu la tarification (que tu sois dev, mainteneur, ou simple rapporteur, tu te prends un siège), j'ai fais non. Petite équipe de dev, beaucoup de rapporteurs, je n'allais pas payer 50 sièges alors que nous ne sommes que 2 dev ! Et je ne regrette pas de l'avoir fait, car ils ont récemment changé leur politique, et maintenant, c'est 19$/mois/utilisateur minimum !

        Du coup, j'ai regardé un peu le code (après tout, c'est ouvert ), et j'ai vite compris comment générer ma propre licence. Je suis tranquille pour 30 ans :p

        • [^] # Re: Une phrase importante

          Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

          ou sur gitlab, dont une partie du code est propriétaire me semble (à moins qu'ils utilisent la version communautaire? Vraie question pour le coup).

          Pour le coup, je crois qu'ils utilisent la version communautaire.

          L’instance officielle gitlab.com ? Ce n’est pas la version "communautaire", mais une bonne partie des fonctionnalités des versions pour entreprises sont réservées aux comptes payant.

          On a quand même déjà un peu plus de fonctionnalités avec un compte gratuit sur gitlab.com qu’avec une instance auto-hébergée de la portion open-source de gitlab.

          • [^] # Re: Une phrase importante

            Posté par  (site Web personnel) . Évalué à 2 (+1/-1).

            Je ne parlais pas pour l'instance officielle de GitLab, mais pour les instances auto-hébergée. Et comme dit dans mon message, "feinter" la licence m'a permis d'activer les différentes fonctionnalités normalement payantes.

            Après, est-ce que l'instance officielle est différente, je ne saurais le dire…

            • [^] # Re: Une phrase importante

              Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

              Je ne parlais pas pour l'instance officielle de GitLab, mais pour les instances auto-hébergée.

              Le message auquel tu réponds n'évoquait que l'instance gitlab.com, d'où la confusion ;)

            • [^] # Re: Une phrase importante

              Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

              Et comme dit dans mon message, "feinter" la licence m'a permis d'activer les différentes fonctionnalités normalement payantes.

              Tiens, c'est rigolo mais quand j'étais jeune, on appelait ça du piratage… Mais bon, le code n'était pas ouvert.
              En tout cas, je trouve ça un poil limite.

              • [^] # Re: Une phrase importante

                Posté par  (site Web personnel) . Évalué à 2 (+0/-0).

                Dans le cadre d'un logiciel libre, parler de piratage n'a pas de sens puisque celui qui reçoit fait ce qu'il veut du logiciel.

                C'est ce que j'ai fais… avant de me rendre compte que GitLab EE n'était pas libre, juste ouvert (contrairement à GitLab CE qui lui, est libre).

                Après, comme dit dans un autre commentaire, c'était initialement un défi a but pédagogique (car je devais peut être mettre en place un système de licence pour un projet) et donc comprendre comment cela fonctionnait était très intéressant.

                Maintenant, j'avoue, je suis coupable car j'ai laissé. Mais comme dis ailleurs, la seule fonctionnalité que j'utilise, je peux aisément la mettre en place avec une tâche cron (ce que je vais faire d'ailleurs quand j'aurais un peu de temps…)

                • [^] # Re: Une phrase importante

                  Posté par  . Évalué à 2 (+0/-0). Dernière modification le 15/02/21 à 18:49.

                  Salut,

                  J'abonde dans ton sens. Étudier comment ça marche, c'est toujours intéressant.

                  On peut même aller beaucoup plus loin (et c'est en partie ce que tu raconte) : c'est très bien d'être "piraté", ce que m'a expliqué vite fait un chef un jour quand on a trouvé une version de notre logiciel (propriétaire…) disponible sans licence : De toute façon, les personnes ne payeront pas, et si on les laisse faire, on gagnera de la visibilité.

                  ;)

        • [^] # Re: Une phrase importante

          Posté par  . Évalué à 10 (+11/-0).

          Du coup, j'ai regardé un peu le code (après tout, c'est ouvert ), et j'ai vite compris comment générer ma propre licence. Je suis tranquille pour 30 ans :p

          J'ai peut-être mal interprété et, dans ce cas, je te pris de bien vouloir me corriger.

          Dans le cas où j'ai bien saisi ce que tu écris, et au risque de faire le casse-pied :

          • le code de la version EE est "ouvert" mais propriétaire quand même
          • contrairement à ce que tu avances dans un autre commentaire, ce que tu fais n'est pas une "feinte" de la licence . Juste une violation.

          Je comprends tout à fait la contrainte budgétaire que leur modèle de facturation par utilisateur peut poser (surtout dans ton cas où tu devrais payer un siège pour chaque utilisateur qui s'inscrit pour juste ouvrir un bug ce qui n'est pas financièrement tenable).

          Mais que tu postes sans rougir que c'est facile de défoncer leur génération de clef pour envoyer se faire foutre la licence, ça me parait un poil abusé sur un site où on discute/débat régulièrement des licences et de leur respect. La prochaine fois qu'une grosse boite se fait épingler pour non respect de la GPL, on lui dira qu'il n'y a pas de problème à avoir feinter la licence ?

          • [^] # Re: Une phrase importante

            Posté par  (site Web personnel) . Évalué à 2 (+1/-1).

            le code de la version EE est "ouvert" mais propriétaire quand même

            C'est ce que j'ai compris aussi. Comme il y a des restrictions sur les conditions de diffusions, je ne suis pas certains que l'on puisse qualifier la licence de libre, j'ai donc préféré dire que le code était ouvert, même si une grande partie est sous MIT.

            contrairement à ce que tu avances dans un autre commentaire, ce que tu fais n'est pas une "feinte" de la licence . Juste une violation.

            Je me permets de citer la licence (car oui, j'avais quand même lu un peu avant de procéder à cela) :

            Notwithstanding the foregoing, you may copy and modify
            the Software for development and testing purposes, without requiring a
            subscription.

            Que l'on pourrait traduire par :

            Malgré ce qui précède, vous pouvez copier et modifier le Logiciel à des fins de développement et de tests, sans que cela nécessite d'avoir un abonnement.

            C'est exactement ce que j'ai fais. Et je ne dis pas comment j'ai fais, ni ne diffuse le moyen de le faire.

            Juste pour information, initialement, c'était juste un défi (une manière d'évaluer mon niveau de compréhension d'un projet externe et de sa sécurité) et d'étudier le mécanisme de licence mis en place (car potentiellement, j'aurais du faire quelque chose de similaire pour un projet).

            Mais que tu postes sans rougir que c'est facile de défoncer leur génération de clef pour envoyer se faire foutre la licence, ça me parait un poil abusé sur un site où on discute/débat régulièrement des licences et de leur respect.

            Je n'ai pas à rougir de le dire. Le code est ouvert, on peut le lire et comprendre assez vite comment cela fonctionne. Le dire ou pas ne change pas grand chose.

            Le souci c'est de le faire et/ou de dévoiler comment faire. Et cela, je le concède, c'est beaucoup plus borderline. Je n'ai pas eu à modifier le code source. Je l'ai lu, j'ai compris comme ça marche, j'ai modifié la configuration du logiciel et cela fonctionne.

            Reste à savoir sous quelle licence se trouve les fichiers de configuration… (ce qui, si j'ai bien compris la licence, est sous MIT Expat car en gros, tout ce qui est en dehors de EE licence est sous MIT Expat).

            Donc la question est : sans modification des fichiers sources, peut-il y avoir, dans le cas précis, une violation de la licence ? Je le répète, je n'ai fais que de la configuration, le logiciel en lui-même je ne l'ai pas modifié (je n'ai même pas eu à le recompiler, c'est pour dire !)

            De plus, je ne dis pas comment y arriver (et je ne le ferai pas) car si je suis déjà à la limite de la licence (le fait qu'elle soit respectée ou non mériterait l'oeil d'un juriste), le fait de dévoiler et de dire comment le faire serait clairement en infraction (car là, je pourrais nuire à leur business et c'est expressement dit dans la licence qu'il est interdit de publier et distribuer des sous-licences et/ou de vendre le logiciel).

            Enfin, si demain je devais choisir, entre continuer et arrêter, et bien j'arrêterai et utiliserai uniquement la version gratuite, ou bien je cloturerai carrément mon instance. Mon instance est simplement un clone de github, et la seule fonctionnalité non disponible dans la version community que j'utilise, c'est la possibilité de créer un dépôt sous GitLab, qui soit le clone d'un dépôt externe ou pull mirroring (ce que je pourrais tout à fait faire autrement à base de hook ou de scripts cron par exemple).

            Si mes besoins changent, et que j'ai véritablement besoin d'une licence, j'acquiererai une véritable licence, quitte à avoir 2 instances de GitLab, une communauté, et une autre avec abonnement afin de limiter un peu le prix, mais je ne vois vraiment pas pour l'instant la fonctionnalité qui me manquerait pour en arriver là.

            Quoi qu'il en soit, et je vais peut être me faire dézinguer en disant cela, mais du point de vue purement légal, je n'ai pas l'impression d'enfreindre la licence.

            Du point de vue moral, oui, c'est pas bien. Toutefois, je peux totalement me passer de la licence, donc je n'ai pas beaucoup de scrupule car je peux aisément faire sans. J'ai encore moins de scrupules quand je vois que GitLab a fait disparaitre les comptes à 5$/mois au profit de ceux à 20… (x4 dans les prix, ça fait mal quand même)… Mais comme le rappel très bien Zenitram dans son très intéressant journal, la licence (bon, ok, dans son journal, c'est le libre, mais cela n'en reste pas moins vrai) se fout de la moral…

            • [^] # Re: Une phrase importante

              Posté par  (site Web personnel) . Évalué à 9 (+7/-0).

              la seule fonctionnalité non disponible dans la version community que j'utilise, c'est la possibilité de créer un dépôt sous GitLab, qui soit le clone d'un dépôt externe ou pull mirroring

              C’est justement là que tu ne respectes pas la licence ;)
              Je cite le passage en question :

              This software and associated documentation files (the "Software") may only be
              used in production, if you (and any entity that you represent) have agreed to,
              and are in compliance with, the GitLab Subscription Terms of Service, available
              at https://about.gitlab.com/terms/#subscription (the “EE Terms”), or other
              agreement governing the use of the Software, as agreed by you and GitLab,
              and otherwise have a valid GitLab Enterprise Edition subscription for the
              correct number of user seats.

              L’exception donnée plus loin ne concerne clairement que le développement de GitLab lui-même, et les tests liés à son développement :

              Notwithstanding the foregoing, you may copy and modify
              the Software for development and testing purposes, without requiring a
              subscription.

              En gros c’est une exception permettant de participer au développement de GitLab EE sans pour autant devoir en acheter une licence d’utilisation. Ce qui ne semble pas être le cas d’utilisation que tu décris.


              Après je ne cause pas du côté moral de ce que tu fais, à titre personnel ça ne me touche pas du tout ;)
              Mais sois bien conscient que sur le plan légal tu n’es pas dans les clous.

              • [^] # Re: Une phrase importante

                Posté par  (site Web personnel) . Évalué à 3 (+2/-1).

                L’exception donnée plus loin ne concerne clairement que le développement de GitLab lui-même, et les tests liés à son développement :

                Hmmm, c'est intéressant. Je n'avais pas du tout compris ce passage de cette manière là. J'avais compris développement et test dans son sens général, et non uniquement pour le cas spécifique de GitLab. Aurais-je compris ce qu'il m'arrangeait de comprendre ? Pour ma part, j'avais prévu un test de GitLab pendant 6 mois (3 en interne, et 3 avec des clients à l'issue de la première phase si concluante).

                Pour l'instant, je suis toujours en train de tester GitLab. Mes clients sont encore sur mon redmine, sauf 1 qui me sert de béta testeur qui est sur le GitLab depuis le semaine dernière (et là, il est en vacances).

                Mais sois bien conscient que sur le plan légal tu n’es pas dans les clous.

                Bon ben je vais peut être "croner" ma tâche de synchro. Cela sera tout aussi efficace et je n'en ai pas pour très longtemps à le faire !

                J'aviserai en fonction des retours que j'ai de mes clients. Cela ne me dérange pas de payer, si le paiement est justifié. Et encore… vu l'évolution tarifaire qu'il y a eu il y a quelques semaines, la donne a changé. Ce sera peut être tout simplement abandon de GitLab au profit de GitHub (qui me coutera 4x moins cher).

                J'avais choisi GitLab pour ne pas (trop) dépendre d'un service tiers et avoir le contrôle des données (notamment dans le cadre du RGPD). Et avec Github, je n'aurais pas de questions à me poser sur les mises à jour et le SLA…

                En tout cas, j'en retire pas mal d'enseignements :
                - on comprend souvent ce qu'on a envie de comprendre, et qu'il serait plus sage d'avoir un département juridique ;
                - les tarifs et conditions tarifaires, que se soit dans le SaaS ou en auto-hébergement peuvent varier d'un coup et de manière très brutale (x4, ça fait mal quand même) et qu'il ne faut donc pas oublier cette possibilité ;
                - toujours se garder une porte de sortie en pouvant, a minima, récupérer ses données (cf. évolution tarifaire ou fermeture du service par exemple) ;

                • [^] # Re: Une phrase importante

                  Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

                  Franchement, si la seule fonctionnalité payante de GitLab qui te manque est remplaçable par une tâche cron, utilise l’édition libre et gratuite avec ta tâche cron en supplément. Aucun risque de mauvaise surprise côté évolution des tarifs, de licence à modifier parce que tu as un utilisateur à ajouter, ou de changement quelconque des conditions d’utilisation.

                  Vu les tarifs des différentes éditions pour entreprise, ce serait vraiment dommage de payer ça juste pour économiser un petit script et une ligne dans un crontab ;)

                  Pour ma part j’utilise la version libre (et gratuite) depuis quelques années avec toute une équipe (une poignée de développeurs réguliers, et une quinzaine de contributeurs plus ponctuels), et si j’en avais la possibilité j’aurais plutôt tendance à en retirer des fonctionnalités plutôt que de chercher à en ajouter… Mais c’est pour du développement communautaire de logiciel libre, sans aucune structure derrière (ni entreprise, ni association), donc nos besoins semblent bien différents de ce que tu décris ici.

  • # Crée les comptes manuellement

    Posté par  (site Web personnel) . Évalué à 6 (+5/-1).

    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 ?

    Puisque je n’ai pas de réponse à ta question, je vais répondre du point de vu opposé, à la question :

    Imagine que tu veuilles qu’on puisse te rapporter un bogue sur un petit logiciel sans importance […], qu’est-ce que tu préférerais ou que serais-tu prêt à accepter ?

    Et là, la réponse est plus simple à mon avis : il ne faut pas accepter les rapports de bogues sur une forge logicielle tant que tu tiens la charge par courrier électronique. Entre un robot et un rapporteur de bug hypothétique qui préférerait une forge logicielle à un courriel, il n’y a pas un saut qualitatif significatif. GitHub doit beaucoup de son succès pour de petits projets à son nombre d’utilisateurs qui ne savent pas utiliser Git, déposent juste des fichiers via l’interface web, produisent un commit au descriptif vide et génèrent une poule-requête dans la foulée. Ceux là, tu préféreras toujours qu’ils te contactent via le compte qu’ils ont déjà sur Gmail, plutôt qu’ils en créent un de plus sur ton Gitea. D’ailleurs, tu en as peut-être déjà pris certains pour des bots, vu ton expérience avec Gmail. Malheureusement, les humains échouent presque autant que les machines au test de Turing, pour être optimiste attribuons ça aux progrès des intelligences artificielles.

    • [^] # Re: Crée les comptes manuellement

      Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

      Imagine que tu veuilles qu’on puisse te rapporter un bogue sur un petit logiciel sans importance […], qu’est-ce que tu préférerais ou que serais-tu prêt à accepter ?

      Alors, de mon point de vue, « la question elle est vite répondue » en effet : l’e-mail, moi ça me convient parfaitement.

      tant que tu tiens la charge par courrier électronique

      Vu le nombre de rapports de bogue que je reçois, je pense que j’ai encore une marge considérable avant d’être surchargé.

      (Mes logiciels ont soit très peu de bogues, soit très peu d’utilisateurs… :D )

    • [^] # Re: Crée les comptes manuellement

      Posté par  . Évalué à 3 (+1/-0).

      Entre un robot et un rapporteur de bug hypothétique qui préférerait une forge logicielle à un courriel

      Je me permets d'ailleurs de vous remémorer l'épisode ou une entreprise à encouragé le spam de rapports de bugs. Je n'arrive pas a retrouver le truc complet (en moins de 60s) mais je trouve d'autres résultats amusants (non-lus, je me base sur l'en-cart du moteur de recherche):

      How to deal with GitHub spambots - DEV Community
      https://dev.to/nikpoltoratsky/how-to-deal-with-github-spambots-5e6n
      Somebody decided that it's a good idea to create a 3000+ spam issues with advertising in Chinese in our repository

      • [^] # Re: Crée les comptes manuellement

        Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

        Je me permets d'ailleurs de vous remémorer l'épisode ou une entreprise à encouragé le spam de rapports de bugs.

        Oh, ces hypocrites de Digital Ocean qui offrent des t-shirts en échange de spam sur GitHub ?

        Un intervenant d’exception partageait un lien à ce sujet sur un réseau social tout aussi exceptionnel il y a quelques mois : pull request «DDoS» par DO sur github?

        • [^] # Re: Crée les comptes manuellement

          Posté par  . Évalué à 3 (+1/-0).

          Oui, voila, eux. Merci.

        • [^] # Re: Crée les comptes manuellement

          Posté par  (site Web personnel) . Évalué à 5 (+4/-1).

          Oh, ces hypocrites de Digital Ocean qui offrent des t-shirts en échange de spam sur GitHub ?

          C’est l’exécution qui était pété, pas le principe (si on accepte que ça vaut le coup de devenir un homme sandwich).

          Le principe c’était « contribuez à du logiciel libre sur GitHub et on vous offre un t-shirt », le but n’était pas de créer des PR inutiles, c’est juste qu’un tas de trous du cul on commencé à faire de la publicité sur ce challenge en encourageant les gens à faire des PR idiotes.

          Maintenant, ça aurait été bien différent si le même concours avait eu lieu avec des règles comme : les mainteneurs choisissent si leur projet fait partit du concours, la PR doit modifier/ajouter un certain nombre de lignes de code et/ou de documentation, ou même que les mainteneur choisissent eux même si une PR est acceptée en la labellisant d’une certaine manière.

          Bref, c’est juste qu’ils ont pas réfléchi à l’implémentation, mais l’idée d’inciter les gens à contribuer ne me parait pas déconnant.

  • # Autres idées

    Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

    Et pourquoi ne pas ajouter une couche de sécurité supplémentaire avec, par exemple, une config fail2ban (bon je ne suis pas fan, mais ça peut aider), voire une mitigation de connexion avec xt_recent et firewalld (il y a quelques tutos sur le web)?

    Ou bien encore configurer ton service web pour qu'il bannisse les ip suspectes (par exemple avec https://www.knthost.com/search?search=nginx ou encore mod_security 3.0 configuré avec le projet honeypot…)?

    Évidemment, ça n'empêche pas un humain de se créer un compte, mais ça réduit considérablement la fenêtre d'attaque.

    • [^] # Re: Autres idées

      Posté par  . Évalué à 6 (+4/-0).

      De mon expérience sur un forum ça ne suffit pas. Les bots créent des comptes depuis des machines compromises dans toute la planète et avec le nombre de bordel IOT passoires disponibles ils peuvent changer d'adresse ip à chaque requête donc tu ne peux ni te baser sur la geolocalisation pour te dire que c'est douteux, ni sur la répétition

  • # Écrire son propre captcha ?

    Posté par  . Évalué à 6 (+4/-0). Dernière modification le 12/02/21 à 12:58.

    Je me suis toujours demandé si finalement il ne valait pas mieux se créer un petit captcha simple dans ces cas-là.

    Certes il n'a aucun chance de survivre face à qqu'un qui veut écrire un bot spécifique, mais au moins les bots existant ne sauront pas le résoudre. Et pour un petit site "insignifiant" (avec tout le respect…) ça suffirait peut-être ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Écrire son propre captcha ?

      Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

      Je me suis toujours demandé si finalement il ne valait pas mieux se créer un petit captcha simple dans ces cas-là.

      Pas franchement motivé pour aller tripatouiller le code de Gitea (d’autant que le Go n’est pas un langage avec lequel je suis familier) pour y injecter un captcha de mon cru, même si je suis d’accord que ça pourrait être une solution suffisante.

      Et pour un petit site "insignifiant" (avec tout le respect…) ça suffirait peut-être ?

      Mon site est clairement insignifiant, de même que les projets que j’héberge dessus, mais le problème je pense c’est que la forge que j’utilise, elle, ne l’est pas. Gitea est assez populaire il me semble (bon, « populaire » auprès d’un certain public, évidemment), ça ne m’étonnerait pas que des bots scannent le net spécifiquement pour rechercher des instances.

      Du coup, toute solution implémentée directement dans le code upstream (par opposition à un bidouillage local propre à une instance précise) ne résisterait probablement pas longtemps (comme c’est arrivé pour les CAPTCHA ”natives” de Gitea, totalement inutiles aujourd’hui).

      • [^] # Re: Écrire son propre captcha ?

        Posté par  . Évalué à 2 (+1/-0).

        J'héberge personnellement du gitea depuis plusieurs années, et je n'ai jamais eu de bots.
        Tu dois avoir un site racine super populaire didonc !

        Perso, je pense que j'activerais l'oauth github. Je ne pense pas qu'il y ait autant de bot sur github, mais bon, je ne suis pas un connaisseur.

        • [^] # Re: Écrire son propre captcha ?

          Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

          J'héberge personnellement du gitea depuis plusieurs années, et je n'ai jamais eu de bots.
          Tu dois avoir un site racine super populaire didonc !

          C’est malin, je vais prendre la grosse tête maintenant !

          Sérieusement, si quelqu’un a une explication sur pourquoi certaines instances attirent les bots et pas d’autres (et s’il y a éventuellement des choses à faire pour éviter de les attirer), je suis preneur. Parce que chez moi, dès que j’ai ré-ouvert le formulaire d’inscription, le premier bot est arrivé après même pas dix minutes. o_O

          Genre il y avait un type en embuscade qui surveillait mon site avec des jumelles, prêt à crier « Ça y est les gars, il a ré-ouvert les inscriptions ! À l’attaaaaaque ! »

          Perso, je pense que j'activerais l'oauth github. Je ne pense pas qu'il y ait autant de bot sur github

          C’est fait. :) On verra ce que ça donne, mais (naïvement peut-être) j’ai assez bon espoir que Github sache faire du bon boulot en la matière — vue leur position, ils ne doivent pas tellement avoir le choix…

  • # Test de turing

    Posté par  (site Web personnel) . Évalué à 10 (+13/-1).

    Je reviens sur la notion de test de Turing. Par expérience, les captchas se font déborder, toujours. Il y a une certaine logique à ça : ce qui est automatisable dans sa génération, est automatisable dans sa résolution. C'est une course perpétuelle.

    Ce qui marche, c'est de faire des tests évolutifs, et on en arrive donc à ta solution :

    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…

    Demander un échange "entre humains" pour créer un compte est actuellement encore valable pour détecter une machine ET pour éloigner les humains dont le métier est de spammer. Car oui, certaines créations de comptes ne sont pas automatisées, mais réalisées par des humains qui gagnent quelques centimes à chaque compte. Seulement vu les misères qu'ils touchent, ils ne vont pas perdre du temps à avoir un échange et papoter avec quelqu'un, il y a plus rentable ailleurs sur le net : ça fait du tri.

    Ça fait aussi du tri chez tous les humains pas très doués. Cependant, et c'est là qu'en tant que dev ça peut t'intéresser, ça va faire un tri "utile". Plutôt que de te retrouver avec des tickets mal formatés, incompréhensibles, tu vas avoir des mails, avec des infos un peu similaires mais un vrai canal pour échanger. Et ton service de ticket va s'en retrouver assaini et donc utilisable.

    Mon expérience de pas-dev ayant eu envie de signaler des bugs : même sur github, je rame toujours à trouver si il y a déjà eu des problèmes similaires, déjà traités, etc ; je ne parle souvent pas la langue du dev ; github m'enquiquine avec ses captchas, son ergonomie et son formatage à l'américaine (non, deux points ne veulent pas dire que je veux un smiley !), je ne sais pas comment décrire mon problème, bref je rame quand je fais un ticket, à tel point que même en ayant un compte sur la plate-forme, généralement je ne remonte pas les problèmes. À l'inverse, sur certains projets j'ai des échanges directs avec les devs. J'explique par mail, IRC ou XMPP, on échange, ils m'aident soit à dépatouiller mon problème soit à dire "ah oui y'a un vrai bug" et à le décrire pour le rendre reproductible. Et on construit le rapport de bug ensemble, qui sera réellement utile dans leur forge. Parfois aussi ils n'ont pas le temps, ça reste une info en l'air, ce qui n'est pas très grave : j'ai déjà fait un peu mieux que de ne rien remonter, ça reste une info "quelque part" qui donnera peut-être du sens au rapport de bug suivant.

    De mon côté : faire un ticket sur une forge, même avec un compte, est plus rebutant que d'envoyer un mail.

    Écrire un mail est plus simple que s'inscrire sur une plate-forme et apprendre à l'utiliser. Tout le monde doit écrire des mails ; chacun a déjà son logiciel pour ça. Donc, laisser ton adresse mail et gérer les remontées de bug par ce canal est le plus simple pour tes utilisateurs. Ça te demande potentiellement un peu plus de boulot, mais tu devrais aussi le faire pour des tickets…

    Quand à ceux qui ne savent pas écrire un mail, s'ils sont triés dans l'affaire : est-ce vraiment un gros souci ? Tu as éliminé tous ceux qui ne sont pas assez autonomes pour réaliser une action aussi simple ; ce serait peut-être gênant pour un média social, mais là il s'agit de bosser sur un projet, être un peu excluant sur certains critères évite de perdre trop de temps…

  • # Bloquer les GAFAM

    Posté par  (site Web personnel) . Évalué à 10 (+17/-1).

    Sur la forge de ./play.it, une instance GitLab, je tente une approche originale : https://forge.dotslashplay.it/users/sign_in
    Je cite : « To avoid spam issues, e-mail addresses ending with .com are not allowed to register from this form. If you wish to use such an address, please contact us by e-mail or on IRC. »

    Le message inclut des liens directs pour nous contacter par mail ou IRC, donc de cette page on peut directement contacter un admin qui lui pourra créer le compte. Et bien sûr, si on n’utilise pas une adresse en .com on peut s’inscrire sans aucune restriction.

    Ça fait quelques mois que j’ai mis cette restriction en place, et je n’ai plus eu aucune forme de spam depuis (pour être honnête, j’ai aussi mis en place un honeypot au même moment). Et contrairement à ce qu’on m’annonçait la première fois que j’ai présenté cette approche, les inscriptions légitimes n’ont pas diminué.

    En bonus, j’ai le plaisir mesquin de retourner complètement l’approche raciste habituelle qui consiste à bloquer les TLD correspondant à la Russie, la Chine ou l’Afrique… Là je bloque le seul TLD qui s’annonce directement comme "commercial", et je dois admettre en tirer une certaine forme de satisfaction ;)

    • [^] # Re: Bloquer les GAFAM

      Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

      J’ai clairement un gros contingent de comptes fantômes associés à des adresses gmail.com, mais le reste vient d’un peu partout. J’ai du .ru, du .pw, du .nl, du .cn

      Ce qui est intéressant en revanche, c’est qu’il n’y a quasiment que les bots avec des adresses en gmail.com qui arrivent à passer l’étape de la confirmation par e-mail (REGISTER_EMAIL_CONFIRM), tous les autres sont correctement filtrés par cette étape (c’est-à-dire qu’ils créent bien des comptes, mais ne les activent jamais, ce qui permet de les nettoyer facilement).

      Je ne sais pourquoi les bots gmail.com sont plus « fûtés » que les autres, mais du coup, coupler la demande de confirmation par e-mail à un refus pur et simple des adresses Gmail pourrait être une bonne solution (en laissant quand même la possibilité d’ouvrir un compte sur demande manuelle, pour les 0.01% d’utilisateurs de Gmail qui ne sont pas des bots).

      • [^] # Re: Bloquer les GAFAM

        Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

        Dans mon cas j’ai bien une confirmation par e-mail pour valider la création des comptes, probablement équivalente à l’option de Gitea.

        Comme toi c’était un mélange d’adresses de pas mal d’origines qui se faisaient bloquer par cette étape, c’est peut-être le honeypot qui a fait disparaître cette catégorie de spammeurs de mon radar.

  • # Follow-up

    Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

    Merci pour tous les commentaires pertinents.

    Je remarque que parmi les solutions envisageables, personne ne s’est prononcé pour les CAPTCHA externes (reCAPTCHA ou hCaptcha). J’avoue que ça m’a (agréablement) surpris, je m’attendais un peu à être orienté vers cette solution, sur le mode « Ouais les reCAPTCHA, personne n’aime ça, mais enfin ça marche, alors vas-y te casse pas la tête (et pis d’toute façon tout le monde les utilise déjà, alors bon…) ».

    En définitive, j’ai ré-ouvert la création de comptes locaux, avec les contraintes suivantes :

    • saisie d’une CAPTCHA générée nativement par Gitea (dans les faits ça n’arrête pas beaucoup de bots, mais c’est toujours ça de pris) ;
    • confirmation par e-mail requise, les comptes non-confirmés au bout de trois jours étant automatiquement supprimés (ça arrête presque tous les bots sauf ceux associés à des adresses Gmail, qui malheureusement représentent de loin le plus gros contingent) ;
    • interdiction pure et simple de créer un compte avec une adresse Gmail,1 sauf sur demande adressée directement à moi-même2 — merci à vv222 pour m’avoir suggéré cette approche à l’artillerie lourde, que je n’avais pas osé envisagé.

    J’ai aussi ajouté GitHub comme fournisseur OAuth2, pour permettre à celles et ceux ayant un compte GitHub de l’utiliser pour se connecter chez moi. On verra bien si ça ouvre de nouveau la porte en grand aux bots, auquel cas je mettrais évidemment fin à l’expérience.


    1. Avec l’option EMAIL_DOMAIN_BLOCKLIST, qui je l’espère sera disponible à partir de Gitea 1.15.0. 

    2. Demande sur papier libre à m’adresser par lettre recommandée, merci d’inclure une enveloppe timbrée libellée à votre adresse pour recevoir en réponse le mot de passe du compte nouvellement crée. 

    • [^] # Re: Follow-up

      Posté par  . Évalué à 5 (+3/-0).

      confirmation par e-mail requise, les comptes non-confirmés au bout de trois jours étant automatiquement supprimés

      Pourquoi 3 jours ? Est-ce qu'ils y a beaucoup d'humains qui attendent autant de temps avant de confirmer un compte ? J'imaginais que 3 heures était un délai amplement suffisant.

      • [^] # Re: Follow-up

        Posté par  (site Web personnel) . Évalué à 9 (+7/-0).

        Pas de raison particulière, c’est « au doigt mouillé. » J’abaisserai peut-être le délai à 24 h par la suite.

        J'imaginais que 3 heures était un délai amplement suffisant.

        Trois heures, ça me semble vraiment court.

        Je peux imaginer que quelqu’un remplisse le formulaire puis, le mail de confirmation n’arrivant pas immédiatement (peut-être parce que son fournisseur fait du greylisting, ce qui peut facilement retarder la réception d’une bonne heure selon « l’agressivité » du greylisting), passe à autre chose, peut-être quitte son bureau parce que c’est la fin de la journée, et ne rouvre pas son client mail avant le lendemain matin…

        • [^] # Re: Follow-up

          Posté par  . Évalué à 3 (+1/-0).

          Ou tout simplement la connexion qui lâche à ce moment la, et donc impossible de récup le mail, tu passes à autre chose, donc tu remets au lendemain…

          3 jours, c'est bien, ça laisse un weekend passer.

      • [^] # Re: Follow-up

        Posté par  (site Web personnel) . Évalué à 4 (+2/-0). Dernière modification le 21/02/21 à 23:19.

        Il ne faut pas oublier que les emails ne sont pas synchronent: il peut y avoir beaucoup de délais entre l'envoi et la réception d'un email.

        En plus, en général, il me semble que les fournisseurs de mail essaient pendant 5 jours d'envoyer l'email au serveur destinataire s'il est indisponible.

        Du coup, si le serveur destinataire est indisponible pendant quelques temps (soit à cause du réseau IPv6 / IPv4 / BGP / VPN intermédiaire / firewall / DOS chez les intermédiaires / routeurs en rade…), c'est tout à fait possible que 3 heures ne suffisent simplement pas à recevoir un mail.

        Je pense que garder 3 jours un compte inactif sur son service GIT n'est pas trop dérangeant (quelques Kio de disques employés) et permet au potentiel contributeur de terminer son inscription quand ses emails sont à nouveau disponible.

        Si les disques se prennent vraiment trop de comptes ainsi à cause des bots, je descendrai la limite à 1 jour, voir 9 heures. En tout cas, je n'irai pas plus bas qu'"une journée de travail" (et encore, cette définition dépend des pays sources de contributeurs, par exemple, Suisse vs France vs Japon…).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.