’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_CONFIRMest 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.
# une option
Posté par Psychofox (Mastodon) . Évalué à 10.
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 gouttegd (site web personnel) . Évalué à 4.
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.
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 Psychofox (Mastodon) . Évalué à 3.
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.
J'imagine que tu peux directement taper dans la DB.
[^] # Re: une option
Posté par azerttyu (site web personnel) . Évalué à 2.
Hello
Je débarque après la bataille mais de notre coté on utilise entre autre ça :
https://git.spip.net/spip-contrib-outils/importToGitea/src/branch/master/cleanSpamAccount.sh
Sur gitea les spams utilisaient souvent le meme tld avec l'api c'est alors facile de purger ces cas.
On pourrait compléter avec la détection des comptes inactifs de plus de 5 jours ou autre.
En cron ça fait le taff
[^] # Re: une option
Posté par Anonyme . Évalué à 4. Dernière modification le 12 février 2021 à 22:10.
Les bots font de l’OAuth ?
# Par mail
Posté par Mimoza . Évalué à 9.
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 freem . Évalué à 4.
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".
[^] # Re: Par mail
Posté par Mimoza . Évalué à 3.
civilization premier du nom, posait des question sur l'arbre de techno
Un des premier jeu indiana-jones exigeait un code via un double disque (type carte des étoile) qui était complètement noir, mat pour le fond, brillant pour l'écriture, donc impossible a photocopier.
# Listes...
Posté par redo_fr . Évalué à 8. Dernière modification le 12 février 2021 à 08:18.
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 Misc (site web personnel) . Évalué à 6.
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 Zatalyz (site web personnel) . Évalué à 8.
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 Benoît Sibaud (site web personnel) . Évalué à 10.
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 Frank-N-Furter . Évalué à 6.
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 Zenitram (site web personnel) . Évalué à -10. Dernière modification le 12 février 2021 à 08:40.
En fait tu résumes tout en quelques mots :
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.
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 claudex . Évalué à 8.
C'est dommage que tu ais arrêté ta lecture avant le troisième paragraphe
« 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 Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 7.
Sans parler de ce passage :
Ou des notes :-)
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.
À 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. ↩
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Une phrase importante
Posté par Lutin . Évalué à 5.
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 Psychofox (Mastodon) . Évalué à 0. Dernière modification le 12 février 2021 à 11:18.
[^] # Re: Une phrase importante
Posté par freem . Évalué à 7.
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).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Une phrase importante
Posté par vv222 (site web personnel) . Évalué à 5.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Une phrase importante
Posté par vv222 (site web personnel) . Évalué à 2.
Le message auquel tu réponds n'évoquait que l'instance gitlab.com, d'où la confusion ;)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Une phrase importante
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 6.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Une phrase importante
Posté par _kaos_ . Évalué à 3. Dernière modification le 15 février 2021 à 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é.
;)
Matricule 23415
[^] # Re: Une phrase importante
Posté par bbo . Évalué à 10.
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 :
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 ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Une phrase importante
Posté par vv222 (site web personnel) . Évalué à 10.
C’est justement là que tu ne respectes pas la licence ;)
Je cite le passage en question :
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 :
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Une phrase importante
Posté par vv222 (site web personnel) . Évalué à 4.
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 jyes . Évalué à 7.
Puisque je n’ai pas de réponse à ta question, je vais répondre du point de vu opposé, à la question :
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 gouttegd (site web personnel) . Évalué à 3.
Alors, de mon point de vue, « la question elle est vite répondue » en effet : l’e-mail, moi ça me convient parfaitement.
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 freem . Évalué à 3.
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):
[^] # Re: Crée les comptes manuellement
Posté par vv222 (site web personnel) . Évalué à 7.
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 freem . Évalué à 3.
Oui, voila, eux. Merci.
[^] # Re: Crée les comptes manuellement
Posté par Anonyme . Évalué à 5.
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.
[^] # Re: Crée les comptes manuellement
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à -1.
Voilà, ce fut un Délicieux-et-Délicat DO Sandboxlike-ou-Sample
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Autres idées
Posté par Bruce Le Nain (site web personnel) . Évalué à 7.
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 Psychofox (Mastodon) . Évalué à 6.
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 gUI (Mastodon) . Évalué à 6. Dernière modification le 12 février 2021 à 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 gouttegd (site web personnel) . Évalué à 3.
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.
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 16aR . Évalué à 2.
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 gouttegd (site web personnel) . Évalué à 3.
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 ! »
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 Zatalyz (site web personnel) . Évalué à 10.
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 :
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 vv222 (site web personnel) . Évalué à 10.
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
.comare 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
.comon 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 gouttegd (site web personnel) . Évalué à 4.
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.comqui 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.comsont 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 vv222 (site web personnel) . Évalué à 3.
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 gouttegd (site web personnel) . Évalué à 4.
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 :
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.
Avec l’option
EMAIL_DOMAIN_BLOCKLIST, qui je l’espère sera disponible à partir de Gitea 1.15.0. ↩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 Jean-Baptiste Faure . Évalué à 5.
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 gouttegd (site web personnel) . Évalué à 9.
Pas de raison particulière, c’est « au doigt mouillé. » J’abaisserai peut-être le délai à 24 h par la suite.
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 freem . Évalué à 3.
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 Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 21 février 2021 à 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…).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.