Traduction : « Je ne veux pas de spam ! »

Le spam est un problème qu’à Framasoft, nous connaissons bien. Mais savez-vous à quel point ?
Je vais, dans cet article, vous dresser le tableau des soucis de spam que nous rencontrons et des contre-mesures que nous avons mises en place.

Avant cela, un peu d’histoire…

Qu’est-ce que le spam ?

Avant l’ère d’Internet, le spam n’était qu’une marque de viande en conserve.

Les Monty Python, humoristes anglais à qui l’on doit notamment les hilarants Sacré Graal ! et La vie de Brian, ont réalisé un sketch (version textuelle) dans lequel un couple, dans un restaurant, demande ce qu’il y a à la carte pour le petit déjeuner et où la serveuse ne propose que des plats avec du spam (et pas qu’un peu : « Spam, spam, spam, spam, spam, spam, baked beans, spam, spam, spam and spam. »). La femme du couple ne peut avoir de petit déjeuner sans spam, la serveuse ne lui proposant qu’encore plus de spam… (le titre de cet article est une citation de la femme du couple).

De ce sketch découle l’utilisation du terme spam pour les courriels indésirables (et tout autre message indésirable, quelle que soit la plateforme comme nous allons le voir).
De nos jours, le spam représente 50% des courriels échangés sur la planète.

Que serait une marque sans #CopyrightMadness ? Hormel Foods, l’entreprise derrière le spam a tenté d’utiliser le droit des marques pour éviter que le nom de son produit soit utilisé pour quelque chose dont personne ne veut et pour essayer d’empêcher d’autres entreprises d’utiliser le terme (comme des éditeurs de solutions anti-spam). Je croyais qu’Hormel Foods avait cessé cette lutte inutile, mais il semblerait que non, allant jusqu’à embêter Gee pour un dessin qu’il proposait sur RedBubble.

Le spam dans les courriels

Chez Framasoft, nous sommes aux deux bouts de la chaîne : nous envoyons beaucoup de courriels (dans les 15 000 courriels par jour pour nos services – inscriptions, notifications, etc. – et plus de 200 000 courriels par jour pour Framalistes) et nous en recevons aussi, que ce soit au niveau de notre serveur de courriel interne ou sur Framalistes. Il y a aussi quelques autres services qui permettent d’interagir par courriel comme notre forum, Framavox et Framagit.

Nous devons donc nous assurer, d’un côté, de ne pas passer pour des spammeur·euses et de l’autre, de nous en protéger.

Se protéger des spams par courriel

Rien de bien fantastique à ce niveau. Nous utilisons l’antispam Rspamd qui vérifie la validité du courriel par rapport à sa signature DKIM, à l’enregistrement SPF et à la politique DMARC du domaine (voir sur NextINpact pour un bon article sur le sujet). Bien entendu, cela ne vaut que si le domaine en question met en place ces mécanismes… On notera que la plupart des FAI français, s’ils vérifient bien les courriels entrants de la même façon que nous, se tamponnent allègrement le coquillard de mettre en place ces mécanismes pour leurs propres courriels. J’aimerais qu’un jour, ceux-ci arrêtent de faire de la merde 🙄 (remarquez, il semblerait que ça avance… très lentement, mais ça avance).

En plus de ces vérifications, Rspamd effectue aussi une vérification par filtrage bayésien, interroge des listes de blocage (RBL) et utilise un mécanisme de liste grise.

Il y a toujours, bien évidemment des trous dans la raquette, mais le ratio spam intercepté/spam non détecté est assez haut et nous alimentons Rspamd avec les messages indésirables qui sont passés sous le radar.

Sur Framalistes, afin de ne pas risquer de supprimer de messages légitimes, nous avons forcé le passage des spams probables en modération : tout message considéré comme spam par Rspamd doit être approuvé (ou rejeté) par les modérateur·ices ou propriétaires de la liste.

title.gettext test x-spam-status  header

match([header->Subject][-1],/\*\*\*\*\*SPAM\*\*\*\*\*/) smtp,dkim,smime,md5 -> unsure
true()                                                  smtp,dkim,md5,smime -> ham

match ([msg->spam_status], /unsure/)   smtp,dkim,md5,smime   ->   editorkey

Ne pas être considéré comme spammeur·euses

Là, c’est plus difficile. En effet, malgré notre respect de toutes les bonnes pratiques citées ci-dessus et d’autres (SPF, DKIM, DMARC…), nous restons à la merci de règles absurdes et non publiques mises en place par les autres services de courriel.

Vous mettez en place un nouveau serveur qui va envoyer des courriels ? Bon courage pour que les serveurs de Microsoft (hotmail.com, outlook.com…) l’acceptent. J’ai encore vécu ça il y a quelques mois et je ne sais toujours pas comment ça s’est débloqué (j’ai envoyé des courriels à des adresses chez eux que j’ai créées pour ça et je reclassais les courriels dans la catégorie « légitime », ça ne fonctionnait toujours pas mais quelques semaines plus tard, ça passait).

Votre serveur envoie beaucoup de courriels à Orange ? Pensez à limiter le nombre de courriels envoyés en même temps. Mais aussi à mettre en place un cache des connexions avec leurs serveurs. Eh oui : pas plus de X mails envoyés en même temps, mais pas plus de Y connexions par heure. Ou par minute. Ou par jour. C’est ça le problème : on n’en sait rien, on ne peut que poser la question à d’autres administrateurs de services de mail (pour cela, la liste de diffusion smtp-fr gagne à être connue. Le groupe des adminSys français, FRsAG est aussi à garder en tête).

Un autre problème est que nous ne sommes pas à l’origine du contenu de tous les courriels qui sortent de nos serveurs.
Par exemple, un spam arrivant sur une framaliste, s’il n’est pas détecté, sera envoyé à tou·tes les abonné·es de la liste, et ça peut vite faire du volume.

Les spams peuvent aussi passer de medium en medium : Framapiaf peut vous notifier par courriel d’une mention de votre identifiant dans un pouet (Ex. « Coucou @luc »). Si le pouet est un spam (« Coucou @luc, tu veux acheter une pierre magique contre les ondes 5G des reptiliens franc-maçons islamo-gauchistes partouzeurs de droite ? »), le spam se retrouve dans un courriel qui part de chez nous.

Certes, les courriels partant de chez nous sont aussi analysés par Rspamd et certains sont bloqués avant envoi, mais ce n’est pas efficace à 100 %.

Il y a aussi les faux positifs : que faire si nos courriels sont incorrectement classés comme spam par leurs destinataires ? Comme quelqu’un abonné sur une framaliste sans en être averti et qui d’un coup se retrouve submergé de courriels venant d’un expéditeur inconnu ?

Nous nous sommes inscrits à une boucle de rétroaction : nous recevons des notifications pour chaque courriel classé comme indésirable par un certain nombre de fournisseurs de messagerie.
Cela nous a permis (et nous permet toujours. Quotidiennement.) d’envoyer un message à de nombreuses personnes au courriel @laposte.net abonnées à des framalistes pour leur demander de ne pas nous mettre en indésirable, mais de se désabonner de la liste (en leur indiquant la marche à suivre) si elles ne souhaitent pas en recevoir les messages.

Au niveau de Framalistes, nous vérifions que les comptes possédant plus qu’un certain nombre de listes, et que les listes avec beaucoup d’abonné⋅es ne soient pas utilisées pour envoyer des messages indésirables. En effet, nous avons déjà souffert de quelques vagues de spam, nous obligeant à l’époque à modérer la création de listes en dehors des heures de travail car nous ne souhaitions pas, le matin, nous rendre compte que le service était tombé ou s’était fait bloquer pendant la nuit : l’envoi massif de courriels comme le faisaient les spammeur·euses rencontrait souvent un goulot d’étranglement au niveau du serveur, incapable de gérer autant de courriels d’un coup, ce qui faisait tomber le service.
Cette modération n’est plus active aujourd’hui, mais nous avons toujours cet outil prêt à être utilisé en cas de besoin.

Framalistes, si vous l’utilisez, a besoin de vous pour lutter contre le spam !

Petit rappel : il y a un lien de désinscription en bas de chaque courriel des framalistes. Utilisez ce lien pour vous désinscrire si vous ne souhaitez plus recevoir les messages de la liste.

Rien de plus simple que de déclarer un courriel comme étant du spam, n’est-ce pas ? Un clic dans son client mail et hop !

Eh bien non, pas pour Framalistes.

En effet, en faisant cela, vous déclarez notre serveur comme émettant du spam et non pas le serveur originel : nous risquons d’être complètement bannis et de ne plus pouvoir envoyer de courriels vers votre service de messagerie. De plus, l’apprentissage du spam (si le service de messagerie que vous utilisez fait bien son travail, les messages déclarés manuellement comme étant du spam passent dans une moulinette pour mettre à jour les règles de filtrage anti-spam) ne se fait que sur votre service de messagerie, pas chez nous.

Si votre liste reçoit des spams, merci de le signaler à nom_de_la_liste-request@framalistes.org (l’adresse pour contacter les propriétaires de votre liste) : les propriétaires de la liste ont la possibilité, sur https://framalistes.org/sympa/arc/nom_de_la_liste, de supprimer un message des archives et de le signaler comme spam non détecté (n’hésitez pas à leur indiquer ce lien).

Le spam sur Framapiaf et Framasphère

Point d’antispam comme Rspamd possible sur Mastodon ou diaspora* (techniquement, il pourrait y avoir moyen de faire quelque chose, mais ça serait très compliqué).

Les serveurs Mastodon (pas que framapiaf.org, celui de Framasoft) font régulièrement l’objet de vagues d’inscription de spammeur·euses. Pour éviter l’épuisement de notre équipe de modération, nous avons décidé de modérer les inscriptions et donc d’accepter les comptes un à un.

Nous nous reposons sur les signalements des utilisateur·ices pour repérer les comptes de spam que nous aurions laissé passer et les supprimer (ce qui est très rare) ou les bloquer s’ils proviennent d’autres serveurs avec lesquels nous sommes fédérés.

Framasphère ne dispose pas, contrairement à Framapiaf de tels outils de modération : pas d’inscriptions modérées, pas de blocage de comptes distants… Nous ne pouvons que nous reposer sur les signalements et bloquer les comptes locaux.
Nous arrivons tout de même à bloquer les comptes distants, mais cela nécessite de modifier un enregistrement directement en base de données.

UPDATE people SET serialized_public_key = 'banned' WHERE guid = 'le_guid_du_compte';

Le spam sur Framaforms

Framaforms a rapidement été victime de son succès : sa fréquentation a presque triplé entre 2019 et 2020 (et l’année n’est pas terminée !), devenant aujourd’hui le service le plus utilisé de notre réseau !

Nous n’avons donc pas remarqué la création de nombreux, trop nombreux formulaires proposant, par exemple, des liens vers des sites de téléchargement illégal de films. C’est d’ailleurs suite à une réclamation d’un ayant droit que nous avons pris conscience du problème (oui, nous avons fait suite à cette réclamation : quoi que nous pensions du droit d’auteur, nous nous devons de respecter la loi).

La lutte contre le spam a occupé une bonne partie du temps de Théo qui a temporairement rejoint notre équipe salariée pour prêter main forte sur Framaforms :

• détection de certains termes dans les formulaires avec mise en quarantaine (dépublication) en cas de suspicion de spam ;
• quarantaine des formulaires ne contenant aucune question (juste la description, quoi) ;
• interdiction de certains termes dans le titre des formulaires ;
• intégration d’Akismet (un service anti-spam en ligne, proposé par Automattic, la société derrière https://wordpress.com/, contributrice à WordPress) ;
• amélioration du système de CAPTCHA
• ajout de vues permettant une gestion plus aisée des formulaires par les administrateur·ices.

Les efforts de Theo ont porté leurs fruits : la détection automatique des spams et leur dépublication tout aussi automatique limitent la pollution présente sur Framaforms (ce qui évite les réclamations, donc de monopoliser l’attention d’un salarié pour y répondre) et l’interface de gestion des spams facilite grandement le travail des administrateur·ices.

Le spam sur Framagit

Nous avons beaucoup d’utilisateur⋅ices sur Framagit : nous avons dépassé les 90 000 inscrit⋅es. Mais pour notre malheur, la grande majorité d’entre elleux est constituée de comptes de spam !

Après des mois de ménage, nous sommes redescendus à un peu moins de 34 000 comptes, mais nous ne sommes pas dupes : il y a encore beaucoup de comptes illégitimes.

À noter cependant : ces comptes de spam ne semblent pas être dommageables pour les utilisateur⋅ices de Framagit. En effet, leur nuisance se limite généralement à mettre des liens vers un site de poker en ligne, de rencontres voire… de plombiers à Dubaï (je ne comprends pas non plus 😅).

Ceci explique en partie pourquoi nous n’avons pas lutté très activement contre le spam sur Framagit (l’autre raison étant que nous n’avions tout simplement pas de temps à y consacrer).

Nous avions déjà eu une vague de spams lors de l’ouverture de Framagit et nous avions dû interdire l’accès de notre forge logicielle à l’Inde, à l’Indonésie et au Viêt Nam, restriction active jusqu’à la semaine dernière.
Cela n’est pas dans nos habitudes mais s’il faut choisir entre ça et le risque d’épuisement professionnel d’un membre de l’équipe, Framasoft préfère faire passer l’humain avant tout (🤗).

Une grande vague de nettoyage a eu lieu en juin, où j’ai recherché des critères communs aux comptes de spam afin de les supprimer en masse… ce qui a donné lieu à une vilaine boulette lorsque j’ai choisi des critères bien trop larges, conduisant à la suppression de nombreux comptes légitimes (rétablis depuis).

Depuis, j’ai vérifié manuellement chaque compte remonté par mes recherches… soit plus de 18 000 comptes depuis septembre. Parmi ceux-ci, il devait y en avoir, à la louche (parce que mes souvenirs me trahissent), une ou deux dizaines de comptes légitimes. Heureusement ! Je crois que j’aurais assez mal pris le fait d’avoir vérifié chaque compte pour rien 😅

Nous avons désormais un script qui supprime automatiquement les comptes qui ne se sont jamais connectés dans les 10 jours suivant leur inscription : ce sont visiblement des comptes de spam qui ne reçoivent pas les mails de confirmation et donc ne se sont jamais connectés.
Ce script nous remonte aussi les comptes dont la biographie ou les liens contiennent certains termes usités par les spammeur·euses.

Nous avons recherché une solution de CAPTCHA pour Framagit, mais celui-ci ne supporte que reCaptcha, la solution d’Alphabet/Google… et il était hors de question de faire fuiter les informations (adresse IP, caractéristiques du navigateur…) et permettre le tracking de nos utilisateurs vers les services de l’infâme bête aux multiples têtes que nous combattons !

Nous avons alors recherché quelqu’un·e qui saurait développer, contre rémunération, une solution de type honeypot.
Dans le ticket que nous avons, sans aucune honte, squatté pour poser notre petite annonce, on nous a aiguillés vers une fonctionnalité d’honeypot expérimentale et cachée de Gitlab que je me suis empressé d’activer.
Il faut bien le dire : c’est très efficace ! Le nombre de comptes automatiquement supprimés par le script évoqué plus haut est descendu de près de 100 par jour à entre 0 et 2 comptes, ce qui montre bien que les scripts des spammeur·euses pour s’inscrire ne fonctionnent plus aussi bien.

Bien évidemment, il reste encore beaucoup de spam sur Framagit, et de nombreux comptes de spam sont créés chaque jour (10 ? 15 ? 20 ? Ça dépend des jours…), mais nous ne comptons pas en rester là. Le honeypot pourrait être amélioré, ou nous pourrions voir pour une intégration d’Akismet à Gitlab (il y en a déjà une, mais elle n’est pas utilisée pour vérifier les biographies des comptes).
Gitlab permet maintenant de modérer les inscriptions en les acceptant une à une (comme nous le faisons sur Framapiaf) : nous avons récemment activé cette fonctionnalité, pour voir si la charge de modération était acceptable et si cela avait un effet bénéfique.

Framalink

Nous recevons de temps à autre (bien moins ces derniers temps, fort heureusement) des mails indiquant que Framalink est utilisé pour dissimuler des liens de hameçonnage dans des mails.

Lorsque la vague d’utilisation malveillante s’est intensifiée, j’ai développé (et amélioré au fil du temps) quelques fonctionnalités dans Lstu (le logiciel derrière Framalink) : une commande pour supprimer des raccourcis, pour rechercher les raccourcis contenant une chaîne de caractères ou provenant d’une certaine adresse IP, un système de bannissement d’adresse IP, un système de domaines interdits, empêchant le raccourcissement d’URL de tels domaines, une vérification des URL dans la base de données Google Safe Browsing (lien en anglais) avant raccourcissement et même a posteriori (je vous rassure, aucune donnée n’est envoyée à Google, la base de données est copiée et utilisée en local).

Ces efforts n’ont pas été suffisamment efficaces et nous avons été obligés de couper l’accès à l’API de Framalink, ce qui n’est pas une panacée, mais tout cela a fortement réduit nos problèmes de spam (ou pas, mais en tout cas, on a beaucoup moins de mails nous alertant de l’utilisation de Framalink pour du hameçonnage).

Notez que c’est à cause de l’utilisation de Framalink à des fins malveillantes que ce service est souvent persona non grata chez Facebook, Twitter et consorts.

Framasite

Des framasites avec de jeunes filles dénudées qui jouent au poker avec des plombiers de contrées lointaines ? Eh bien non, même pas. Les spammeurs se contentent de créer des comptes dont le nom d’utilisateur·ice est du genre « Best adult dating site, register on… ».

Et tout comme sur Framagit, beaucoup de comptes créés ne sont jamais validés (vous savez, avec l’email qui dit « cliquez sur ce lien pour finaliser votre inscription » ?).

Heureusement que ce n’est que cela, Framasite n’ayant pas d’interface d’administration permettant la suppression propre d’utilisateur·ices (« propre » voulant dire avec suppression des sites créés). Une simple suppression des comptes illégitimes en base de données suffit à faire le ménage.

Framalibre

Framalibre est aussi sujet aux spams, mais il s’agit généralement là de notices de logiciels non libres. Soit les personnes créant ces notices n’ont pas compris que Framalibre n’était dédié qu’aux logiciels libres, soit elles ont essayé d’améliorer leur référencement en ajoutant leurs logiciels.

Pour une fois, ce n’est pas bien méchant, pas bien violent (cela n’arrive pas souvent) et la vigilance de l’équipe de modération permet de supprimer (manuellement) ces notices indésirables très rapidement.

WordPress (commentaires)

Les spams dans les commentaires d’un blog sont un graaaaand classique ! Nous avons opté, sur nos sites wordpress, pour les extensions Antispam Bee et Spam Honey Pot.

C’est plutôt efficace, il est rare qu’un spam passe à travers ce système.

Drupal (inscriptions)

Nous avons quelques autres installations de Drupal autres que Framaforms et Framalibre. Les spammeurs s’inscrivent, voient qu’ils ne peuvent rien publier facilement : les Drupal en question ont les inscriptions ouvertes pour une bonne raison, mais ne permettent pas de créer des articles comme ça, hop !

Ce n’est donc, à l’heure actuelle, pas gênant.

Notre formulaire de contact

« Un formulaire de contact ? Oh chic ! » se disent les spammeurs. Là aussi, nous recevons un certain nombre de spams, tous les jours, toutes les semaines (une quarantaine par semaine), ou par une ancienne adresse de contact.

Nous nous contentons de répondre « #spam » en commentaire du ticket créé dans notre RequestTracker : cela supprime le message et empêche son expéditeur·ice de nous envoyer d’autres messages (voir sur mon wiki personnel pour commander son RequestTracker par mail).

Les faux positifs

Je n’ai pas encore parlé des faux positifs : des messages légitimes détectés à tort comme étant du spam. Cela arrive forcément, quel que soit le type de plateforme, quels que soient les moyens déployés : statistiquement, il y aura toujours, un jour, une erreur du système ou des humain·es derrière (cf la boulette évoquée dans la partie « Framagit »).

Et dans l’autre sens, on aura toujours des spams qui arriveront à passer. Il est généralement difficile voire impossible de durcir les règles de détection de spam sans augmenter la proportion de faux positifs.

Conclusion

Il n’y en pas vraiment. La lutte contre le spam est un combat sans fin, un jeu du chat et de la souris qui ne se termine jamais. On tente de se protéger du mieux qu’on peut, on trouve des astuces, ça va mieux pendant un temps et ça recommence.

Il faut pas se le cacher : plus un hébergeur « grossit », plus il prend de la renommée sur Internet, plus il y a de chances que des personnes malveillantes repèrent son service et l’utilisent pour leur spam. Il y a donc un paradoxe de l’hébergement : trop petit, on est vite seul·e et débordé·e par la multiplicité des tâches à accomplir pour faire les choses correctement…

Mais trop gros, on centralise les attentions, dont celles des personnes malveillantes qui auront peu de scrupules à parasiter les ressources que vous mettez en commun. Ce qui induit encore plus de travail pour se protéger des spams et les nettoyer.

Ça vous paraît pessimiste ? Ça l’est un peu, sans doute ¯\_(ツ)_/¯

Et on vous explique un peu ce qui s’est passé.

Cela ne vous a peut-être pas échappé, Framapic, notre service de partage d’images, est subitement devenu indisponible le vendredi 17 août. Nous l’avons relancé lundi 24 septembre.

Nous ne l’avons pas coupé de gaieté de cœur, mais c’était soit la coupure du service Framapic, soit la coupure de l’IP du serveur, ce qui aurait entraîné l’arrêt de l’ensemble des services hébergés sur ce dernier.

Responsabilité du fournisseur de service

Nous avons déjà été contactés par diverses institutions ou organisations pour des problèmes de photos de drogue, d’armes ou de pédopornographie déposées sur Framapic.

Et oui, parmi ces institutions figurent des autorités judiciaires.

Il est de notre responsabilité d’hébergeur de réagir promptement aux demandes de suppression (lorsqu’elles sont fondées) ou aux requêtes judiciaires. Le problème est lorsque le demandeur contacte directement notre hébergeur, Hetzner. En effet, lorsque Hetzner nous transmet le signalement, celui-ci s’accompagne d’un délai d’une heure pour réagir avant la coupure de l’adresse IP du serveur.

Escalade

Au mois d’août, alors que jusqu’ici nous n’avions que peu de signalements, nous avons fait face à une vague de plusieurs signalements par semaine. Si nous avons toujours promptement réagi, Hetzner s’est lassé de ces signalements à répétition… et nous a laissé 24 heures pour migrer framapic.org hors de son réseau, avec toujours une menace de coupure.

Il fut donc décidé de mettre Framapic hors-ligne, de déplacer le nom de domaine vers un serveur situé chez un autre hébergeur et de ne fournir qu’une copie statique de la page de l’incident de notre site de statut : notre adminSys avait fini sa journée et commençait ses vacances… (il est quand même revenu sur le pont en urgence).

Toute requête demandant une image renvoyait (normalement) une capture d’écran du message de notre page d’incident.

Délai

Les vacances de l’adminSys se terminent, mais la rentrée ne commence pas par la remise en service de Framapic. Nous avons essayé de convaincre Hetzner de bien vouloir nous laisser remettre Framapic sur leurs serveurs, mais ce fut en pure perte.

Nous avons donc décidé de déplacer Framapic chez un autre hébergeur, avec un compte qui lui sera dédié afin de ne pas mettre en péril d’autres services si le cas se représentait.

Le rattrapage du travail en attente accumulé pendant les vacances a retardé la location du nouveau serveur… et ensuite il fallut attendre plus ou moins 24 heures que celui-ci soit mis à notre disposition (ce qui fut une surprise, habitués que nous sommes au quart d’heure maximum d’attente pour la même opération chez Hetzner).

Remise en service et limitations

Enfin, Framapic est de retour ! Mais pour éviter de nouveaux soucis, nous sommes obligés de mettre en place quelques limitations.

Ainsi, les nœuds de sortie du réseau Tor sont bannis. Il nous est douloureux d’en arriver là, convaincus que nous sommes de l’utilité de Tor pour des usages légitimes, mais comme un nombre conséquent de signalements concernaient des images envoyées via Tor, cette limitation s’est imposée.

Toute IP ayant envoyé une image ayant fait l’objet d’un signalement légitime sera définitivement bannie du service. Nous le faisions déjà quasi-systématiquement mais il nous arrivait d’oublier de le faire : certains signalements arrivaient pendant le weekend ou tard le soir, la priorité était la suppression des images signalées. Nous n’oublierons plus le bannissement.

Nous nous réservons le droit, si cela devenait nécessaire, de mettre en place d’autres types de blocage (geoIP ou autre joyeusetés), même si cela ne nous enthousiasme pas.

De l’intérêt des CHATONS

Framasoft a impulsé le collectif https://chatons.org justement pour éviter que les services proposés par notre association ne deviennent des “points centraux” du réseaux.

Ainsi, pendant la coupure de Framapic, vous pouviez toujours trouver d’autres chatons proposant un service équivalent (la recherche sur le site chatons.org retourne 14 membres proposant un tel service). Même si cette carte n’est pas forcément très à jour (hum), on peut rapidement trouver quelques services alternatifs, par exemple :

• https://pic.drakonix.net/ (Brest)
• https://wtf.roflcopter.fr/apps/ (Toulouse)
• https://pic.infini.fr/ (Brest)
• https://picat.drycat.fr/ (Nantes)

CHATONS est un collectif encore en construction, mais on voit ici tout l’intérêt de la décentralisation.

Ne dépendez pas de services tiers

Avant la coupure de Framapic, celui-ci faisait peiner le serveur sous le poids des nombreuses visites. Nous avions alors regardé d’où provenaient les requêtes en loguant les en-têtes Referer (et seulement cela, pour préserver votre vie privée, mais il fallait qu’on sache d’où venait le problème).

Quelle ne fut pas notre surprise lorsque nous nous sommes rendu compte que certains sites utilisaient Framapic pour stocker… les assets de leur site. Autrement dit, les images affichées sur le site web ne proviennent pas de leur hébergement (c’est à dire la machine hébergeant les pages web), mais sont récupérées depuis Framapic.org. Et il ne s’agissait pas que de blogs personnels, hein ! Des sites institutionnels en .gouv.fr utilisaient cette même mauvaise pratique ! (tous créés par la même entreprise qui n’a pas répondu à notre mail de contact leur demandant de ne pas le faire… mais qui a fini par cesser. Forcément, avec plus d’un mois d’images toutes cassées 😁)

Pourquoi cela est-il une très mauvaise pratique ?

1. si le site tiers est indisponible, comme ce fut le cas de Framapic, le site ne ressemble plus à rien (ce fut assez drôle de voir les sites institutionnels évoqués plus haut remplis de la capture d’écran de l’incident 😁) ;
2. si vos visiteurs bloquent les sites tiers avec une extension type uMatrix, le site ne ressemble plus à rien ;
3. dans le cas de Framapic, cela induit une forte charge sur notre serveur : en effet, les images sont déchiffrées (bien que nous ayons un système de cache, celui-ci n’est pas extensible à l’infini) et chaque visite implique des requêtes en base de données ;
4. sérieusement, mettre ses images sur le serveur du site ne le ralentira pas (à moins que vous n’hébergiez énormément d’images très lourdes).

Framapic a été pensé comme un moyen simple de partager des images (photos de vacances, captures d’écran…), ce n’est pas un CDN.

La morale de la fable

Nous espérons que ce petit article aura permis à certain⋅e⋅s d’apprendre au passage quelques petites choses sur les coulisses d’un service d’hébergement d’images et notre pratique à Framasoft :

• nous respectons la loi si un signalement est justifié ;
• dépendre d’un hébergeur revient à se soumettre à ses conditions — et à dépendre de sa disponibilité — d’où l’intérêt d’en choisir un avec soin (vive les CHATONS !), ou mieux, lorsque c’est possible, de s’auto-héberger ;
• notre Framapic n’est pas destiné à héberger des images qui s’affichent sur un site web.

Cet article fait écho à mon précédent article sur le pouvoir de nuisance des silos de mail.

Dans cet article, je pestais contre le pouvoir ahurissant que confère une grosse base d’utilisateurs à certains fournisseurs de mail (Gmail, Yahoo, etc).

En effet, il est quasiment impensable pour quiconque envoie des mails de passer outre leurs façons de faire, sous peine de se couper d’une grande partie des internautes.

Quand bien même on se conforme à leurs desiderata, quand bien même on met en place toutes les bonnes pratiques existantes, certains fournisseurs de mail ne font pas leur travail correctement…

Nota Bene : Framasoft n’est pas la seule structure à rencontrer les problèmes décrits ci-dessous. Des universités aux entreprises en passant par les google groups, on trouve des témoignages un peu partout sur le Web de mails qui n’arrivent pas à destination, et les administrateurs systèmes échangent souvent entre eux pour savoir si ça vient d’eux ou du serveur d’en face (vous aurez déjà deviné, d’après le titre de cet article, d’où vient généralement le problème).

Florilège

À tout seigneur, tout honneur, commençons par laposte.net.

laposte.net

La Poste avait tout pour fournir un service de mail propre et performant : son histoire dans les communications remonte à loin (on peut faire remonter sa généalogie au XVe siècle avec la première poste d’État de Louis XI) et si nous avons tous eu une lettre ou un colis qui s’est perdu dans les méandres des centres de tri, force est de constater que ça fonctionnait quand même très bien. En 2000, la Poste, encore entreprise publique, devait pouvoir fournir une adresse électronique à tous les Français⋅e⋅s.

Comment ne pas lui faire confiance ? Nous-mêmes, libristes avons, pendant longtemps, conseillé laposte.net à qui nous demandait un fournisseur de mail « propre », qui n’espionne pas les conversations, ne met pas de publicité…

Les choses ont bien changé.

Le prestataire de la Poste (ah bah oui, c’est un sous-traitant, vous n’imaginiez quand même pas que la Poste allait avoir des compétences en interne à l’heure des suppressions de postes de fonctionnaires ?) semble être, excusez le terme, un vrai branquignol : nous avons souvent des messages d’erreur comme 421 4.3.2 All server ports are busy (les serveurs ne sont pas correctement dimensionnés), 550 5.5.0 Service refuse. Veuillez essayer plus tard. service refused, please try later. LPN007_510 (« nope, on veut pas, revenez plus tard ») ou mon préféré, 451 4.7.1 Service unavailable – try again later (tout est vautré).

Ça fait des mois que les serveurs de laposte.net plantent régulièrement, avec en point d’orgue une panne qui a duré plusieurs jours en avril et une communication qui a mis plusieurs jours à arriver (un message pour dire qu’il y a un problème serait-il un aveu de faiblesse pour eux ?).

Résultat :

• les mails s’accumulent sur nos serveurs, et comme on retente de les envoyer pendant quelques jours, eh bien ça ralentit le traitement des autres mails (bon, maintenant, j’ai mis en place des mailqueues séparées, mais ce n’est pas quelque chose que je devrais avoir à mettre en place !) ;
• les utilisateurs ne reçoivent pas leurs mails de confirmation d’inscription à nos services ;
• qui les utilisateurs contactent-ils ? Ah bah non, pas le support de la Poste, ce serait trop simple. Non, non, c’est nous. Et c’est usant. Non pas de vous répondre, mais le fait que ce soit 95 % du temps la faute à votre fournisseur de mail qui ne fait pas correctement son boulot.

Orange (wanadoo)

Ah, Orange. Tout un poème…

L’opérateur historique qui, lui aussi, a bénéficié de son aura d’ancien service public pour capter une grande majorité des internautes français lorsque vint l’heure de se choisir son premier FAI. Du coup, beaucoup de personnes ont encore une adresse wanadoo. Et comme Orange est le FAI majoritaire en France, encore plus de personnes ont une adresse orange.

J’avais déjà parlé dans mon précédent article de sa sale manie de ne pas accepter qu’on lui envoie trop de mails en une seule connexion. Imaginez un quidam qui refuse que son facteur lui apporte plus de trois lettres par tournée. Le facteur doit donc se représenter plusieurs fois s’il a plus de trois lettres à délivrer. C’est débile. Orange fait ça, mais pour le mail.

C’est le seul fournisseur que je connaisse qui impose ce genre de limite (qu’on ne vienne pas me dire que c’est pour lutter contre le spam : comment font les autres ? Hein ? Orange n’aurait pas les capacités financières et techniques de lutter plus proprement contre le spam ?).

Heureusement, ça se règle facilement, mais tout de même.

Et puis, de temps en temps, pouf, il rejette nos mails à coup de 550 5.2.0 Mail rejete. Mail rejected. ofr_506. Pourquoi ? Va savoir. Et ça se débloque tout seul au bout d’un temps.

Free

Après l’opérateur historique, voici celui qu’on surnomme le trublion du net. De temps en temps, celui-ci semble modifier les règles de son antispam, et nous voilà avec des mails 550 spam detected, quand bien même c’est le 300e mail quasi identique que nous envoyons de la journée. Et puis ça s’en va et ça revient.

Pareil avec 451 too many errors from your ip, ça bloque de temps en temps et ça repart comme c’est venu… alors qu’il s’agit majoritairement de mails de notification (framapiaf, framasphere, framagit…) et donc que les adresses ont été vérifiées ! Certes, il peut y avoir des erreurs, mais tellement peu dans le volume de mails que nous envoyons à Free… Ça arrive vraiment de façon aléatoire. Grmpf.

Facebook

On l’oublie, mais Facebook, en 2010, a proposé d’avoir une adresse mail @facebook.com (bon, ils ont arrêté les inscriptions en 2014, ce qui explique l’oubli). Et certaines personnes utilisent encore ces adresses.

Nos mails étaient bloqués de temps à autre avec un code 554 5.7.1 POL-P4 Connection refused, ce qui veut dire en gros « Revenez dans 24 ou 48 heures ». En soi, ce n’était pas forcément délirant, si jamais nous avions, pour une raison ou pour une autre, envoyé beaucoup de mails d’un coup à leurs serveurs. Mais depuis quelques semaines, il n’y a plus de déblocage : nos mails ne partent plus pour facebook.com, même en les faisant partir d’un autre serveur ou en diminuant la vitesse d’envoi.

Voilà pour les fournisseurs de mails qui font n’importe quoi avec leurs serveurs. Ils présentent tout de même l’avantage de nous permettre de comprendre pourquoi les destinataires n’ont pas reçu leurs mails, fût-ce pour de stupides raisons. Mais il y en a de plus vicieux…

Ceux qui n’amènent pas les mails à leurs destinataires (ou qui les cachent)

On ne les connaît pas bien, ce n’est que lorsque l’on nous contacte pour et que nous voyons que le mail est bien parti qu’on les repère : les fournisseurs de mails qui acceptent nos mails mais, pour une raison ou pour une autre, les envoient rejoindre le grand rien.

Eh oui, nos mails disparaissent parfois sur le serveur de votre fournisseur de messagerie. Vous ne les trouverez dans aucun dossier, pas même dans les spams.

Il s’agit le plus souvent de choix algorithmiques du fournisseur : l’antispam est vraiment sûr que ce message est frauduleux ? Bah, pas la peine d’embêter l’utilisateur, on le jette ! (ce qui est stupide car ne permettant pas la correction des faux positifs par les utilisateurs).

Encore mieux, Gmail. Comme expliqué dans notre FAQ, si vous recevez un mail identique à un que vous avez envoyé, comme un message à une framaliste à laquelle vous êtes inscrit, Gmail cachera le mail reçu de la liste. Vous l’avez envoyé, vous en connaissez le contenu, non ? Ah, vous vouliez voir quand le message arriverait, histoire d’être sûr qu’il a bien été traité par notre serveur de listes ? Pas de bol.

Ceux qui proposent une application pourrie

Les personnes qui utilisent l’application de mail Orange sur leur téléphone ont des soucis pour envoyer des messages à des framalistes. Après investigation, nous nous sommes rendus compte que l’application met l’adresse de la liste (enfin un dérivé, elle met l’adresse dédiée à la réexpédition des mails reçus par la liste) dans l’en-tête Sender.

Que cela veut-il dire et pourquoi est-ce un problème ? Cela fait croire que le mail provient du serveur des framalistes. Comme notre serveur n’est pas stupide, voyant un mail provenant soit-disant de lui-même mais passant par un serveur non-autorisé à envoyer des mails framalistes, celui-ci refuse le mail. Tout simplement. C’est une des techniques classiques de lutte contre le spam que d’agir ainsi.

Conclusion

Les problèmes face aux gros silos de mail sont nombreux, et sont loin d’être tous dus à une mauvaise configuration de votre serveur mail que vous chouchoutez vous-même (ou de ceux que nous configurons… Non vraiment, c’est pas nous qui pondons de telles bouses ! D’où ce joli hache-tague : c’est #PasMonCaca).

Je pense personnellement et sincèrement qu’il y a une part d’incompétence de la part de ces silos dans un certain nombre de cas. Si tout le monde jouait le jeu correctement, le mail ne serait pas aussi compliqué qu’aujourd’hui.

Que pouvez-vous faire ? Eh bien, à part changer de fournisseur de mail (connaissez-vous les CHATONS ?), vous pouvez contacter le support de votre fournisseur actuel, lui expliquer la situation et lui dire que ce n’est pas normal. Nous pouvons vous fournir, le cas échéant, les codes d’erreur retournés par son serveur pour les mails que nous vous envoyons. Peut-être qu’en étant suffisamment nombreux à râler, la situation évoluera.

Fun fact : combien des fournisseurs de mail évoqués dans cet article permettent de contacter leur serveur de mail en IPv6 ? Un seul — je vous laisse chercher lequel 😁

(Et si vous vous posez la question, oui, les serveurs de framasoft.org et framalistes.org sont accessibles en IPv6, comme toute l’infrastructure de Framasoft. Quand on veut, on peut.)

Image d’en-tête par barefootcollege, source.

Non, nous n’allons vous parler de fibres (quoique). C’est du transit d’Internet que nous allons parler. Ou plutôt, nous allons laisser Stéphane Bortzmeyer en parler.

Son article nous a séduits, aussi bien par la thématique abordée (on ne se refait pas, quand les GAFAM menacent l’avenir d’Internet, on aime bien que ce soit dit 😃) que par son aspect didactique, truffé d’hyperliens permettant à tout un chacun de le comprendre. Nous le reproduisons ici, avec son aimable permission et celle de la licence (libre, bien sûr) de l’article, la GFDL et avec quelques photos en plus (dont un chaton, je viens de dire qu’on ne se refaisait pas 😁).

Stéphane Bortzmeyer est bien connu du milieu technique pour ses articles sur les RFC (Request For Comments) et autres articles techniques plutôt que pour des textes à destination de la famille Dupuis-Morizeau mais ses fiches de lecture pourraient bien les intéresser.

Le transit Internet est-il vraiment mort ?

À la réunion APRICOT / APNIC du 20 février au 2 mars, à Hô-Chi-Minh-Ville, Geoff Huston a fait un exposé remarqué, au titre provocateur, « The death of transit ». A-t-il raison de prédire la fin du transit Internet ? Et pourquoi est-ce une question importante ?

Deux petits mots de terminologie, d’abord, s’inscrivant dans l’histoire. L’Internet avait été conçu comme un réseau connectant des acteurs relativement égaux (par exemple, des universités), via une épine dorsale partagée (comme NSFnet). Avec le temps, plusieurs de ces épines dorsales sont apparues, l’accès depuis la maison, l’association ou la petite entreprise est devenu plus fréquent, et un modèle de séparation entre les FAI et les transitaires est apparu. Dans ce modèle, le client se connecte à un FAI. Mais comment est-ce que les FAI se connectent entre eux, pour que Alice puisse échanger avec Bob, bien qu’ils soient clients de FAI différents ? Il y a deux solutions, le peering et le transit. Le premier est l’échange de trafic (en général gratuitement et informellement) entre des pairs (donc plus ou moins de taille comparable), le second est l’achat de connectivité IP, depuis un FAI vers un transitaire. Ces transitaires forment donc (ou formaient) l’épine dorsale de l’Internet. Le modèle de l’Internet a été un immense succès, au grand dam des opérateurs téléphoniques traditionnels et des experts officiels qui avaient toujours proclamé que cela ne marcherait jamais.

Mais une autre évolution s’est produite. Les utilisateurs ne se connectent pas à l’Internet pour le plaisir de faire des ping et des traceroute, ils veulent communiquer, donc échanger (des textes, des images, des vidéos…). À l’origine, l’idée était que l’échange se ferait directement entre les utilisateurs, ou sinon entre des serveurs proches des utilisateurs (ceux de leur réseau local). Le trafic serait donc à peu près symétrique, dans un échange pair-à-pair. Mais les choses ne se passent pas toujours comme ça. Aujourd’hui, il est de plus en plus fréquent que les communications entre utilisateurs soient médiées (oui, ce verbe est dans le Wiktionnaire) par des grands opérateurs qui ne sont pas des opérateurs de télécommunication, pas des transitaires, mais des « plates-formes » comme les GAFA (Google, Apple, Facebook, Amazon). La communication entre utilisateurs n’est plus pair-à-pair mais passe par un intermédiaire. (On peut parler d’un Minitel 2.0.)

Bon, mais quel rapport avec l’avenir de l’Internet ? Mes lect·eur·rice·s sont très cultivé·e·s et savent bien que le Web, ce n’est pas l’Internet, et que le fait que deux utilisateurs de Gmail passent par Gmail pour communiquer alors qu’ils sont à 100 mètres l’un de l’autre n’est pas une propriété de l’Internet. (Les ministres et la plupart des journalistes n’ont pas encore compris cela, mais ça viendra). L’Internet continue à fonctionner comme avant et on peut toujours faire du BitTorrent, et se connecter en SSH avec un Raspberry Pi situé à l’autre bout de la planète (notez qu’il s’agit de l’Internet en général : dans la quasi-totalité des aéroports et des hôtels, de nombreux protocoles sont interdits. Et ces malhonnêtes osent prétendre qu’ils fournissent un « accès Internet »).

C’est là qu’on en arrive à l’exposé de Huston. Il note d’abord que les sites Web qui ne sont pas déjà chez un GAFA sont souvent hébergés sur un CDN [un réseau de diffusion de contenu, Note du Framablog]. Ensuite, il fait remarquer que les GAFA, comme les CDN, bâtissent de plus en plus leur propre interconnexion. À ses débuts, Google était une entreprise comme une autre, qui achetait sa connectivité Internet à un fournisseur. Aujourd’hui, Google pose ses propres fibres optiques (ou achète des lambdas) et peere avec les FAI : encore un peu et Google n’aura plus besoin de transit du tout. Si tous les GAFA et tous les CDN en font autant (et la plupart sont déjà bien engagés dans cette voie), que deviendra le transit ? Qui pourra encore gagner sa vie en en vendant ? Et si le transit disparaît, l’architecture de l’Internet aura bien été modifiée, par l’action de la minitélisation du Web. (Je résume beaucoup, je vous invite à lire l’exposé de Huston vous-même.)

Notez que Huston n’est pas le premier à pointer du doigt cette évolution. Plusieurs articles moins flamboyants l’avaient déjà fait, comme les déjà anciens « The flattening internet topology: natural evolution, unsightly barnacles or contrived collapse? » ou « Internet Inter-Domain Traffic ». Mais Huston réussit toujours mieux à capter l’attention et à résumer de manière percutante un problème complexe.

Alors, si Huston a raison, quelles seront les conséquences de la disparition du transit ? Huston note qu’une telle disparition pourrait rendre inutile le système d’adressage mondial (déjà très mal en point avec l’épuisement des adresses IPv4 et la prévalence du NAT), voire le système de nommage mondial que fournit le DNS. Le pair-à-pair, déjà diabolisé sur ordre de l’industrie du divertissement, pourrait devenir très difficile, voire impossible. Aujourd’hui, même si 95 % des utilisateurs ne se servaient que des GAFA, rien n’empêche les autres de faire ce qu’ils veulent en pair-à-pair. Demain, est-ce que ce sera toujours le cas ?

Mais est-ce que Huston a raison de prédire la mort du transit ? D’abord, je précise que je suis de ceux qui ne croient pas à la fatalité : ce sont les humains qui façonnent l’histoire et les choses peuvent changer. Décrire la réalité, c’est bien, mais il faut toujours se rappeler que c’est nous qui la faisons, cette réalité, et que nous pouvons changer. Essayons de voir si les choses ont déjà changé. Huston aime bien provoquer, pour réveiller son auditoire. Mais il faut bien distinguer l’apparence et la réalité.

Les observateurs légers croient que tout l’Internet est à leur image. Comme eux-mêmes ne se servent que de Gmail et de Facebook, ils expliquent gravement en passant à la télé que l’Internet, c’est Google et Facebook. Mais c’est loin d’être la totalité des usages. Des tas d’autres usages sont présents, par exemple dans l’échange de données entre entreprises (y compris via d’innombrables types de VPN qui transportent leurs données… sur Internet), les SCADA, BitTorrent, la recherche scientifique et ses pétaoctets de données, les réseaux spécialisés comme LoRa, les chaînes de blocs, et ces usages ne passent pas par les GAFA.

Peut-on quantifier ces usages, pour dire par exemple, qu’ils sont « minoritaires » ou bien « un détail » ? Ce n’est pas facile car il faudrait se mettre d’accord sur une métrique. Si on prend le nombre d’octets, c’est évidemment la vidéo qui domine et, à cause du poids de YouTube, on peut arriver à la conclusion que seuls les GAFA comptent. Mais d’autres critères sont possibles, quoique plus difficiles à évaluer (le poids financier, par exemple : un message d’une entreprise à une autre pour un contrat de centaines de milliers d’euros pèse moins d’octets qu’une vidéo de chat, mais représente bien plus d’argent ; ou bien le critère de l’utilité sociale). Bref, les opérateurs de transit sont loin d’être inutiles. L’Internet n’est pas encore réduit à un Minitel (ou à une télévision, l’exemple que prend Huston qui, en bon australien, ne connaît pas ce fleuron de la technologie française.)

Merci à Antoine Fressancourt, Jérôme Nicolle, Pierre Beyssac, Raphaël Maunier, Olivier Perret, Clément Cavadore et Radu-Adrian Feurdean pour leurs remarques intéressantes. Aucune de ces conversations avec eux n’est passée par un GAFA.

Cet article est distribué sous les termes de la licence GFDL

Stéphane Bortzmeyer

Crédits :

• Internet map 1024, Matt Britt, CC-BY 2.5
• Minitel, Nicolas Nova, CC-BY 2.0
• Grey fur kitten, Vadim B, CC0

La création d’un site web depuis votre compte Framagit est beaucoup plus souple, et c’est une belle victoire pour le libre !

Qu’est‐ce que GitLab Pages ?

À l’instar des pages Github, les pages GitLab permettent à toute personne possédant un dépôt sur une instance de GitLab de créer un site Web via un générateur de site statique (Jekyll, Middleman, Hexo, Hugo, Pelican…) et de l’héberger sur l’infrastructure dudit GitLab.

La compilation du site est effectuée lors du push vers le dépôt GitLab, via le système d’intégration continue de GitLab, puis le résultat est publié à l’endroit idoine pour être accessible via le Web. Il est possible d’utiliser un nom de domaine personnel (il n’est pas obligatoire d’utiliser une adresse du style https://username.gitlab.io), ainsi qu’un certificat personnel.

Et ça sert ?

Oui !

Les pages GitHub sont très souvent utilisées par les développeurs pour fournir une page de présentation de leurs projets, même les plus gros : Ruby on Rails, Django, React…

Les pages GitLab sont donc susceptibles d’être tout autant utilisées que les pages GitHub. La demande est là.

Mais on avait pas déjà un truc comme ça ?

Tout à fait ! J’avais créé Fs Pages pour fournir un service similaire mais plus limité que les Gitlab Pages car Gitlab ne souhaitait pas les intégrer à leur édition communautaire.

Il était possible de publier un site statique via Fs Pages mais la génération du site devait se faire avant de pousser le code : point de génération automatique. De plus, il n’était pas possible d’utiliser un nom de domaine personnel. Votre site statique répondait uniquement via l’adresse https://votre_utilisateur.frama.io.

Le long chemin de la libération

Nous n’allons pas refaire l’historique complet de la libération des Gitlab Pages, surtout que celui-ci est disponible sur LinuxFr. Mais un petit résumé succinct ne fera pas de mal.

Tout a commencé par un tweet de votre serviteur demandant à Gitlab s’il était envisageable d’avoir les Gitlab Pages dans l’édition communautaire de Gitlab (pas la peine de chercher les tweets en question, j’ai fermé mon compte twitter). Gitlab a ouvert un ticket pour discuter de cela.

Gitlab a exposé au fil du temps trois arguments :

• seules les fonctionnalités utiles aux instances de moins de 100 utilisateurs peuvent aller dans l’édition communautaire (et pour eux, cela n’était pas le cas de Gitlab Pages)
• https://gitlab.com, qui utilise la version entreprise — donc avec les Gitlab Pages — est libre d’utilisation pour tout un chacun, et contrairement à Github, les dépôts privés sont gratuits
• les Gitlab Pages sont une fonctionnalité qui ajoute une réelle plus-value à l’édition entreprise : comment vendre leur produit si une des fonctionnalités majeures est déjà dans l’édition communautaire ?

Il est à noter que Gitlab nous a proposé d’utiliser la version entreprise avec un rabais, ce qui est tout à leur honneur, mais comme nous ne souhaitons utiliser que du logiciel libre, nous avons décliné (évidemment 😀)

La communauté a fait valoir que Gitlab Pages n’intéressait pas que les grandes instances, qu’utiliser https://gitlab.com ou Github revenait au même puisque cela équivaut à utiliser du logiciel propriétaire, proposa un financement participatif pour financer la libération et enfin avança que les Gitlab Pages feraient une bonne publicité à Gitlab, les développeurs utilisant de plus en plus fréquemment ce genre de solution pour héberger leurs sites ou leurs blogs. Et même si j’ai horreur de cet argument de notoriété, force m’est d’avouer qu’il a su faire mouche (ainsi que les plus de 100 « 👍 » du ticket) : la libération fut annoncée peu de temps après celui-ci !

En tout, la discussion a duré près de onze mois. Les échanges furent cordiaux et la communauté, opiniâtre, a su faire valoir ses arguments.

Bref, une bien belle victoire pour le libre qui voit là un logiciel apprécié se doter d’une nouvelle fonctionnalité très attendue !

Bon, et maintenant ?

Depuis la mise à jour de Framagit du 2 mars dernier, toute personne possédant un dépôt sur Framagit peut, via les Gitlab Pages, créer et héberger un site sur notre infrastructure, que ce soit en sous-domaine de frama.io (comme moi 😊) ou avec un domaine privé (auquel cas il faudra faire pointer un enregistrement DNS vers les IPs de frama.io : 144.76.206.44 et 2a01:4f8:200:1302::44 ou créer un enregistrement DNS de type CNAME vers frama.io.), avec ou sans certificat.

La documentation de Gitlab sur l’utilisation des Gitlab Pages (en anglais) est très complète et propose même un grand nombre de modèles sur lesquels vous baser. D’Hugo à Pelican en passant par des pages statiques développées à la main, il y en a pour tous les goûts !

Il n’y a que deux ombres au tableau :

• l’utilisation de certificats Let’s Encrypt n’est pas aisée mais un ticket est ouvert chez Gitlab pour intégrer directement Let’s Encrypt aux Gitlab Pages
• il n’y a pas de redirection automatique vers la version sécurisée (https) de votre site, quand bien même vous fourniriez un certificat ou que vous utilisiez un sous-domaine de frama.io (ce qui vous fournit automatiquement une version https de votre site grâce à notre achat d’un certificat wildcard (certificat valant pour le domaine et tous ses sous-domaines)). Un ticket est cependant ouvert chez Gitlab à ce sujet. En attendant, pour rediriger vos visiteurs vers la version https de votre site, vous pouvez néanmoins inclure ce petit bout de JavaScript dans vos pages :

  <script>
  var loc = window.location.href+'';
  if (loc.indexOf('http://')==0){
      window.location.href = loc.replace('http://','https://');
  }
  </script>

Le framablog n’étant pas un blog technique, nous ne étendrons pas plus sur les ficelles de Gitlab Pages : on va laisser ça pour notre site dédié à la documentation de nos services.

Au 20 mars, nous sommes déjà 31 (oui, bon, ok, sur 7 560 utilisateurs, ça fait peu) à avoir commencé à bidouiller sur les Gitlab Pages de Framagit (contre 53 quand nous proposions FsPages). Continuez comme ça ! 🙂

Crédits image :

• Logo Framasoft : © JosephK, CC-BY-SA
• Logo Gitlab : © Gitlab, CC-BY-NC-SA 4.0
• Arithmetic symbols : Domaine public
• Love Heart : Domaine public

Warning : cet article parle de forge logicielle qui sert à développer collaborativement du code. Il est donc un peu velu et technique, mais il fera plaisir aux plus « barbu-e-s » d’entre vous !

Préviousselaid, chez Framasoft : nous avions besoin d’une forge logicielle comme outil interne à l’asso… parce que même si nous ne développons pas (ou exceptionnellement) de logiciel libre ; les mettre en avant, les améliorer (parfois), les promouvoir et ouvrir des services au monde, ben ça demande de créer, maintenir, échanger et améliorer du code !

Nous nous étions donc installé Gitlab à la main, sur un coin de serveur, juste pour nous…  Étant les seuls utilisateurs, on s’est dit que ce ne serait pas grave s’il n’était pas toujours à jour, à traquer la dernière version… (oui : nous sommes moins exigeants sur nos outils internes que pour les services que nous ouvrons au grand public ^^).

Franchement, merci Google !

Merci, parce qu’à chaque fois que vous prenez des décisions unilatérales aux dépens de vos utilisateurs-produits, vous nous offrez l’occasion de prouver que le Libre offre des alternatives bien plus respectueuses des personnes qui vous ont confié leur vie numérique (et leur code).

Le jour où nous avons appris que Google Code fermait ses portes, nous avons donc décidé d’ouvrir les nôtres. Cela nous a aussi permis de sensibiliser au fait que, dans le mode des codeurs et développeuses, GitHub est devenu un point central et monopolistique assez inquiétant.

Forcément, l’ouverture à tous de notre git et les nouvelles fonctionnalités des nouvelles versions de Gitlab (une nouvelle version tous les 22 du mois) nous ont incités à mettre à jour plus régulièrement, ce qui prend plusieurs heures à chaque fois… et plusieurs fois par mois, car des versions correctives sont régulièrement publiées.

Améliorer le Framagit… une priorité

Ceci, ajouté à l’utilisation grandissante de notre forge qui allait bientôt poser des problèmes de taille de disques, nous a amenés à migrer (le 17 mars dernier) notre Gitlab vers une machine avec plus de disque et surtout avec une installation utilisant les paquets dits « omnibus ».

Ces paquets omnibus nous ont permis d’installer Gitlab à l’aide d’un simple apt-get install gitlab-ce plutôt que de suivre la longue procédure d’installation manuelle. Non seulement l’installation est simplifiée, mais — et c’est surtout là la plus-value que nous en attendions — mettre à jour Gitlab devient tout aussi simple avec une seule commande apt-get dist-upgrade.

Résultat : notre Gitlab suit scrupuleusement la publication des nouvelles versions, avec leur lot de nouvelles fonctionnalités !

Pour fêter cela, nous avons étrenné un nouveau nom de domaine… inspiré par vous ! Avouons-le, «Git point Framasoft point orrrrrrrgueh », ça accroche un peu en bouche. De partout, nous avons entendu parler du « Framagit » : alors tant qu’à faire, autant l’appeler comme vous le faites déjà. Bien entendu, il n’est nul besoin de modifier vos URL, elles restent valides… mais la nouvelle est à votre disposition !

Et si on ajoutait de l’intégration continue ?

Derrière ce terme barbare se cache une fonctionnalité très pratique : on crée une « recette » qui sera exécutée dans une machine virtuelle à chaque push. Cela peut par exemple permettre de lancer une suite de tests pour vérifier que l’on n’a rien cassé. 🙂

Pour utiliser cette fonctionnalité, il faut disposer de ce que l’on appelle un runner, c’est à dire un logiciel qui va récupérer la recette et l’exécuter. Il est possible d’installer un runner sur n’importe quel ordinateur, même votre ordinateur de bureau.

Pour ceux qui ne souhaitent pas gérer leur runner eux-mêmes, Framasoft met à disposition deux runners partagés entre tous les utilisateurs de Framagit, que vous pouvez utiliser comme bon vous semble. Notez toutefois que Gitlab indique que quiconque utilise un runner partagé peut accéder aux informations des projets utilisant ce runner : il vaut mieux monter votre propre runner pour vos projets sensibles.

De plus, en utilisant les runners partagés de Framasoft, il est possible que votre projet soit mis en file d’attente, en attendant que les recettes précédentes aient fini de s’exécuter… à vous de voir !

Vous voulez des pages Gitlab ? Nous aussi !

Github permet à tout un chacun d’héberger un site statique. Gitlab propose une fonctionnalité similaire mais hélas, uniquement dans sa version entreprise… Nous utilisons pour notre part la version communautaire qui est la version libre de Gitlab… donc sans les pages Gitlab.

Nous avons donc ouvert un ticket pour demander que cette fonctionnalité soit incluse dans la version communautaire. Si vous aussi vous aimeriez voir cela arriver, aidez-nous tout simplement en votant sur https://gitlab.com/gitlab-org/gitlab-ce/issues/14605.

En attendant, profitez d’une forge logicielle à jour et libre sur Framagit.org !

Trouver des auteurs de logiciels libres, c’est relativement simple. Il n’y a qu’à se pencher sur un paquet Debian pour en trouver. Trouver des artistes qui mettent leurs productions sous licence libre, c’est déjà un peu plus rare.

Connaissez-vous David Revoy ? Non ? Et pourtant, vous avez sans doute déjà vu des projets auxquels il a contribué. Il a en effet travaillé (entre autres) à plusieurs projets de la fondation Blender : Sintel, Tears of Steel…

Mais c’est plutôt son webcomic Pepper & Carrot qui nous a poussés à l’interviewer. D’une rare qualité, les aventures de cette jeune sorcière et de son chat nous ont séduits, tant par les dessins magnifiques que par son humour.

Bonjour David. Tu peux te présenter un peu ? Ton parcours, ton travail, tes projets…

Bonjour, j’ai 34 ans et je suis un Montalbanais passionné de dessin et d’informatique depuis l’enfance. Au cours de ces quinze dernières années, j’ai eu un parcours de freelance passant par l’illustration (couverture de livre et jeu de société), par le concept-art (décors/engins et persos dans les jeux vidéos) et parfois par la direction artistique de projets.
L’an dernier, j’ai créé Pepper&Carrot, un projet de webcomic libre et open-source financé grâces au mécénat des lecteurs. Peu après et grâce au succès de la série, j’ai décidé d’arrêter le freelance pour me consacrer à plein temps à la création de nouveaux épisodes et aux extras (traductions, tutoriaux, wiki, téléchargements gratuits…).

Tu expliques sur ton site pourquoi tu as choisi l’Open Source. Tu peux nous faire un petit résumé pour nos lecteurs qui ne maîtrisent pas la langue de Shakespeare ?

Je vais essayer de résumer ça mais tout d’abord je tenais à vous remercier, car j’ai abordé le libre entre 2003 et 2005 grâce au portail de Framasoft d’il y a dix ans. A l’époque j’utilisais Windows XP et cela m’a permis d’adopter Blender, Inkscape, Firefox, LibreOffice et FileZilla. Mon abandon total des logiciels propriétaires s’est fait peu de temps après. Je venais d’acheter un nouveau PC livré avec ‘Windows Vista’ pré-installé. J’avais une licence ‘XP pro’ en boîte et je comptais réinstaller ce système car tous mes logiciels dépendaient de ce système. Malheureusement pour moi, la carte mère du PC Vista n’avais pas de pilote pour XP disponible et mes licences logicielles professionnelles (Photoshop, Painter, Manga Studio; plusieurs milliers d’euros) était toutes instables avec Windows Vista. Mettre tout à jour était très coûteux et n’apportait aucunes nouvelles fonctionnalités.

Cette stratégie de mise à jour forcée me paraissait injuste. Je ne voulais pas alimenter les créateurs d’un tel système avec mon argent. C’est donc cet événement qui m’a poussé vers le 100% GNU/Linux. Voici une vidéo d’époque :

Tu as travaillé sur pas mal de jeux vidéos. Pourquoi faire une BD ? C’était quelque chose qui te trottait dans la tête ou ça t’est arrivé comme ça ?

J’aime beaucoup les jeux vidéos et le cinéma d’animation, mais être auteur de bande-dessinée c’est mon rêve d’enfance. C’est la passion que j’ai toujours essayé de préserver. La BD, c’est l’art qui me touche le plus et celui dans lequel je m’exprime avec le plus de liberté. Pour la création de Pepper&Carrot, c’est vrai que c’est arrivé un peu « comme ça ». Tout a commencé un dimanche soir d’avril 2014 particulièrement calme, j’ai fait un speedpainting (une peinture numérique à la tablette graphique). J’ai enregistré ce qui ce passait à l’écran par coïncidence ce jour-là :

J’avais là une petite sorcière, un chat, une scène… La semaine qui a suivi j’ai ajouté d’autres cases et cela a formé une petite histoire. L’épisode 1 est né ainsi.

Ce petit projet personnel a eu beaucoup de succès, alors j’ai décidé de faire un épisode 2. Puis 3, puis 4… Ce mois-ci, je fais l’épisode 14. L’audience me porte par son enthousiasme. C’est ainsi qu’est né et continue de grandir Pepper&Carrot; un pas devant l’autre, très connecté au présent.

Tu utilises des logiciels libres ou open-source, mais lesquels ? Et qu’est-ce qui t’as décidé à libérer tes œuvres ?

J’utilise essentiellement Krita sur Linux Mint. Mes outils secondaires sont Inkscape, Blender, Gimp, Mypaint, G’Mic et Imagemagick.

J’ai commencé à libérer mes œuvres à la Blender Foundation quand je travaillais sur la direction artistique du court-métrage Sintel. C’était dans le cahier des charges de mettre tous les dessins préparatoires en Creative Commons Attribution. J’ai pu donc faire l’expérience directe de travailler avec cette licence très ouverte au sein d’une grande audience. L’expérience fût très positive. C’est ainsi que j’ai appris à connaître, et ensuite adopté les licence Creatives Commons.

Tes projets sont sous licence CC-BY, CC-BY-SA, CC-BY-NC-ND, copyright classique… Qu’est-ce qui détermine la licence que tu utilises ?

C’est déterminé par des préoccupations juridiques. D’abord il y a les dessins qui sont tellement « copyrightés » par mes clients que je ne peux ni en parler et ni même les montrer. Ce sont les contrats de jeux-vidéos, de cinémas sous NDA (Non Disclosure Agreement : accord de non-divulgation) que j’ai remplis durant mes années freelance. Les dessins « copyrightés » simplement sont ceux où je reçois l’autorisation d’afficher le dessin en basse résolution sur mon site.

La licence CC-By-NC-ND encourage le partage Internet mais empêche les travaux dérivés, les modifications et l’utilisation commerciale. J’ai longtemps utilisé ceci pour mes travaux personnels plus activistes comme pour le « Yin-Yang de la faim dans le monde ». Des groupements politiques m’ont déjà démarché pour détourner ou s’approprier ce dessin. Leur donner l’autorisation d’office serait trop dangereux.

La licence CC-By-Sa, c’est celle qui offre tout, mais demande la mise à disposition des sources de l’œuvre sur une licence également libre. Une façon de forcer l’évolution du libre à rester libre.

La licence CC-By, c’est quand je décide de tout partager, et de ne garder que le crédit participatif à l’élaboration du dessin. C’est la licence que je trouve la plus libre et aussi la licence que j’ai choisie pour tout Pepper & Carrot.

Il y a des personnes qui ne connaissent pas (encore) Pepper&Carrot… Comment tu les présenterais ?

Je les présenterais en BD, tel qu’ils le sont mais si je devais le faire avec que du texte, je passerais la main à ce petit texte issu de l’article de LinuxFr, par l’auteur Eingousef (édité par ZeroHeure, Yvan Munoz, BAud, M5oul, Benoît Sibaud et palm123 et modéré par ZeroHeure / Licence CC by-sa) :

Des personnages mignons, des chats, une influence manga/anime, de l’héroic-fantasy, des clins d’œil au logiciel libre, de l’humour décalé et de la poésie dans un univers épique, des licences libres et des sources complètes, des contributions à des logiciels libres et jeux libres… David Revoy a tout pour plaire aux geeks. Ce dessinateur aux multiples talents, qui s’est fait connaître dans la communauté du libre surtout par son impressionnant travail de concept artist sur les trois derniers Open Movies de la Blender Foundation (Sintel, Tears of Steel et le projet Gooseberry), s’est lancé l’année dernière dans la réalisation d’un webcomic libre, « Pepper & Carrot ». Celui-ci met en scène les aventures décalées de Pepper, une petite sorcière courageuse et casse-cou, mais qui a tendance à sous-estimer ses capacités, et de Carrot, son chat à l’intelligence quasi-humaine, mais éternel esclave de ses instincts, dans l’univers féerique du Royaume d’Hereva, avec ses villes volantes, ses fées, ses phénix, ses dragons-vaches, ses canards-drakes et ses sorcières rivales…

Le mode de financement de Pepper & Carrot est basé sur l’économie participative (Tipeee, Patreon, les dons…). Comment y es-tu venu ? Ça marche bien ?

J’y suis venu car je ne voulais pas proposer Pepper&Carrot aux éditeurs papier. L’édition est un milieu en crise que je connais assez bien grâce à mes années de travail dans l’illustration. Un univers ou la loi du marché prime sur tout. Pepper&Carrot aurait été sans doute dénaturé, standardisé, aseptisé et réduit au bon vouloir des commerciaux, des distributeurs, des actionnaires… du pognon pour le pognon. Quand on élimine la voie de l’édition classique, il ne reste plus grand chose pour exercer la BD à plein temps. Je ne suis ni riche ni « fils de » pour vivre de la BD sans en demander une contrepartie financière. J’ai un loyer mensuel à payer, un corps à nourrir, un matériel informatique à entretenir, donc solliciter le mécénat des lecteurs était ma seule possibilité.
De nos jours, ça marche grâce à la générosité des lecteurs. Financièrement, je suis loin de mes années freelance. Je gagne un petit SMIC pour autant d’heures de travail par semaine qu’il en est humainement supportable (sans congé, sans arrêts maladies, sans retraite). Mon projet en 2016 : arriver à maîtriser la production des épisodes et réduire les heures pour retrouver une vie personnelle en dehors de Pepper&Carrot (une coquetterie que je me suis refusée au cours des 15 derniers mois).

Tu as plein de rêves pour Pepper&Carrot… Comment t’es venue l’idée d’afficher ces douces ambitions ? Cette liste avance bien ?

Pour l’idée, je me suis dit que d’afficher clairement mes rêves et mes motivations aiderait les visiteurs du site à me connaître.

Est ce que ça avance ? Difficile à évaluer pour certain rêves. Par exemple pour le rêve numéro 1 : « Donner une conférence au Japon dans une convention Manga à propos de Pepper&Carrot » c’est super difficile à quantifier l’avancement de ce rêve. Mais j’ai déjà une piste ; j’ai reçu un email d’un lecteur Japonais avec les coordonnées d’un événement Manga qu’il connaît. Je vais donc bientôt constituer un beau dossier pdf pour essayer de démarcher cet événement. Quand au rêve « Atteindre l’épisode 100 ! », ce rêve est très quantifiable et avec la publication le mois dernier de l’épisode 13, j’en suis exactement à 13% !

Un petit mot de la fin ? Ou un dessin ? 😀

Un dessin bien sûr ! Merci pour l’interview !

Toutes les illustrations de l’article sont bien évidemment de David Revoy, en CC-BY 🙂

Nous l’avions dit lors de notre campagne de don 2013 : 2014 sera l’année du « Moins de Google et plus de Libre »

Un semblant de planning a été dévoilé dans le récent billet intitulé « Manger la pâtée de son chien ». C’est le 1er février que nous devions nous séparer de Gmail, et nous l’avons fait !

Nous sommes maintenant complètement autonomes pour la gestion de nos mails. Comme annoncé précédemment, nous avons choisi la solution BlueMind.

Il nous fallait un groupware pour remplacer Gmail : nous avions besoin de la gestion des mails, mais aussi de celle des agendas et des contacts, le tout en permettant le partage de ceux-ci, au moins entre nous.

Pendant notre recherche du Graal du groupware libre kivabien, nous en avons testé un bon nombre. Si certains n’étaient pas sans attraits, aucun n’avait la simplicité d’installation, de configuration et de maintenance de BlueMind tout en proposant une interface sympa et une synchronisation Exchange Active Sync^[1] sans devoir allonger la monnaie^[2].

Après avoir choisi BlueMind, un tweet de ma part nous a réservé une belle surprise : la souscription — facultative — auprès de BlueMind est offerte pour les associations du libre.
Même si nous étions partis pour nous débrouiller seuls, cette nouvelle était bienvenue car la souscription apporte un outil permettant de faire les mises à jour aussi simplement que l’installation^[3] (qui tient en deux lignes de commande).

Du temps en moins pour des mises à jour, c’est autant de temps en plus pour nos projets :D.

Bref, séduits par Bluemind, nous l’avons installé sur une machine virtuelle de notre nouvelle infrastructure^[4].

La formation des utilisateurs framasoftiens à la nouvelle interface ainsi que leur migration fut longue et pleine de mails de questions, de réponses, d’incompréhension… mais couronnée de succès.
La possibilité (récente) de pouvoir exporter sa boîte Gmail au format mbox a même donné lieu à une petite séance de modification d’un script python, IMAP Upload pour l’adapter aux labels de Gmail : les labels deviennent des dossiers lorsqu’ils passent dans gmail-mbox-to-imap et les mails y sont consciencieusement rangés. Peut-être ce script vous sera-t-il utile ?

Ce fut une belle migration. L’adminsys et le serveur se portent bien 😉 Nous pouvons donc aujourd’hui vous annoncer fièrement que nos mails sont libres et nous espérons que vous aurez envie de nous suivre dans cette voie.

Ce premier jalon dans notre entreprise de libération ne fait qu’ouvrir la voie à la ribambelle de changements que nous opérerons cette année.
Le prochain épisode sera celui du passage des Google Groups à notre propre serveur de listes de diffusion basé sur Sympa (1er mars si tout se passe comme prévu).

Librement,
Sky, pour Framasoft

Crédits photo:

• Capture d’écran : Sky, CC-0
• Chat dans un ordinateur : Tim Avatar Bartel, CC-BY