Ted écrit des trucs

Anonymiser des données pour de vrai avec la confidentialité différentielle

2024-05-13T00:00:00+02:00

En avril 2024, j'ai été invité par les équipes techniques de la CNIL pour donner une présentation sur la confidentialité différentielle lors d'un séminaire de recherche du LINC. La vidéo de cette présentation a été ensuite publiée en ligne. J'ai reproduit mes diapositives et la transcription de cette présentation ci-dessous, après quelques modifications.

Bonjour à toutes et à tous !

Je m’appelle Damien et j’ai une mauvaise nouvelle.

La mauvaise nouvelle, c’est qu’on peut pas prendre des données appartenant à des individus et publier ou partager des statistiques sur ces données, sans aussi révéler de l’information sur des individus spécifiques.

Ça, c’est une vérité fondamentale, qu’on peut formaliser et prouver avec des maths. Comme on m’a fait promettre de ne pas vous parler de maths, à la place, je vais vous donner deux exemples qui illustrent ce phénomène.

Supposons qu’on organise une conférence francophone de protection de données. On demande aux participants et participantes de remplir un formulaire où leur pose des questions comme « quel est votre pays d’origine ? ».

La conférence dure plusieurs jours. À l’issue du premier jour, on observe la distribution suivante. Il y a plusieurs personnes provenant de chaque pays, donc on se dit : « ce sont des données statistiques, pas individuelles, on peut sans problème les publier sur le site de la conférence ».

Le lendemain, il y a quelques nouveaux participants, donc les données sont mises à jour sur le site.

Moi, j’étais à la conférence, et je me souviens des données publiées la veille. Donc je peux calculer la différence des deux…

… et savoir qu’il y a exactement trois nouvelles personnes qui n’ont pas pu assister au premier jour.

Mais attendez une minute.

Une d’entre elles, je la connais — c’est une de mes collègues, arrivée aujourd'hui. Je sais qu’elle est française. Ce petit bout de données à gauche, ça correspond exactement à elle.
L’autre, c’est quelqu’un qui donne une présentation et qui s’excuse de ne pas avoir été là hier. Sa bio indique qu’il est belge, donc il est là dans les données statistiques.
Donc la troisième… Ça doit être cette autre personne dans l’audience, que je suis sûr de ne pas avoir vue hier. Je ne sais pas encore qui c’est, mais je viens d’apprendre qu’elle est Suisse.

Et ça… c’était pas vraiment supposé arriver. J’ai appris quelque chose à propos d’une personne unique, alors que tout ce qu’on a fait jusqu’à maintenant, c’est juste publier des statistiques.

C’est un premier exemple qui illustre la mauvaise nouvelle de tout à l’heure : on a fait fuiter de l’information individuelle sans le vouloir.

Vous allez me dire : « Damien, ton exemple est un peu tiré par les cheveux. Ce genre de truc, ça n’arrive pas dans la vraie vie. »

Laissez-moi vous parler du bureau du recensement américain. C’est l’équivalent de notre INSEE en France. C’est une agence publique qui collecte des données sur tout un tas de choses, y compris des individus, puis qui publie des statistiques démographiques et économiques sur le pays.

En 2010, ils ont, comme tous les 10 ans, publié un tas de statistiques démographiques. Combien de gens vivent à quel endroit, quels âge ils ont, quelles sont leur caractéristiques ethniques, combien y a-t-il de personnes par foyer, ce genre de chose. Plus tard, ils ont voulu estimer à quel point ces données pouvaient être réidentifiables.

Voilà un truc qu’on peut faire avec une grosse collection de statistiques.

On peut prendre chaque statistique et la voir comme résultat d’une équation à plein d’inconnues. On imagine chaque attribut de chaque individu comme étant une variable, un truc inconnu. Puis on se dit : on sait que la moyenne d’âge dans cette zone géographique, c'est 42,17. Ça veut dire que la somme de tous les âges (inconnus, donc), divisé par le nombre de personnes, c'est exactement 42,17. Et on fait ça pour toutes les statistiques. On obtient un gros système à plein d’inconnues. C’est une sorte d’énigme, un énorme puzzle.

Les puzzles, ça se résout ; les systèmes d’équation aussi. On peut mettre tout ça dans un gros algorithme pour faire ce genre de maths à grande échelle…

Et on obtient des données reconstruites. Un truc qui ressemble fichtrement à la base de données originale : une série d’informations qui correspondent à des individus uniques. Si ces données individuelles ont l’air d’être les mêmes que dans la base de données originale, c’est déjà assez suspect. Mais on peut faire pire.

Les données reconstruites ressemblent à la table en bas à droite. On a des informations géographiques et démographiques, mais on a pas de nom.

Mais on peut facilement trouver un autre jeu de données auxiliaires qui contient l’identité de certaines personnes, et certaines informations à leur sujet. Ce genre d’info, plein de gens peuvent l’avoir, par exemple votre employeur, vos connaissances, ou bien les services en ligne que vous utilisez.

On remarque un truc intéressant : certaines informations sont communes aux deux jeux de données. Donc on peut associer chaque ligne de la base de données avec un individu reconstruit à partir des données statistiques.

Mais on a un truc en plus dans les deux bases de données. Dans l’une, on a l’identité de chaque personne…

… dans l’autre, on a des information qu’on avait pas à l’origine. Ça, c’est une mauvaise nouvelle, parce que ça nous permet d’apprendre des informations sensibles, et nouvelles, sur des gens spécifiques.

Au sein le bureau du recensement américain, la possibilité et l’efficacité de cette attaque a été un véritable signal d’alarme. D’autant plus qu’ils avaient quand même essayé de protéger leurs données statistiques, en injectant un peu d’aléatoire dans certaines parties de leur processus. Mais ça a pas suffi.

Donc, c’est une illustration un peu déprimante de la mauvaise nouvelle de tout à l’heure.

Est-ce que tout est perdu ? Est-ce qu’il faut juste arrêter entièrement de publier ou de partager des données si on veut être sûr de ne rien fuiter ? Est-ce que finalement, l’anonymisation, c’est perdu d’avance ? Est-ce qu’on ferait pas mieux d’aller déménager en montagne et élever des chèvres ?

Peut-être pas. Parce que les mathématiciens et cryptologues qui ont formalisé cette vérité fondamentale ont aussi proposé une sorte de “lot de consolation”.

Ce lot de consolation, c’est un moyen mathématique de quantifier et de limiter cette fuite de données personnelles.

On se dit, bon, on peut pas avoir le beurre et l’argent du beurre. En tous cas, pas entièrement. Le mieux qu’on puisse faire, c’est un compromis entre “qu’est-ce qu’on publie comme données globales utiles” et “qu’est ce qu’on fait potentiellement fuiter sur des individus”. Et on peut quantifier ce compromis. On décider du niveau de risque qu’on est prêt à accepter.

On peut faire ça avec une notion qui s’appelle la confidentialité différentielle.

L’intuition de la confidentialité différentielle, c’est de prendre la perspective d’un type méchant qui essaie de deviner une information sur quelqu’un en particulier. Par exemple, est-ce que cette personne spécifique a un cancer. Au début, le type méchant est pas trop sûr si c’est le cas.

Si jamais il regarde le jeu de données qu’on a publié et qu’il peut répondre à cette question avec certitude, c’est une mauvaise nouvelle. On a fait fuiter des informations personnelles. Le type méchant a gagné.

Mais si, après avoir regardé les données qu’on a publié, le type méchant est toujours pas trop sûr de la réponse à sa question, alors c’est bien. Ça veut dire qu’on a pas fait fuiter de données. Enfin, non : on a dit tout à l'heure que c’était pas possible de ne rien faire fuiter. Ça veut dire qu’on a pas trop fait fuiter de données.

Comment on quantifie ça ?

On quantifie ça avec le langage que les mathématiciens utilisent pour parler d’incertitude : avec des probabilités. Ah non zut ! On avait dit « pas de maths ».

On quantifie ça avec le langage que les gens normaux utilisent pour parler d’incertitude : avec des paris sportifs.

On imagine qu’au début, notre type méchant n'a pas la moindre idée de si sa cible a le cancer ou pas. Si on lui demande de parier sur le sujet, il hausse les épaules, et dit : « Aucune idée. Je vais décider en tirant à pile ou face. Je suis prêt à parier 1€ pour gagner 1€ si j’ai raison ». C’est l’incertitude totale.

Maintenant, ça veut dire quoi si le type méchant a appris de l’information sensible avec un haut degré de certitude ? Ça veut dire qu’il est prêt à parier bien plus qu’il a raison. Il peut dire, par exemple : « Je suis quasiment sûr que ma cible a le cancer. je suis prêt à mettre 100€ sur la table et tout perdre si j’ai tort, tout ça pour ne gagner que 1€ si j’ai raison ».

À l’inverse, si le type méchant n’a pas appris grand-chose, alors il est peut-être prêt à mettre un peu plus sur la table — disons, 1,10€. Il a peut-être une raison d’être légèrement plus suspicieux que sa cible a le cancer, ou ne l’a pas, mais il reste quand même pas trop sûr. Son niveau d’incertitude a diminué, mais pas de beaucoup. Dans ce cas, on peut se dire : « C’est OK, on a pas trop fait fuiter de données ».

La confidentialité différentielle a plusieurs avantages majeurs.

D’une part, on ne suppose absolument rien sur le type méchant. La diminution d’incertitude dont je viens de parler correspond au pire des cas : il a accès à toutes les données auxiliaires qu’il veut, un ordinateur surpuissant, etc. On ne fait pas d’hypothèse sur quelle méthode précise il utilise pour arriver à ses fins. C’est du coup une définition très robuste: il n’y a pas de risque que quelqu’un découvre une attaque plus astucieuse dans six mois qui rende obsolète notre méthode d’anonymisation.
La confidentialité différentielle est la seule définition d’anonymisation qui permet de raisonner sur le risque cumulatif de plusieurs publications. Si je publie des statistiques sur des données une fois, et puis six mois plus tard je publie autre chose qui utilise aussi ces données, je peux quantifier le risque — la diminution d’incertitude du type méchant — des deux publications ensembles.
La confidentialité différentielle, c’est comme le chiffrement : comme c’est basé sur des maths, on peut être très transparent sur ce qu’on fait exactement aux données pour les protéger. Plus besoin de garder les détails du processus d’anonymisation secrets, comme c’est souvent le cas actuellement.
Enfin, pas mal de définitions alternatives ne fonctionnent que avec des cas d’utilisation simples, comme des histogrammes. La confidentialité différentielle, ça marche aussi pour faire des choses beaucoup plus compliquées, comme des médianes, du partitionnement de données, des algorithmes d’apprentissage…

Comment ça marche en pratique ?

C’est un peu comme le chiffrement : les techniques fondamentales reposent sur des maths assez simples, mais ça devient assez vite compliqué. Sans rentrer trop dans les détails, l’immense majorité des techniques qui permettent d’obtenir une propriété de confidentialité différentielle fonctionnent sur le même schéma.

On commence à partir de nos données sensibles.
La première étape, c’est de limiter à quel point chaque individu peut contribuer au résultat qu’on veut calculer. Par exemple, si on veut calculer la moyenne des salaires d’un groupe de personnes, il faut limiter le salaire maximal qu’on peut prendre en compte. Sinon, si Bernard Arnault fait partie du jeu de données, ça va être compliqué de cacher cette info.
Ensuite, on calcule ce qu’on veut calculer — typiquement, des statistiques.
Puis on va ajouter du bruit dans les données. On peut imaginer qu’on lance un dé et qu’on ajoute le résultat à ce qu’on a calculé jusqu’à maintenant. À la place de publier un salaire moyen de 2800 euros dans une certaine catégorie de la population, on va publier 2816, ou quelque chose de ce genre. L’idée est que le bruit “cache” la contribution de chaque individu. Plus il y a de bruit, moins les statistiques qu’on obtient sont précises, et mieux les gens sont protégés.
Une fois qu’on a fait tout ça, on peut publier ou partager les données qu’on obtient. Et on peut prouver que chaque individu est correctement protégé.

Je vous donne cette explication pour que vous ayez une idée des grands principes. Mais en pratique, est-ce que c’est ça qu’on fait ? Est-ce qu’on va, à la main, limiter l’influence de chaque individu, calculer des trucs, échantillonner des nombres aléatoires et les ajouter ?

Surtout pas.

La confidentialité différentielle, c’est comme le chiffrement. Même quand, sur le papier, ça n’a pas l’air très compliqué, le diable se cache dans les détails. Il y a un tas de problèmes d’implémentation pénibles avec la génération de nombres aléatoires, le calcul de l’influence de chaque individu pour des opérations compliquées, les imprécisions dûes à l’utilisation de nombres en virgule flottante, et tout un tas d’autres considérations pénibles.

Donc c’est une très mauvaise idée de réimplémenter ça tout seul, et c’est important d’utiliser un des outils conçus et maintenus par des expertes et experts qui prennent en compte et résolvent tous ces problèmes pour vous.

La startup pour laquelle je travaille développe un de ces outils, Tumult Analytics, qu’on utilise avec tous nos clients.

Avec mon employeur, Tumult Labs, on travaille avec plusieurs clients pour les aider à publier des données de façon sécurisée, avec de la confidentialité différentielle. J’ai mis quelques exemples en haut.

Plus qu’un outil, on a développé un processus en plusieurs étapes qu’on reproduit à chaque cas d’utilisation.

La première grande étape, c’est la conception. On formalise le problème : qu’est-ce qu’on essaie d’accomplir, quel est le but du projet, qui va utiliser les données en sortie. C’est là qu’on définit les indicateurs de réussite. D’un côté, quel est l’objectif de protection de données ? Quel niveau de confidentialité différentielle est acceptable ? Qu’est-ce qu’on essaie de protéger ? De l’autre, on sait qu’on va ajouter du bruit dans les données. Comment quantifier cette imprécision ? Quel type d’imprécision est la plus importante à limiter ? À partir de ces infos, on écrit un premier prototype qui génère les données qu’on veut.
On passe ensuite à la deuxième grande étape : l’optimisation. On génère des données avec notre prototype, et on regarde — est-ce que le niveau d’imprécision dans les données est acceptable ? Ou bien est-ce qu’il y a trop de bruit, au point que les données ne sont pas utilisables de la façon dont on aimerait ? Quel genre de biais on a introduit ? Généralement, la performance du premier prototype est pas terrible. Il faut donc optimiser notre approche, en changeant certains aspects de l’algorithme, et en sélectionnant des paramètres différents. Observez que les flèches vont dans les deux sens dans cette étape. C’est un processus itératif, où on se rend compte petit à petit de qu’est-ce qui marche bien. Parfois, on se rend compte qu’il y a un critère de succès auquel on avait pas pensé initialement, donc on révise nos indicateurs et on repart pour un tour.
Enfin, on finit par la phase de lancement, une fois qu’on a déterminé notre algorithme final. On écrit son implémentation, on la teste, on la documente, et on passe le tout en production.

Tout ça paraît peut-être encore un peu abstrait, donc laissez-moi vous donner un exemple du genre de résultat qu'on peut obtenir par l'application de ces méthodes.

Un de nos clients, c’est la Fondation Wikimédia, qui s’occupe de la gestion de Wikipédia et d’autres projets apparentés, comme Wikidata our le Wiktionnaire.

L’objectif du premier projet sur lequel on a travaillé avec eux, c’était de publier des statistiques du type — chaque jour, pour chaque article de Wikipédia, combien y a-t-il eu de personnes qui ont visité cet article. Avant notre collaboration, la Fondation pouvait ne publier ces statistiques qu’à un niveau global. Les statistiques par pays n’étaient publiées que lorsqu’elles étaient suffisamment grandes, et pas mal de gens — scientifiques, contributeurs, éditrices, etc., — leur avaient demandé de publier plus de données.

Après l'application de notre méthodologie, et en utilisant la bibliothèque logicielle que j'évoquais plus tôt, on a pu leur permettre de publier 40 fois plus de données qu’avant, 250 millions au total (et des centaines de milliers en plus chaque jour). On a aussi pu réduire le seuil auquel on publie des statistiques par un facteur 10, alors même qu’on a une définition d’anonymisation plus robuste.

Pour plus d'infos, vous pouvez consulter l'étude de cas que j'ai écrit à propos de ce project.

À propos d’anonymisation plus robuste. Comme je suis invité par la CNIL, je me suis dit que ça valait peut-être le coup de finir par un sujet peut-être un peu acrobatique…

… et c’est parler un peu de l’aspect légal de tout ce que je viens de vous raconter. Comment est-ce que les organismes de régulation définissent l’anonymisation de données ?

Voilà ce que la CNIL dit sur son site web. Il faut que la réidentification soit impossible, par quelque moyen que ce soit. C’est très bien, comme définition. C’est clair, c’est concis, ça ne fait pas dans la demi-mesure. Bon travail. C’est très clairement aligné avec la propriété dont je parlais tout à l’heure : la confidentialité différentielle ne fait pas d’hypothèse sur la façon dont les données pourraient être réidentifiées en théorie, donc on peut compter dessus pour capturer cette impossibilité fondamentale.

Le groupe de travail de l’article 29 précise qu’il faut qu’il y ait trois choses qui soient impossibles à faire avec des données anonymes.

L’individualisation, c’est le fait de pointer à un morceau de données et d’isoler une personne précise.
La corrélation, c’est de prendre deux données différentes et de pouvoir dire que ça provient de la même personne.
L’inférence, c’est d’apprendre une information nouvelle, de façon quasi certaine, sur un individu.

Là encore, c’est assez raisonnable. La partie sur l’inférence a des subtilités qui font que c’est pas si clair, mais je vais pas m’étendre dessus.

Au sein de la communauté des gens qui font de la communauté différentielle, il y a eu plusieurs efforts pour essayer de lier les deux mondes. À la fois expliquer en quoi certaines définitions satisfont (ou pas) ces critères, et les formaliser avec des maths. Il y a un vrai désir de combler l’écart entre les deux mondes, parce qu’on veut que notre travail soit utile au plus grand nombre.

Donc tout ça, c’est super chouette, la collaboration entre les deux mondes est excellente, et il n’y a rien à améliorer.

Sauf que… sauf que les autorités de régulation ne se contentent pas de décrire des buts, elles suggèrent aussi des moyens d’atteindre cet objectif d’anonymisation. Et c'est là que c'est moins enthousiasmant. À la fois dans l’avis du groupe de travail de l’article 29, dans ce qu’on lit sur les sites Web des différentes autorités de protection de données, et dans ce qu’on entend dans des conférences fréquentées par des juristes ou des régulateurs… c’est vraiment pas terrible.

D’abord, l’exemple typique qui est toujours présenté comme étant une bonne idée, c’est des définitions vieilles de plus de 25 ans, comme le k-anonymat, et ça on sait que c’est complètement cassé en pratique. Donc c’est pas terrible.
Mais le problème est plus profond: le modèle mental qui est typiquement présenté, c’est un modèle transformatif : on chaque donnée individuelle et on fait quelque chose avec. Par exemple, enlever certaines informations, ajouter du bruit à certaines valeurs, généraliser certaines catégories… Mais on sait que ce genre de mécanisme est très loin d’être robuste. Mieux vaut adopter une stratégie qui agrège des données de plusieurs personnes ensemble, et encourager les gens à publier des statistiques plutôt que des micro-données.
Il y a aussi un réel manque d’encouragement à faire évoluer les pratiques dans le bon sens. Le RGPD, à l’endroit où il parle de la sécurité du traitement, il dit de prendre en compte “l’état des connaissances”. L’endroit qui définit l’anonymisation dit qu’il faut tenir compte “des technologies disponibles au moment du traitement et de l'évolution de celles-ci”. Et… nous on essaie ! C’est ce qu’on fait toute la journée ! Mais c’est difficile d’avoir l’impression que de votre côté du monde, c’est la même chose. On a pas encore parlé à un client qui nous a dit “on a envie d’adopter la confidentialité différentielle parce que le régulateur nous y encourage”.

Comment on peut faire pour améliorer ça ?

Écoutez, j’y connais rien, donc c’est peut-être super naïf, mais : ça serait bien d’avoir plus de collaborations, et surtout que ces collaborations soient plus transparentes.

J'ai pu voir la différence que ça peut faire en comparant les interactions que j'ai eu avec des organismes publics de régulation d'un côté et de de l'autre de l'Atlantique.

J'ai fait des efforts pour lire ce que les différentes institutions européennes publient au sujet de l'anonymisation, mais ces documents me semblent toujours être mis en ligne à la toute fin du processus, sans qu'il n'y ait d'étape de collection de retours publics. Et quand c'est carrément à côté de la plaque — je pense par exemple à l'étude de cas sur la confidentialité publiée par l'ICO — envoyer des retours et suggestions a l'air d'être complètement inefficace.

Peut-être que je m'y prends mal car je ne connais pas assez ce milieu, mais je sais que les choses peuvent se passer très différemment. NIST, l’organisation pour la standardisation technologique aux USA, a récemment reçu l’ordre du gouvernement américain de publier un guide sur la confidentialité différentielle. Leur processus, c’est d’écrire un brouillon, de publier le brouillon, de demander à toutes les personnes intéressées de leur envoyer des retours et suggestions, d’avoir un gros dialogue pour décider quoi mettre dans la version finale, et de publier le résultat de ce processus.

Donc j’ai passé une semaine sur leur brouillon et je leur ai envoyé plein d’idées, et je vais les rencontrer en visio dans quelques semaines pour discuter de comment améliorer leur guide. Toutes mes contributions vont ensuite tomber dans le domaine public, et je vais pouvoir voir qui d’autre a contribué quelles autres suggestions. Je suis citoyen français, je vis en Europe, donc ça me paraît un peu fou que je puisse avoir une telle influence sur des documents publiés par des organismes américains, mais que l'UE me semble être une boîte noire complète.

Donc ma question ou requête pour vous pour conclure cette présentation, c’est… comment on met en place ce genre d’échange, de collaboration transparente et constructive sur les questions techniques, en Europe ?

Je suis sûr que je ne suis pas le seul intéressé !

Sur ce, merci pour l'invitation, pour votre attention, et d'avance pour vos questions ! Voilà mon adresse mail, et des liens vers mes profils LinkedIn et Mastodon si vous voulez rester en contact.

Faire marcher un Lenovo X1 Carbon sous Linux

2017-04-02T00:00:00+02:00

J'ai récemment acquis un Lenovo X1 Carbon, de quatrième génération. Je suis satisfait du matériel et déçu par son manque de compatibilité générale avec Linux. Globalement, tous les problèmes rencontrés sont résolubles (et ce billet détaille comment, pour ceux que j'ai eus), mais il y plein de choses qui ne fonctionnent pas magiquement du premier coup.

Les bons côtés

Matériel

Les specs sont enthousiasmantes (un SSD, ça change la vie \o/), et le produit fini est d'excellente qualité, comme le reste de la ligne ThinkPad.

Il est très léger pour un 14'' — lenovo.com annonce « Vous vous surprendrez […] à vérifier fréquemment si vous ne l'avez pas oublié ! », je confirme ^^
Il est solide et ne se pète pas au moindre choc.
L'écran mat a une résolution splendide, et reste lisible quel que soit l'angle où l'on se trouve.
Le clavier est confortable, le trackpoint aussi. Je ne peux pas commenter sur le pavé tactile, je ne l'utilise jamais.

La connectique est évidemment moindre que sur mon laptop précédent (beaucoup plus épais), mais est meilleure que nombre d'ultraportables : 3 ports USB, un HDMI, un MiniDP, un jack 3.5mm et un truc propriétaire pour mettre un dock. Suffisant pour une grande majorité d'utilisations. Pas de prise Ethernet, je pensais que ça me manquerait mais en pratique ça va, le Wi-Fi marche bien.

Le touchpad et trackpoint fonctionnent

Les deux fonctionnent sous Debian Testing sans que j'aie eu besoin de rien faire, y compris le mouvement "trackpoint + clic milieu" pour émuler la molette de défilement. Désactiver le touchpad se fait très facilement.

Les moins bons côtés

C'était pénible de parvenir à un système qui soit vraiment satisfaisant à utiliser au quotidien avec ma distribution favorite (Debian Testing).

Booter sur une clé USB était compliqué

J'ai essayé de suivre les instructions du wiki Debian mais ma clé USB n'était pas reconnue. Après pas mal de galère (j'ai essayé toutes les combinaisons possibles d'options dans le BIOS…), j'ai compris pourquoi : les 3 ports USB de ma machine sont en USB 3.0, mais son BIOS n'a pas les bons drivers… J'étais à deux doigts de booter sur Windows pour installer la version suivante de mon BIOS, et puis je me suis souvenu qu'on m'a fourni un dock OneLink+ avec ma machine, et que ce truc a (entre autres) une prise USB 2.0. J'ai pu brancher ma clé USB dessus, relier le dock à ma machine, et booter sur la clé \o/

Sans cette astuce, la solution standard semble être de mettre le BIOS à jour.

Le dock OneLink+ est tout pourri

Bref, mon université m'a fourni le dock OneLink+ avec mon laptop sans me demander mon avis, mais il n'est normalement pas compris dans le prix. Je déconseille fortement son achat. Il fonctionne très mal avec Linux.

Ça ne concerne pas vraiment le laptop lui-même, mais comme ça a l'air d'être le seul dock prévu pour le X1 Carbon et qu'un dock est un truc raisonnable à avoir quand on achète un ultraportable qu'on veut aussi utiliser au travail ou à la maison, je compte ça dans les points négatifs de la machine elle-même. Je me souviens de trois points problématiques, il y en a peut-être d'autres.

La prise jack marche par intermittence

PulseAudio a bien l'air de le reconnaître (pacmd list-sources renvoie bien une section avec "OneLink+" dedans) mais il faut parfois plusieurs essais pour que le son parvienne sur des enceintes branchées sur le dock. Et quand il n'y a pas de son qui sort, on entend un genre de bruit électronique désagréable.

Les prises vidéo ne marchent pas super bien

xrandr est extrêmement perturbé par le dock, et renvoie des sections qui ne correspondent à rien de branché. Trouver comment lui dire d'envoyer de la vidéo sur le vieil écran que l'on m'a filé à l'université était pénible.

La prise Ethernet ne marche juste pas

Les drivers sont pourtant supposés être disponibles… J'ai décompressé le bidule, l'ai installé, ai tout bien suivi les instructions, mais pas moyen que ça fonctionne (ifconfig ne le détecte désespérément pas). Comme on m'a aussi fourni un dongle Ethernet → USB, et que celui-ci fonctionne (même quand on le branche dans le OneLink+), j'ai pas cherché beaucoup plus loin. Note que le dongle en question n'est pas non plus super satisfaisant, cf. la section suivante.

Avalanche de messages d'erreur depuis le kernel

Une fois le système installé, j'ai eu le déplaisir de constater que ma console se faisait inonder sous les messages du noyau comme décrit dans ce bug, probablement causé par le dongle que j'utilise pour me connecter à Internet (pour une raison temporaire et tout aussi stupide). J'ai "résolu" le problème de façon temporaire en ignorant les messages du noyau.

Pas de Wi-Fi par défaut

apt-get install firmware-iwlwifi et redémarrer la machine a suffi à ce que ça fonctionne.

xbacklight ne fonctionne pas

Les instructions trouvées ici (créer un /etc/X11/xorg.conf avec ce qui va bien dedans) ont fonctionné.

Pas de son par défaut

Il a fallu que je passe à PulseAudio, alors que je m'en étais très bien passé jusqu'à maintenant. C'était en fait plus facile que ce à quoi je m'attendais, j'ai suivi le premier tutoriel que j'ai trouvé en ligne et ça a marché. Je crois me souvenir que sudo apt-get install pulseaudio pavucontrol a suffi.

Pas de Bluetooth par défaut

Internet m'a indiqué les bons trucs à installer : sudo apt-get install pulseaudio-module-bluetooth bluez-firmware blueman. Ça a eu l'air de marcher (on peut voir la liste des périphériques, etc.), mais en fait j'ai pas réussi à envoyer du son sur les enceintes Bluetooth que j'utilisais avant de faire pactl load-module module-bluetooth-discover et de re-faire l'étape de pairage.

Le lecteur d'empreintes digitales ne marche pas

Ça a l'air impossible de le faire fonctionner pour l'instant, et ça n'arrivera probablement pas dans un futur proche. Triste =(

Les touches multimédia doivent être configurées

Mais paraît normal, puisque j'utilise i3 comme gestionnaire de fenêtres. On peut trouver les codes des touches avec xev, puis leur faire faire ce qu'on veut dans .i3/config, c'est standard. Celle pour le Wi-Fi fonctionne sans avoir besoin de configurer quoi que ce soit (une fois le driver installé), et a l'air d'avoir le même effet qu'un toggle de rfkill sur l'interface Wi-Fi.

Parfois, les touches multimédia cessent complètement de fonctionner, et n'envoient plus rien de reconnaissable dans xev. Je n'ai pas réussi à trouver comment reproduire le bug de façon déterministe, mais il me semble que c'est encore un problème avec le dock. Tout débrancher, mettre le système en veille et le rallumer suffit généralement à ce que ça revienne.

La résolution de l'écran est vraiment grande

La majorité des logiciels sont inadaptés à l'écran HiDPI du X1 Carbon : LyX, Quod Libet, Firefox, etc., ont leurs textes et menus qui apparaissent minuscules. J'ai réglé ça en trois étapes.

J'ai ajouté xrandr --dpi 120 dans mon .xinitrc.
J'ai changé mes raccourcis pour ouvrir des terminaux pour afficher de plus gros caractères, et une belle police lisible et compacte.
Et j'ai installé l'extension Firefox AutoHiDPI pour avoir le DPI de Firefox qui change automatiquement suivant l'écran sur lequel la fenêtre se trouve (parce que mes écrans auxiliaires n'ont pas une telle résolution). Malheureusement, ça ne marche pas si deux fenêtres se trouvent sur deux écrans différents ; je n'ai pas de solution pour ça.

Conclusion

Si je devais me choisir une autre machine maintenant, il est probable que je regarde si il n'y a pas des laptops avec une meilleure compatibilité (en particulier avec des docks qui marchent mieux sous Linux). Mais il est assez possible que je prenne malgré tout le même modèle. Les problèmes sont pénibles, mais on finit par en venir à bout (et c'est satisfaisant quand ça finit par marcher :D) — je n'ai essentiellement plus de souci gênant avec cette machine. Et je suis carrément fan du matériel.

J'espère quand même que les modèles suivants de la ligne ThinkPad marcheront un peu mieux.

Passer d'OfflineIMAP à isync/mbsync

2015-05-26T00:00:00+02:00

Ça fait un petit bout de temps que j'en ai marre d'OfflineIMAP. À l'époque, la seule raison pour laquelle je l'avais choisi comme utilitaire de synchronisation IMAP, c'était sa position proéminente dans les résultats de recherche sur Internet. Puis, je l'ai gardé pendant longtemps par inertie, et parce que faute de point de comparaison, je ne savais pas si ce que je lui reprochais était inhérent à n'importe quel utilitaire du genre. Mes griefs principaux étaient les suivants :

c'est leeent (30 secondes pour synchroniser cinq comptes, en ne comptant pas le temps de téléchargement) ;
lorsque je n'ai pas de connexion Internet, ça devient vraiment lent, comme s'il ne comprenait pas qu'il était hors-ligne ;
lorsqu'on lance une instance d'OfflineIMAP alors qu'il y en a déjà une qui tourne, ça crée une situation chaotique et imprévisible, une sorte de deadlock (aw, Wikipédia me dit que ça s'appelle une « étreinte fatale » en français, n'est-ce pas adorable) qui nécessite souvent de tuer le processus à la main pour que ça aille mieux, et si on lance OfflineIMAP automatiquement toutes les deux minutes, ce genre de situation arrive souvent ;
puis, finalement, j'ai rencontré un bug incompréhensible qui m'a convaincu d'aller voir ailleurs si l'herbe était plus verte.

J'ai donc installé et fait marcher isync/mbsync (le premier nom est historique, le second est le nom de la nouvelle version de l'exécutable). Je ne sais pour l'instant pas si c'est significativement mieux qu'OfflineIMAP, mais ça a l'air rapide, les gens en disent du bien sur Internet, et surtout, ça a l'avantage de ne pas être OfflineIMAP.

Bref, voilà un mini-guide pour passer de l'un à l'autre. Mon .offlineimaprc ressemblait à ça :

[general]
accounts = damien
ui = quiet

[Account damien]
localrepository = damien_local
remoterepository = damien_remote

[Repository damien_local]
type = Maildir
localfolders = ~/Mail/ikura_damien/

[Repository damien_remote]
type = IMAP
ssl = yes
remotehost = desfontain.es
remoteuser = damien
remotepasseval = monsupermotdepasse
realdelete = no
cert_fingerprint = [plein de lettres et de chiffres]

et la section correspondante de mon .mbsyncrc ressemble maintenant à ça :

IMAPAccount dam
Host desfontain.es
User damien
Pass monsupermotdepasse
CertificateFile ~/Documents/cert-imap-ikura.pem

IMAPStore dam-remote
Account dam

MaildirStore dam-local
Path ~/Mail/ikura_damien/
Inbox ~/Mail/ikura_damien/INBOX

Channel dam
Master :dam-remote:
Slave :dam-local:
Create Both
SyncState *

et une fois que c'est fait, il faut bien sûr remplacer l'appel à l'exécutable d'OfflineIMAP par mbsync -a (typiquement, dans le crontab). Passons donc les configurations en revue pour comprendre comment traduire l'une en l'autre.

Trucs généraux

Pas mal de trucs ne nécessitent pas qu'on s'y attarde : j'imagine que vous aurez compris que les options basiques ont changé de nom, que la syntaxe diffère un peu. Les trucs nouveaux sont essentiellement le Create Both (qui signifie : quand y'a un dossier qui est créé en local, le créer aussi sur le serveur ; et de même dans l'autre sens) et le SyncState * qui dit de créer le fichier contenant les informations sur l'état des dossiers dans les deux sens dans un emplacement qui dépend du compte (~/Mail/ikura_damien/INBOX/.mbsyncstate dans mon exemple).

Configuration SSL

Mon serveur IMAPS utilise un certificat auto-signé, donc par défaut, mbsync (comme OfflineIMAP) va logiquement m'envoyer balader lorsque je vais essayer de m'y connecter. Avec OfflineIMAP, on pouvait indiquer un fichier .crt contenant le certificat en question, ou bien directement son empreinte.

Avec mbsync, on peut aller chercher le certificat et le mettre dans un fichier de la façon suivante :

openssl s_client -connect desfontain.es:993 -showcerts 2>&1 < /dev/null \
    | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
    | sed -ne '1,/-END CERTIFICATE-/p' > ~/Documents/cert-imap-ikura.pem

puis on indique CertificateFile ~/Documents/cert-imap-ikura.pem dans le fichier de configuration, et pouf ça marche. (Évidemment, il faut utiliser l'adresse de votre serveur imap à la place de desfontain.es — le port 993 utilisé est le standard 993, mais vous aurez peut-être aussi besoin de changer sa valeur par défaut.)

Les mots de passe en clair, c'est mal

Vous vous souvenez peut-être que dans un article précédent, j'expliquais que j'appelais un script Python depuis OfflineIMAP pour stocker mes mots de passe IMAP dans un fichier chiffré par GPG, et non pas en dur dans le fichier de configuration. mbsync ne sait pas appeler un script Python, mais il sait lancer une commande externe. J'ai donc transformé mon .offlineimap.py en un script indépendant, que j'ai rendu exécutable et que j'ai mis dans un dossier de mon $PATH, ce qui me permet de traduire mon remotepass = mailpasswd("damien") en un PassCmd "decryptpasswd.py damien" (qui remplace le Pass monsupermotdepasse précédent).

(Précision : le script decryptpasswd.py contient en dur le chemin du dossier dans lequel je stocke mes mots de passe chiffré : vous aurez probablement envie de changer ça avant de l'utiliser.)

Conclusion (Ajoutée en avril 2017)

Ça fait donc presque deux ans que j'utilise isync et j'en suis très content.

Les rares problèmes que j'ai eus sont arrivés avec une fréquence bien moindre que quand j'utilisais OfflineIMAP.
C'est beaucoup plus rapide, ça n'ajoute qu'une à deux secondes au temps nécessaire pour télécharger les nouveaux mails.
Ça arrive que ça échoue parce qu'il y a plusieurs instances qui tournent en même temps, mais c'est vraiment rare. Tuer toutes les instances de mbsync suffit à le refaire fonctionner.

Je recommande :-)

Pour envoyer des colis (notamment en Suisse), évitez EnvoiMoinsCher et Chronopost

2015-02-22T00:00:00+01:00

Cet article n'intéressera probablement pas les quelques gens abonnés à mes flux RSS, désolé ; je l'écris plus avec l'espoir qu'il apparaisse dans les résultats des moteurs de recherches lorsque des âmes perdues chercheront le nom de l'une des deux entreprises avec qui j'ai eu le malheur de traiter ces derniers mois. Quoique, l'histoire a un petit côté délicieusement kafkaïen qui peut, pourquoi pas, être vaguement divertissant.

J'ai déménagé en Suisse il y a quelques mois et j'avais quelques affaires à emporter, un peu trop pour les prendre simplement lors de mon voyage mais pas assez pour louer un camion de déménagement. J'ai donc tout mis dans trois cartons, cherché sur Internet quelles entreprises proposaient le transport de colis lourds et volumineux, et ai décidé de faire appel à EnvoiMoinsCher (envoimoinscher.com). J'ai suivi les instructions, ai donc joint une facture Proforma signée, en cinq exemplaires, décrivant de manière lapidaire le contenu des colis (du genre « habits, draps, ustensiles de cuisine, autres effets personnels ») pour la douane, et ai donné les colis à un employé de Chronopost le jour indiqué. Puis, j'ai attendu mes colis, qui ne sont pas arrivés : ils se sont fait bloquer à la douane suisse, car les douaniers archaïques de cet îlot au milieu d'une joyeuse zone de libre échange ont décidé que les colis étaient louches pour plusieurs raisons (ce que je n'ai pas compris tout de suite, faute d'informations pertinentes).

Dans l'ordre, voilà le torrent d'absurdités que j'ai subi au fil des semaines suivantes. Admirez l'incompétence chronique et systématique d'EnvoiMoinsCher et de Chronopost.

EnvoiMoinsCher m'envoie un mail lapidaire, quatre jours après avoir été prévenus par la douane que ma facture n'était pas valide, pour me dire simplement « Veuillez nous transmettre une facture Proforma signée », sans la moindre précision supplémentaire.
Lorsque je les ai appelés pour leur dire « heu, j'ai déjà joint une facture Proforma, c'est quoi votre problème exactement ? », on m'a dit « oh, ça a dû être arraché pendant le trajet ». Du coup, j'ai renvoyé la même facture scannée.
Silence radio pendant deux semaines. Pendant ce temps, j'ai essayé de les joindre par téléphone, de façon répétitive, sans succès. Puis, je joins directement Chronopost, qui a un standard téléphonique surtaxé mais au moins vaguement efficace, et ces gens-là (avec qui je ne devrais même pas avoir à traiter, ayant passé un contrat avec EnvoiMoinsCher) me disent qu'en fait, la facture n'est pas valable, il faut que j'en renvoie une beaucoup plus détaillée. Ils me disent avoir prévenu EnvoiMoinsCher, qui ne m'ont pas fait suivre l'information.
Je renvoie une facture absurdement détaillée (ce lien est hilarant, cliquez dessus) à Chronopost et à EnvoiMoinsCher, et je leur dis avec insistance « tenez-moi au courant, je suis à votre disposition si vous avez besoin de quoi que ce soit de supplémentaire ».
Silence radio. Nombreux appels téléphoniques, impossible d'avoir des infos chez Chronopost, quant à EnvoiMoinsCher, leur standard ne répond pas.
Dix jours plus tard, un employé de Chronopost finit par me dire que le colis a été renvoyé à son point de départ, dans mon ancienne résidence étudiante à Paris. En effet, la douane a demandé des informations supplémentaires (ils étaient visiblement perturbés par le fait que j'étais à la fois l'expéditeur et le destinataire des colis) comme une photocopie de mes papiers d'identité et de mon permis de séjour, Chronopost a fait suivre l'info à EnvoiMoinsCher, qui ne me l'a pas transmise. Au bout de quelques jours, les douaniers ont renvoyé le colis.

J'ai ensuite demandé à Chronopost s'ils ne pouvaient pas faire un geste humain et commercial en récupérant mes colis (encombrant la loge de ma résidence), ils m'ont dit qu'ils ne pouvaient pas faire ça, puisqu'ils n'avaient qu'un contrat avec EnvoiMoinsCher, je ne peux pas déposer de réclamation directement (ce qui est frustrant, mais un peu logique), et que comme la loge de ma résidence a « accepté » le retour, le dossier chez eux était clos.

Je me suis donc plaint par mail à EnvoiMoinsCher. Mon échange avec eux est reproduit par ici. J'ai commencé par expliquer pourquoi je m'estimais lésé et mis dans une situation épouvantable par leur faute, ils m'ont répondu en ne comprenant visiblement pas le problème (disant que c'était ma faute pour ne pas avoir fourni de facture correcte en premier lieu, alors même que leur site ne précisait rien de tout ça — théoriquement, nul n'est censé ignorer les réglementations douanières archaïques, d'accord, mais prétendre qu'il n'y a pas eu de problème de transmission d'information de leur part…), j'ai insisté avec toute la politesse dont j'étais capable en expliquant le problème, et ils ont quand même gentiment continué à m'expliquer que tout était de ma faute, qu'ils avaient déjà payé les frais de retour et que c'était déjà un gentil geste commercial de leur part, suivi d'un boilerplate commercial crétin insistant sur la qualité de leur service.

Je tiens mes promesses et publie cette histoire sur Internet. Je décourage à quiconque d'utiliser EnvoiMoinsCher, particulièrement pour envoyer des choses dans un pays ayant des barrières douanières. Ça doit probablement très bien marcher pour la majorité des gens dont les colis n'ont pas de soucis en route, mais ils sont dramatiquement incompétents et de mauvaise foi dès qu'un problème apparaît. Je me souviens les avoir choisis parce que c'était moins cher que de s'adresser directement à Chronopost ou à des entreprises similaires (je ne sais trop par quelle magie), mais le niveau de complexité supplémentaire apporté par le fait qu'on doit traiter avec deux intermédiaires au lieu d'un ne vaut clairement pas la légère différence de prix, surtout vu la nullité absolue et le manque de professionnalisme de l'intermédiaire supplémentaire.

Quant à Chronopost, malgré ma demande répétée de me tenir au courant, ils ont continué (à en croire les gens que j'ai eu au téléphone) de simplement mettre à jour le dossier partagé avec EnvoiMoinsCher au lieu de me prévenir directement de l'évolution de la situation. Par ailleurs, leur standard téléphonique pour les clients normaux est encombré et les gens qui répondent sont affreusement incompétents : il faut appeler leur standard pour entreprises, qui est surtaxé, mais qui a l'avantage de mettre en communication avec des gens qui savent un peu ce qu'ils font et qui font des efforts pour résoudre le problème (une voix automatique annonce « si vous êtes un particulier, appelez plutôt ce numéro » au début de la communication, ignorez-la).

Entreprises stupides, laissez-moi vous bouuuher un peu publiquement : bouuuh.

Pratiques commerciales du XXIème siècle, chapitre I : vente en ligne

2015-02-22T00:00:00+01:00

Salut, toi, commerçant-e ayant survécu à la révolution technologique des deux dernières décennies. Tu as probablement suivi les conseils de tes consultant-e-s en stratégie, ou bien tu as écouté tes enfants ou ton bon sens, et tu t'es muni-e d'une plateforme de vente en ligne. Tu penses donc avoir fait ce qu'il faut pour atteindre une large audience, comprenant entre autres la frange la plus jeune et la plus technophile du marché que tu cibles.

Cher site de vente en ligne, écoute-moi bien et crois-moi sur parole : tu as tort.

Considère la liste de points suivants. Pour chaque remarque te concernant, sois sûr qu'une quantité non-négligeable de tes clients te haïssent et ont proféré des torrents d'insultes à ton encontre (ou plutôt, à la machine qui sert d'intermédiaire entre eux et toi) à chaque fois qu'ils se sont retrouvés dans une situation frustrante canonique, dont j'ai essayé de dresser la liste (vraisemblablement non-exhaustive).

Ah, et par avance, pardonne-moi le franc-parler. Tu apportes à tes clients des heures et des heures de frustration, pour des stupidités que tu pourrais régler totalement en une quantité ridicule de travail de ta part, tu mérites qu'on te secoue un peu.

Livraison

Tu n'indiques pas clairement le prix de la livraison ? Le seul moyen de le découvrir est d'aller jusqu'au bout du processus d'achat ? Va crever. T'as un système de panier où tu peux voir le prix de ce que t'achètes au fur et à mesure, donc tu affiches le prix que ça va me coûter de passer à la caisse, livraison incluse, en permanence, à un endroit visible de mon écran. Tu modifies la foutue ligne de ton algorithme pour recalculer ça en permanence et tu ne me prends pas par surprise après m'avoir forcé à rentrer mes infos personnelles. Tu me laisses comparer le vrai prix que ça va me coûter d'acheter ça chez toi par rapport à chez ton concurrent, et tu me laisses faire ça rapidement.
Ah, oui, si en plus le fait d'aller à la fin du processus d'achat pour voir le vrai prix nécessite de se créer un compte sur ton site, crois-moi : y'a une place spécialement prévue en Enfer pour les gens comme toi. Avant ça, un avant-goût sur Terre s'appelle la faillite et le chômage, parce que personne n'a envie d'acheter quoi que ce soit chez toi, et tout le monde te hait.
Jackpot si en plus de ça, tu indiques fièrement que tu offres la livraison gratuite à partir d'une certaine somme (absurdement élevée). Si tu ne me dis pas quel est le tarif de livraison en temps normal, je ne peux que partir du principe que tu te fous ouvertement de ma gueule.
À propos de tes prix de livraison. Regarde-les, regarde-les bien. S'ils sont un centime de plus que ce que ça me coûterait à moi d'envoyer ta merde par la Poste, je te classifie instantanément comme un-e enfoiré-e malhonnête. Ta marge, tu te la fais sur le prix des produits. Si j'ai l'impression que tu veux te faire des sous en me sur-facturant des coûts fixes sous le qualificatif de « frais de port », ça te garantit 1) ma haine profonde et 2) le fait d'ignorer automatiquement ton apparition dans les comparateurs de sites marchands, puisque de toute façon je sais que tu vas essayer de m'arnaquer quand je vais vouloir payer chez toi.
Pas directement lié à la livraison, mais tant qu'on est sur les frais cachés de dernière minute : je sais. Tu paies une quantité de frais absurde aux gens qui gèrent ton système d'acceptation de cartes bancaires. Tant pis pour toi, t'avais qu'à accepter Bitcoin. En attendant, c'est ton problème, pas le mien, donc tu compenses sur la marge de tes produits et puis c'est tout. Si tu essaies de me faire payer une surtaxe à la fin parce que je paie par carte, tu peux te référer au paragraphe précédent pour connaître le fond de ma pensée sur tes pratiques d'escroc. Tout particulièrement si je n'ai aucun autre moyen de payer, auquel cas c'est du foutage de gueule assumé.
Tu n'affiches pas clairement où tu livres les produits que tu vends ? Au nom de tous ceux qui parlent ta langue et qui ont passé du temps à faire leur shopping sur ton site, avant de se rendre compte qu'en fait ils ne pouvaient pas être livrés, va au diable. Ça te prend deux minutes de faire un lien « Conditions de livraison » en bas de la page où tu détailles ça. Y'a pas que les gens vivant en France qui parlent français. Par ailleurs, si tu ne vends pas ailleurs qu'en France (ou dans le pays où t'es basé), une petite phrase expliquant pourquoi, et si c'est prévu dans un futur proche ou lointain, ça peut pas faire de mal.

Informations personnelles

Ma date de naissance ? Qu'est-ce que tu peux possiblement en faire, de ma date de naissance ? T'es de la police ? Tu veux pas mon numéro de passeport, tant que t'y es ? Crétin-e.
Tu veux mon numéro de téléphone ? Tu m'expliques pour quoi tu comptes t'en servir, et tu me laisses le choix de te dire « hey, je t'aime bien, mais en fait, va mourir, contacte-moi par mail si t'as besoin de me joindre, t'auras pas mon numéro de téléphone ». Sinon, tu vas récupérer un faux numéro. Je te le garantis.
Ah, tant que j'y suis. Ça devient rare, mais : un champ « téléphone fixe » obligatoire, vraiment ? T'es au courant que les années 90, c'est fini depuis 15 ans ?
Tu me vends un truc dématérialisé ? Je peux savoir pourquoi t'as besoin de mon adresse physique, du coup ? Pour rien, hein. Ouais, c'est ce que je me disais.
Tu ne me proposes pas de conserver mon numéro de carte bancaire pour la prochaine fois, à moins que t'aies une armée d'employés à plein temps qui s'occupent de sécuriser ton bordel. Et quand tu le fais, tu me fais comprendre clairement à quoi ça correspond (c'est pas pour moi, c'est pour mes aïeux) en termes de confiance, et pas juste en termes de « hihi, tu devrais carrément faire ça, c'est trop pratique pour quand tu reviendras, lol ».
Tu coches automatiquement la case qui dit en substance « je donne mon accord pour me faire spammer violemment jusqu'à la fin des temps » (je crois que le texte exact est généralement plus proche de « je souhaite recevoir des informations gnagnagna ») ? Sale petit-e vicieux-se retors-e, va brûler dans les flammes de l'Enfer.
Pour finir, je veux une option pour ne pas faire de compte chez toi, pour juste faire un achat unique, qui me garantisse que tu ne conserves pas mes données (et surtout que tu ne m'envoies pas de spam). C'est pas que je te fais pas confiance pour gérer mes coordonnées personnelles, mais je te fais pas confiance pour gérer mes coordonnées personnelles. Et vu à quel point le reste de ton site est moisi, j'ai de bonnes raisons de ne pas te faire confiance. Laisse-moi acheter un truc chez toi pour me convaincre que tu sais vaguement ce que tu fais.

Ergonomie

Un champ « confirmation d'adresse e-mail » ? C'est ta manière de me faire comprendre subtilement que tu me prends pour un demeuré fini ? Ou bien faire perdre du temps à tes clients, c'est juste ton petit fétichisme perso ?
Tu m'interdis de copier-coller dans le champ de confirmation en question ? Ah mais c'est même plus subtil, à ce niveau-là, c'est juste totalement assumé. « Non seulement t'es tellement stupide que tu devrais pas être autorisé à taper sur un clavier sans qu'on vérifie plusieurs fois ce que tu tapes, mais en plus, on veut être sûrs que t'es au courant qu'on te méprise et qu'on te crache à la gueule. »
Non, j'ai pas envie de sélectionner ma ville dans un champ déroulant. Durant le laps de temps nécessaire pour que ton menu optimisé à la tronçonneuse finisse de se charger (relancer le filtrage à chaque fois que j'ajoute une lettre, vraiment ?), j'ai eu approximativement dix-sept fois le temps d'entrer ma ville et mon code postal. Que je connais, par ailleurs, et que je n'ai donc pas besoin que tu vérifies. Me prendrais-tu pour un imbécile ? Impossible. Ça ne te ressemble pas.
T'as absolument aucune raison de me faire sélectionner le bon type de ma carte bancaire. Tu peux le déduire de son numéro. Hééé oui.
Ah, et quatre champs de quatre caractères chacun pour rentrer ledit numéro ? Vraiment ? Ça sert à quoi, à part m'empêcher de le copier-coller ?
Cliquer sur le bouton « précédent » pour revenir en arrière dans un formulaire fait planter intégralement le processus ? WHAT YEAR IS THIS?
Le champ « mot de passe » est automatiquement effacé lorsque j'ai mal rempli un bout de ton formulaire et que je dois le corriger ? Le mec qui a fait ton site, rassure-moi, c'était ton neveu lors de son son stage de troisième ?

Conclusion

En résumé : donne-moi toutes les informations dont je pourrais avoir besoin, le plus vite possible, demande-moi le strict minimum dont tu as besoin, et embauche des gens compétents pour faire ton site. Prends des gens au hasard, qui ne connaissent pas ton site Internet, donne-leur des tâches simples (acheter tel modèle de cafetière, comparer les différents produits de ta gamme, se renseigner sur le prix de tel produit tout compris…), et chronomètre-les jusqu'à ce qu'ils mettent autant de temps qu'ils en mettraient sur Amazon (sinon, je te garantis qu'ils vont aller sur Amazon). Écoute leur cris de rage et fais en sorte que tes futurs utilisateurs ne rencontrent pas les mêmes frustrations.

Et pendant que t'y es, va donc acheter des billets de train sur Capitaine Train, et prends-en de la graine. C'est à ça que ton site devrait ressembler.

Future research

Des articles similaires, sur le service après-vente à distance, et sur les sites Internet des commerces physiques, sont en préparation. Consolidez-vous.

Exhiber une proposition indémontrable « pour de vrai »

2015-02-14T00:00:00+01:00

tl;dr Ce code genère cette formule mathématique, qui est vraie, mais indémontrable dans l'arithmétique de Tarksi. Woo.

Il y a quelques années, j'ai lu Les théorèmes d'incomplétude de Gödel, un petit bouquin de Smullyan qui explique de façon claire et simple les théorèmes d'incomplétude de Gödel (incroyable, n'est-ce pas ?). À l'époque, j'en avais vaguement entendu parler, ça avait l'air fascinant, et j'avais envie de savoir comment ça marchait pour de vrai, et comment on pouvait construire en pratique l'étrange animal dont mon prof de maths de l'époque (béni soit-il) avait mentionné l'existence : une proposition mathématique vraie mais indémontrable, qui par une étrange pirouette arrive à exprimer exactement « je ne suis pas démontrable ».

Le bouquin est très bien écrit, mais c'était quand même un poil ardu pour le taupin que j'étais, du coup je le lisais par petits bouts et puis l'oubliais. L'été entre mes deux années de prépa, je me suis plongé dedans sérieusement, et ai décidé d'avoir une lecture un peu plus organisée. Et comme je ne suis pas doué pour prendre des notes, et que j'ai compris que la preuve se résumait à répondre à la question « comment construit-on la proposition étrange qui affirme sa propre indémontrabilité ? », je me suis dit que j'allais faire mieux que prendre des notes, j'allais écrire la proposition pas à pas.

Évidemment, comme le fait si justement remarquer David Monniaux dans un récent billet, la construction est longue et la proposition obtenue est « très long[ue], illisible pour un humain », il n'est donc pas question de le faire à la main. Du coup, comme à l'époque, j'étais aussi en train d'apprendre OCaml (tout seul, parce que ma prépa pensait que c'était une bonne idée de nous apprendre le Pascal en cours d'informatique), je me suis dit que j'allais écrire un programme qui faisait ça à ma place.

Du coup, c'est ce que j'ai fait. C'était effectivement fastidieux, ça n'a — pour reprendre les mots pleins de sagesse et de vérité de David Monniaux « pas grand intérêt », mais je me suis quand même amusé, et ça m'a permis d'avoir une idée plus "pratique" de comment ça marchait (vu qu'écrire un programme qui génère la proposition revient essentiellement à refaire toute la preuve étape par étape). Et sur les conseils d'amis qui m'ont prétendu que ça valait la peine de ressortir ça de mes dossiers poussiérieux, je me suis dit que j'allais le publier ici. Voici donc le code avec une jolie coloration syntaxique, et voilà le fichier original.

C'est loin d'être le code le plus propre du monde (hé, je débutais), mais c'est commenté de façon assez extensive, et je l'ai relu et ré-indenté récemment, donc ça Devrait™ être lisible. Je reproduis presque intégralement la preuve dans les commentaires, mais c'est probablement beaucoup plus compréhensible avec le livre sous les yeux. Il y a peut-être des erreurs qui ont survécu aux multiples relectures ; et comme ce n'est pas vérifié en Coq, c'est impossible d'être absolument certain que le résultat est bien indécidable.

À propos de résultat, voici la formule obtenue. Il y a plusieurs choses à dire à son sujet. L'alphabet utilisé est décrit dans le commentaire en haut du fichier .ml, mais je l'imprime en utilisant des raccourcis (pour les opérations arithmétiques, et surtout pour les numéros de variable), pour que ça soit (ahem) plus lisible. Les E et les A sont des quantificateurs (OCaml n'aime pas Unicode), respectivement existentiels et universels.

La taille de la chaîne de caractère imprimée est de l'ordre de quelques centaines de milliers de caractères. Ça n'a en fait pas grande signification, étant donné que les nombres sont codés en unaire et que je les imprime en binaire… La véritable taille est donc plus grande, mais en fait, beaucoup plus grand, parce qu'elle contient des constantes du genre 812939 qui codent "en dur" le numéro de Gödel de certaines propositions. Évidemment, la présence de ces grosses constante n'est pas nécessaire, on pourrait écrire à la place un terme plus court qui est égal à cette formule… Bref, on ne peut pas dire grand-chose d'intelligent de la taille de cette formule, à part « c'est probablement non-trivial d'arriver sous la centaine de milliers de caractères à coup d'optimisations mineures ».

(La question « quelle est la plus petite formule indémontrable » est, je pense (sans avoir le moindre morceau de science pour étayer cette hypothèse), indécidable — je doute qu'on puisse prouver d'une formule « ceci est la plus petite formule indémontrable » — mais ne serait-ce que savoir qu'une formule de, disons, quelques centaines ou milliers de caractères est indémontrable serait intéressant. Peut-être qu'une piste serait d'utiliser le théorème d'incomplétude de Chaitin et d'encoder la formule K(s) ≥ L dans notre langage pour un L assez grand.)

Avoir une bonne configuration SSL avec nginx

2015-01-16T00:00:00+01:00

Aujourd'hui, j'ai découvert le testeur de configuration SSL de Quarlys, qui vérifie automatiquement si un serveur donné est vulnérable à des failles classiques, ou a des problèmes de configuration. C'est intéressant de passer le site de sa banque, ou d'un autre site supposé sérieux et critique, au travers de cette moulinette — ma banque suisse obtient un B ; ma banque française un gros F bien rouge et bien déprimant.

Évidemment, vu que j'utilise SSL sur ce site (vous pouvez vérifier que https://desfontain.es fonctionne bien), j'ai voulu savoir la note que j'obtenais à ce test. Deux minutes plus tard, j'ai pu lire « C: This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C. ».

Fichtre. Allons donc joyeusement désactiver SSL 3, puisqu'il est troué, et n'autorisons que TLS. Ça se fait de la façon suivante. Il faut ouvrir le fichier contenant les règles de nginx (/etc/nginx/sites-enabled/default dans mon cas), et y ajouter une ligne entre la paire d'accolades commençant par server {, après les lignes qui parlent déjà de SSL (listen 443 default ssl & cie):

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

On redémarre nginx (en root, bien sûr):

service nginx restart

on repasse le test, et ce coup-ci, « A-: The server does not support Forward Secrecy with the reference browsers. Grade capped to A-. ». Hmmm. A-, c'est pas mal, mais c'est quand même significativement moins bien que A.

Surtout que la Forward Secrecy, c'est un concept plutôt cool qui permet d'avoir la garantie de sécurité suivante : si un attaquant récupère l'échange chiffré entre le client et le serveur ; et que plus tard il obtient la clé privée du serveur, il ne peut pas déchiffrer l'échange passé. C'est magique. Je ne sais pas comment ça marche. Mais ça crache du feu, et le fait que ça ne marche pas avec tous les navigateurs possibles est perturbant.

La raison est décrite par ce billet (en anglais) : les paramètres que nginx choisit par défaut pour le protocole sont ceux d'OpenSSL. Or, OpenSSL utilise par défaut une clé de 1024 bits ; tandis que le certificat qu'on utilise fait 2048 bits. Du coup, c'est pas compatible, et les clients vont utiliser un protocole moins cool qui n'a pas la propriété qu'on veut. On va donc générer des meilleurs paramètres à la main :

cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096

et dire à nginx de les utiliser en ajoutant ça au même endroit que tout à l'heure:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

et pouf, Forward Secrecy, ça c'est fait. Re-testons allègrement notre serveur après redémarrage de nginx… Ooooh, un joli « A » ! Joie, bonheur et allégresse.

Le billet que j'ai mis en lien un petit peu au-dessus a quelques sections supplémentaires. Par exemple, le petit bout suivant :

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.4.4 8.8.8.8 valid=300s;
resolver_timeout 10s;

active le « OCSP Stapling », une technologie permettant de mettre en cache dans le serveur la réponse de l'autorité du certification quand le client demande une preuve d'identification. C'est un peu comme si on était dans un pays étranger où à chaque fois qu'on rencontre un policier, il demande qu'on lui montre le tampon du pays sur notre passeport. Comme y'a beaucoup de policiers, au bout d'un moment, on en a un peu marre, surtout que le document est au fin fond de notre sac et que du coup, ça nous fait perdre du temps à chaque fois. La solution naturelle, c'est de s'agrafer une photocopie du tampon sur le manteau, comme ça le policier peut juste jeter un coup d'œil et être convaincu, et on perd moins de temps.

(Je sais. Cette analogie n'est pas parfaite. Mais elle est absurde, donc vous allez la retenir. Et de toute façon, vous avez probablement compris que vous pouviez tout aussi bien copier-coller tous les bouts de configuration de cet article dans votre configuration nginx sans vous poser tellement de questions, donc vous allez arrêter de m'embêter.)

Enfin, on peut ajouter quelques chouettes headers HTTP aux réponses qu'on envoie aux clients, pour améliorer encore notre configuration. La ligne suivante :

add_header Strict-Transport-Security max-age=63072000;

active le « HSTS » (HTTP Strict Transport Security), ce qui dit aux navigateurs qui vont sur notre site en utilisant la version HTTP non sécurisée par défaut « hey, y'a une version sécurisée, utilisez-la :D », et si ils ne sont pas trop stupides (erm Internet Explorer 6 erm), ils le font.

Remarque (merci à elarnon) : un inconvénient de HSTS, c'est que si jamais HTTPS ne marche pas pour une raison ou pour une autre (on a oublié de renouveler son certificat, le serveur OCSP ne répond plus, quelqu'un est en train d'essayer de faire un man-in-the-middle…), la version HTTP du site ne sera plus disponible. Ça n'est donc pas très adapté aux sites dont la disponibilité est capitale, mais qui ne gèrent pas de données critiques qui ne supporteraient pas d'être envoyés en clair. Bon, en vrai, si on fait attention à ne pas que son certificat expire, ça ne devrait pas poser de problème majeur.

Ce header-ci :

add_header X-Frame-Options DENY;

permet d'interdire que le contenu de mon site soit réutilisé tel quel dans une balise <frame>, <iframe> ou <object>, ce qui permet de se protéger contre les attaques par détournement de clic. Je… ne sais pas dans quel contexte une telle attaque pourrait avoir du sens sur mon brave petit site perso. Mais ça ne coûte pas très cher. Même remarque à propos de ce dernier header :

add_header X-Content-Type-Options nosniff;

qui permet d'éviter que des navigateurs essaient de deviner le type d'un fichier qu'on leur envoie en regardant son contenu, plutôt que le type de ses headers. Pourquoi ça a du sens de faire ça avec mon contenu, je n'en ai pas la moindre espèce d'idée, parce que (pour autant que je sache) je documente bien le type de mes fichiers avant de les envoyer sur mon serveur, mais oh well.

Je vous ai probablement perdu. Ou vous lisez ces lignes après avoir parcouru les deux tiers de cet article sans le lire. Je ne vous en veux pas. Passez une bonne journée ! =D

Comment renouveler le certificat SSL utilisé par Postfix

2014-10-21T00:00:00+02:00

J'ai dû renouveler le certificat SSL de mon serveur mail (qui tourne grâce à Postfix) aujourd'hui. On trouve des tutoriels sur Internet pour configurer un serveur mail, mais évidemment, un an plus tard, lorsqu'il s'agit de rebidouiller parce que le certificat utilisé arrive à expiration, on passe un bon quart d'heure à chercher et parcourir de longs tutoriels pour trouver un petit bout d'information pertinente. Voilà donc le petit bout en question.

L'autorité de certification qui vous a fourni un certificat vous a envoyé un mail vous disant qu'il fallait le renouveler, vous avez cliqué sur le lien, suivi les instructions, et obtenu un joli bloc de texte qui ressemble à :

-----BEGIN CERTIFICATE-----
MlfjmdCCA+2gAwIBAgVQQ7zoZN0GCSqGSIb3DQEBDDHNZUxkRQNOBgNVBAoTB1Jv
[quelques dizaines de lignes inintelligibles du même genre]
2gAwIBAgVQQ7zoZN
-----END CERTIFICATE-----

et vous vous demandez ce que vous devez en faire. Allez donc voir dans le fichier de configuration de Postfix (/etc/postfix/main.cf sur Debian), et cherchez la ligne qui commence par smtpd_tls_cert_file =. L'emplacement indiqué par cette valeur, c'est le fichier dans lequel il faut mettre le certificat. Chez moi, ça ressemble à :

smtpd_tls_cert_file = /etc/postfix/tls/server.crt

il faut donc que je fasse une sauvegarde de ce fichier, et que je remplace son contenu par le bloc de texte donné par l'autorité de certification. Après avoir redémarré Postfix (service postfix restart), pouf ça marche.

Remarque potentiellement importante : dans des configurations (comme la mienne) où l'empreinte du certificat est stockée en dur sur un client particulier (par exemple, j'ai un tls_fingerprint 5D:7C:… dans mon .msmtprc), il faut bien entendu renouveler cette empreinte. On fait ça avec :

openssl x509 -in /etc/postfix/tls/server.crt -sha1 -noout -fingerprint

et l'on peut copier ce qui est renvoyé après le = dans le morceau de configuration en question.

Stocker des Bitcoin de façon sûre

2014-09-09T00:00:00+02:00

J'ai eu la chance d'entendre parler de Bitcoin assez tôt, et de m'y intéresser assez pour être rapidement enthousiasmé par les possibilités et (à mon humble avis) le potentiel disruptif de cette technologie. En conséquence, j'ai acheté quelques Bitcoin à l'époque où ils ne valaient pas encore grand-chose, et au fil des mois, je me suis rendu compte que vu leur valeur, il faudrait peut-être que je les stocke (au moins en partie) de façon un peu sécurisée. Je me suis renseigné et ce billet décrit la solution que j'ai choisie, qui est assez peu commune pour que ça vaille la peine que je la détaille en français, et assez élégante pour que je puisse l'exposer publiquement sans avoir peur que l'on se serve de ces informations contre moi.

Note : si vous ne connaissez pas bien le fonctionnement des Bitcoin, la seule chose qu'il est nécessaire de savoir pour comprendre cet article est la chose suivante. Les Bitcoin (qui ont de la valeur monétaire, donc que l'on veut protéger contre les incendies et les pirates, et transmettre à nos proches en cas d'accident) sont stockés sur des adresses, et pour pouvoir les utiliser, il faut en avoir la clé privée. Stocker des Bitcoin se résume donc à stocker une clé privée, qui est essentiellement une chaîne de caractères — ou, parce que c'est plus pratique, un QR code :

(pas la peine de vous embêter, il n'y a rien dessus).

Le problème

Je voulais que mon système réponde à trois critères essentiels :

être résistant aux attaques extérieures — par « attaques », j'entends aussi bien un piratage d'un ou plusieurs de mes appareils qu'un possible vol de mes affaires ;
être sûr, c'est-à-dire que je veux minimiser les risques que je perde l'accès à mes Bitcoin — par exemple, en cas d'oubli de mot de passe, de mort d'un disque dur ou d'un autre type d'accident compromettant l'intégrité de mes données ;
et être résilient, c'est-à-dire que si je meurs, je veux être sûr que quelqu'un de confiance puisse y avoir accès.

Malgré ce que peuvent dire d'un ton emphatique les évangélistes du monde du Bitcoin, c'est très loin d'être évident de trouver une solution qui satisfasse tous ces critères d'un coup. La solution classique se base sur un mot de passe complexe et un chiffrement de portefeuille (en général avec BIP-38), mais je trouve que ça a un inconvénient assez majeur : si le mot de passe est assez complexe pour qu'il ne soit pas devinable par un attaquant, il faut soit le noter quelque part, soit devoir le retenir.

Dans le premier cas, on prend le risque de se faire voler le papier en question, ou bien qu'il soit détruit dans un accident — et si on l'écrit sur plusieurs papiers, on diminue le second risque en augmentant le premier. Ou alors, on fait appel à quelqu'un dont c'est le métier de garder des documents précieux (dans un testament chez le notaire ou dans le coffre d'une banque), mais ça tue un peu le principe d'une monnaie décentralisée que l'on peut utiliser sans intermédiaire.

Dans le second cas, il faut avoir une confiance absolue en ses propres capacités de mémorisation, ce qui me semble un peu trop optimiste (un accident qui fait subir un choc au mauvais endroit du cerveau est vite arrivé), et ça ne satisfait pas mon troisième critère.

La solution naturelle est de séparer l'information « clé privée chiffrée » avec « mot de passe de la clé ». Mettre le QR code de la clé chiffrée à plusieurs endroits sûrs, et retenir le mot de passe, en faisant aussi une sauvegarde du mot de passe dans (au moins) un endroit sûr, différent de l'endroit où a mis la clé chiffrée (évidemment). En se débrouillant pour qu'en cas d'accident, nos proches puissent avoir accès à ces deux informations.

Une politique classique en termes de sauvegardes considère que pour être sûr de ne pas perdre une donnée, il faut en avoir trois copies à trois endroits différents, sur au moins deux supports distincts. Dans notre situation où l'on a deux informations qui ne doivent pas se « toucher », il faut donc six lieux de stockage entièrement séparés si on veut avoir une sécurité correcte. Aucun, bien sûr, ne doit être connecté à Internet : on veut avoir la certitude que si une donnée est compromise, on s'en rendra compte et on pourra prendre les mesures qui s'imposent. Du coup, ça fonctionne et c'est théoriquement solide, mais c'est pas très pratique à mettre en place.

La solution

Si on veut avoir une solution plus simple à mettre en place, il ne faut donc pas séparer l'information « clé privée chiffrée » et « mot de passe » : autrement dit, ne pas utiliser de mot de passe. Mais si l'on fait ça et que l'on met la clé privée dans un unique endroit, ça n'est ni résistant aux attaques ni sûr. Donc, on va séparer la clé privée en plusieurs morceaux, de telle sorte à ce que chaque morceau pris à part ne soit pas suffisant pour reconstituer l'information complète.

Un peu comme un puzzle… Sauf que pas vraiment. Un puzzle a une caractéristique pénible : si l'on perd une pièce, on ne peut pas reconstituer le puzzle entier. Et en plus, la connaissance d'une pièce donne une information non négligeable sur le puzzle final : plus on dispose de pièces, plus c'est facile de « deviner » (comprendre : bruteforcer) celle(s) qui manque(nt). Mais ça tombe bien, le monde merveilleux de la cryptographie a une solution toute prête à ce problème, et ça s'appelle SSSS, comme Shamir's Secret Sharing Scheme.

Avec ce système, on peut choisir deux entiers t et n (où t≤n), une clé secrète, et obtenir n morceaux de la clé qui vérifient deux propriétés sympa :

si on dispose de t morceaux différents (n'importe lesquels), on peut reconstituer la clé secrète ;
et si on dispose de strictement moins de t morceaux, alors on a aucune information supplémentaire sur la clé (le problème « trouver la clé » est aussi difficile que si on n'a aucun morceau).

Une fois qu'on a nos morceaux, on les met à des endroits différents, et si 1<t<n, on obtient toutes les propriétés voulues : en cas de perte ou de vol d'un des morceaux, rien n'est compromis (puisqu'il faut au moins 2 morceaux pour avoir accès aux données) et on a peut retrouver l'information de départ (puisque l'on dispose toujours de n-1 morceaux, et t≤(n-1)).

En fait, si 2<t<(n-1), on peut même se faire voler ou perdre deux morceaux sans que ça soit problématique. Et en fonction du niveau de sécurité que l'on désire, on peut adapter le nombre de morceaux. t=2 et n=3 est la solution « minimale », qui permet d'avoir une sécurité raisonnable (le cas de figure « on se fait voler ou on perd 2 morceaux à la fois » est extrêmement peu probable si ils sont dans des endroits différents) et beaucoup plus plus simple à mettre en place et à maintenir que la solution précédente. Si l'on veut plus de sécurité face aux attaques venant de gens malicieux, il faut augmenter t et n en même temps ; et si l'on veut plus de résilience face à l'éventualité d'une perte de données, il faut augmenter n tout seul.

Mise en pratique

La première chose à faire est de choisir t et n, ce qui dépend du nombre d'endroits de stockage dont on dispose. Pour t=2 et n=3, il suffira de confier deux morceaux à deux personnes de confiance, et en garder un avec soi. Ou bien, une seule personne de confiance, et deux endroits sûrs que l'on a à notre disposition. Dans la suite, on va supposer que t=2 et n=3, c'est facile d'adapter à la solution choisie.

Ensuite, il faut créer notre clé privée. On va faire ça sur un ordinateur déconnecté d'Internet, depuis un Live-CD et qui dispose d'une imprimante. Tout ce qui suit la génération de la clé privée doit être fait depuis une machine complètement déconnectée du réseau, pour éviter qu'un virus ne puisse envoyer à un attaquant les informations générées. De la même façon, si le modèle de l'imprimante est récent et qu'elle est connectée à Internet, il faut débrancher sa connexion (voire la réinitialiser avant et après aux paramètres d'usine, si on a pas confiance).

Prenez donc le Live-CD de votre choix (par exemple, Debian Live) et démarrez dessus. On va avoir besoin de quelques paquets :

apt-get install ssss qrencode zbar-tools

ainsi que d'un logiciel de manipulation d'images (si il n'y en a pas de fourni sur le Live CD, téléchargez votre préféré). Puis, ouvrez le navigateur du live CD, allez sur offlineaddress.com, et débranchez votre câble Ethernet (et désactivez votre carte wifi, si besoin) pour être sûr de ne plus être connecté. Générez une adresse en utilisant la page du site. Mettez l'adresse de gauche (la chaîne de caractères qui commence par un 1) dans un fichier (disons, ~/publique), et celle de droite (qui commence par un 5) dans un autre fichier (~/privee, par exemple).

On commence par couper les morceaux :

cat privee | ssss-split -t 2 -n 3

ce qui imprime trois lignes commençant par 1, 2 et 3, nos morceaux de clés qu'on évoquait plus haut. Copiez-les quelque part (par exemple, dans trois fichiers morceau1, morceau2 et morceau3). Faites-en des QR codes :

cat morceau1 | qrencode -o "morceau1.png" 
cat morceau2 | qrencode -o "morceau2.png" 
cat morceau3 | qrencode -o "morceau3.png"

et vérifiez qu'ils fonctionnent bien : en en prenant deux au hasard, vous devez être capable de retrouver la clé privée.

zbarimg --raw morceau1.png | tr -s '\n' > partie1 
zbarimg --raw morceau3.png | tr -s '\n' > partie3 
cat partie1 partie3 | ssss-combine -t 2

Ensuite, avec votre logiciel de manipulation d'images, faites une jolie image contenant les QR codes (et les morceaux en format brut, au cas où on en aurait besoin en situation d'urgence sans avoir accès à un appareil permettant de les lire), imprimez-la et coupez-la en trois morceaux, que vous pouvez ensuite protéger et stocker. Imprimez aussi la clé publique, pour savoir à quelle adresse envoyer les Bitcoin que vous voulez stocker de cette façon.

Il ne reste plus qu'à distribuer les différents morceaux à des gens ou des endroits de confiance, et à indiquer sur votre testament quels sont les endroits en question. Le critère de choix principal est « si quelque chose arrive à un des morceaux, il faut qu'on puisse en être averti rapidement ». C'est pourquoi utiliser du papier est important : un disque dur ou une clé USB qui meurt au fond d'un tiroir, ça ne prévient personne et ça ne fait pas de bruit.

Derniers détails

On pourrait améliorer certains points. Utiliser le client Bitcoin officiel au lieu d'un service comme offlineaddress.com est vraisemblablement une bonne idée, par exemple (mais c'est plus compliqué). Par ailleurs, si on est vraiment paranoïaque, on peut faire en sorte que la machine utilisée n'ait jamais été connectée à Internet, pas même avant la génération de l'adresse : un virus pourrait parvenir à truquer le processus… Mais j'ai beau me creuser la tête, je ne vois pas trop (vu comment on génère l'adresse) comment une telle attaque serait possible, et préparer tous les paquets à l'avance est un peu pénible.

Au niveau de la confidentialité, si les morceaux de clé secrètes doivent bien sûr rester secrète, on peut avoir envie que la clé publique le soit aussi. Ça ajoute des complications. On pourrait par exemple utiliser plusieurs adresses (en faisant trois groupes de morceaux), et stocker les adresses publiques en différents endroits, pour faire en sorte que quelqu'un qui en découvre une n'ait qu'une idée partielle de la quantité de Bitcoin stockés…

Au cas où ça soit utile de le préciser : je ne suis pas responsable de ce que vous faites avec ces instructions ; et je ne garantis pas leur sécurité absolue. No warranty for any of this, to the extent permitted by applicable law, etc.

Je n'ai pas de téléphone.

2014-08-09T00:00:00+02:00

Je n'ai pas de téléphone. Pas de fixe (comme une majorité d'étudiants), mais surtout, pas de téléphone portable. Depuis que j'ai arrêté d'en avoir un, j'ai dû m'expliquer et répondre aux questions de tout un tas de gens, généralement ébahis, qui me demandaient pourquoi, et comment je faisais pour survivre. J'étais bien conscient que c'était plutôt rare aujourd'hui (surtout parmi les jeunes adultes) donc je m'y attendais un peu, mais je ne pensais pas que ce serait à ce point quelque chose d'inconcevable pour autant de gens (y compris des adultes qui, dix ans auparavant, protestaient fermement contre la généralisation de ces appareils).

Du coup, il n'est peut-être pas inutile que je mette en ligne un petit compte-rendu de mon expérience jusqu'à présent — en évoquant aussi bien les raisons qui m'ont poussé à faire ce choix, les changements dans la vie quotidienne que ça a engendré, et les problèmes qu'une telle décision peut créer. Comme ça fait plus de 8 mois que ça dure, je crois que j'ai maintenant une idée assez précise de ce à quoi ressemble une vie sans téléphone portable pour pouvoir écrire un tel article.

Ce billet peut aussi être vu comme un témoignage permettant à d'autres gens, potentiellement tentés par l'idée de se débarrasser de leur téléphone portable, de savoir ce qui les attend :-)

D'avance, désolé pour la longueur du texte qui suit. Il semblerait que je sois proprement incapable d'écrire des trucs courts.

Motifs

En novembre dernier (2013), j'ai perdu mon portable. J'étais embêté. Du coup, je me suis dit que ce serait une excellente occasion pour changer de forfait et passer chez Free. Pour garder mon numéro de téléphone, il me fallait soit ma carte SIM (que j'avais perdue), soit que je récupère mon numéro RIO. Et à cause de détails administratifs stupides qui n'intéresseront personne, ça a commencé à prendre un temps assez long — au bout de deux semaines, je n'avais toujours pas ce numéro, et l'idée de forcer tous mes contacts à changer mes coordonnées m'ennuyait un peu.

À peu près au même moment, une fournée supplémentaire de révélations de Snowden était publiée : en particulier, le 4 décembre, le public apprenait que la NSA intercepte et stocke une quantité hallucinante de données de géolocalisation de téléphones portables à travers le monde. Plus de 5 milliards d'interceptions de ce type par jour ! À cette fréquence, qui peut encore croire que le citoyen moyen n'est pas concerné ? Qui peut être assez naïf pour imaginer que non, vu qu'il n'a rien à se reprocher, personne ne stocke de données intimes le concernant ?

À la suite de ces révélations, j'ai fait en sorte de limiter au maximum les opportunités, pour les agences gouvernementales aussi bien que pour les grandes multinationales, d'obtenir des informations privées me concernant. Je me suis mis à héberger mon propre serveur mail, à signer et chiffrer mes communications dès que possible, à utiliser des adresses à usage unique lorsque je m'inscris sur un site marchand… Mais l'idée que l'on sache en temps réel où je suis, et que l'on puisse reconstituer mon itinéraire (donc mon emploi du temps, mes habitudes de consommation, la liste de mes proches…), ça m'est proprement insupportable. Ça devrait l'être aussi pour vous, d'ailleurs (j'ai passé une bonne demi-heure à sous-titrer cette vidéo en français, prenez donc trois minutes pour la visionner).

Or, il n'existe pas beaucoup d'options pour se protéger contre ce type d'intrusion dans sa vie privée. La géolocalisation d'un téléphone portable éteint ou en mode avion est possible (en anglais), et puis trimballer un téléphone éteint n'a pas beaucoup d'intérêt. Par ailleurs, au bout de deux semaines à vivre sans téléphone, je me suis rendu compte que ne pas avoir de téléphone avait en fait un certain nombre d'avantages, que les inconvénients n'étaient pas si terribles que ça, et que c'était une expérience intéressante d'essayer de s'en passer.

En résumé, c'est un mélange de hasard et de désir de protection de vie privée qui m'ont poussé à ne pas racheter de portable, et j'ai continué par curiosité et après avoir découvert les avantages que ça avait.

Inconvénients, et problèmes rencontrés

Je commence par les points négatifs, pour pouvoir finir sur une note positive : ça correspondra mieux à mon expérience, qui est globalement enthousiasmante (je ne compte pas racheter un téléphone de sitôt, tant que je n'en ai pas besoin professionnellement).

Carte bleue, et achats sur Internet

Le gros morceau. Le système de paiement par carte bleue fonctionnant suivant un protocole d'une stupidité profonde (sérieusement, devoir donner l'intégralité des informations de sa carte au moindre site marchand, qui pourrait très bien les utiliser pour vider le compte et disparaître dans la nature… 40 ans après l'invention de la cryptographie asymétrique, c'est complètement absurde), les banques et organismes de paiement forcent de plus en plus l'utilisation de système d'authentification en deux temps. Entre autres, quand on paie par carte bancaire via Internet, c'est maintenant devenu la norme de recevoir un SMS avec un code de confirmation.

C'est un cataplasme sur une jambe en fibre de carbone, mais il n'empêche que c'est devenu une option non seulement par défaut, mais obligatoire. J'ai donc augmenté la proportion de trucs payés par Internet avec Bitcoin, mais enfin, c'est encore loin de suffire (un jour, peut-être…). Je suis donc allé voir ma banque en leur demandant de supprimer cette option. Impossible. Je suis allé voir quelques autres banques en leur demandant si c'était possible chez eux — les réponses se partageaient entre « je n'en ai pas la moindre idée » et « non ». À chaque fois, je passais pour un doux dingue et j'étais le premier à leur poser la question (ce qui m'a fait réaliser qu'en fait, tout le monde a un téléphone, au moins en France, et que ceux qui n'en n'ont pas ne font pas non plus leurs achats sur Internet).

J'ai donc pris rendez-vous avec la personne qui s'occupe de mon compte à la Banque Postale (au lieu de demander au hasard parmi les employé-e-s présents ce jour-là), et partant du principe que ces gens-là sont payés en fonction de leur capacité à garder leurs clients, j'ai menti et lui ai dit que s'il n'existait pas de solution, j'allais changer de banque. Elle s'est activement creusé les méninges, et a fini par me proposer l'option « e-carte bleue ». En gros, à chaque transaction, je peux générer un nouveau numéro de carte à usage unique, qui ne « contient » que la somme nécessaire à régler mes achats.

Je ne comprends pas pourquoi un tel système n'est pas plus répandu (la preuve, il a fallu à ma conseillère vingt bonnes minutes de recherche avant d'y penser), si j'avais su avant que ça existait, je m'y serais inscrit sans hésiter (surtout pour le prix minime de l'option, de l'ordre d'une dizaine d'euros par an). En tous cas, ça a résolu mon problème : avec un code à usage unique, il n'y a plus besoin d'une authentification en deux temps. Et je peux recommencer à faire des achats sur Internet comme je veux, de façon bien plus sécurisée qu'avant.

Autres systèmes utilisant une authentification en deux temps

Les fournisseurs de cartes bancaires ne sont pas les seuls à vouloir vous envoyer des SMS de confirmation. Tout un tas de services en ligne font tout leur possible pour que leurs utilisateurs utilisent ce type d'authentification. Sur mon compte Google, par exemple, on me demande régulièrement d'entrer un numéro de téléphone. Dans la majorité des cas, il suffit de répondre « non merci », et même si le bouton n'est pas franchement mis en évidence, ça reste une possibilité. Et la seule contrariété est que la question réapparaît à intervalles réguliers.

Parfois, ça n'est pas une option : je n'ai pas pu utiliser (enfin, tester) Coinbase à cause de ça. Tant pis pour eux ! D'autres fournisseurs de services « sensibles » (à qui l'on confie des mails, ou de l'argent) permettent l'utilisation de mécanismes plus intelligents, comme une authentification en deux temps basée sur des codes à usage unique à imprimer ou bien sur l'utilisation d'une clé PGP (un cookie pour le premier lecteur capable de deviner le site que j'ai en tête et qui utilise cette méthode).

En résumé, ça n'est pas un gros problème.

Ne pas pouvoir remplir les formulaires par Internet

Ah oui, sites marchands et autres, j'ai un message pour vous : si vous demandez un numéro de téléphone lors de l'inscription à votre système, sans expliquer à l'utilisateur pourquoi vous en avez besoin ; ou pire, si vous lui interdisez de laisser ce champ vide, allez faire de l'apnée nus dans le Kawah Ijen. Sérieusement.

Donc, au cours des derniers mois, j'ai souvent dû entrer « 0000000000 » comme numéro de téléphone pour pouvoir m'inscrire sur divers sites Web. Parfois, « 0600000000 » lorsqu'ils vérifient que le numéro a l'air honnête. Du coup, je suis désolé pour la personne qui a ce numéro, il est possible qu'il se soit fait spammer un peu :D

C'est un peu bête, mais ça ne m'a jusqu'ici rien causé d'autre qu'un léger agacement — à chaque fois qu'il est question de se faire livrer un produit quelconque, je précise avec ma commande « me contacter par e-mail uniquement, je n'ai pas de téléphone ». Pour la petite histoire, ça m'est arrivé de remplir un formulaire papier sous les yeux d'une employée pour une carte de fidélité quelconque. Je lui ai dit que je n'avais pas de téléphone, elle m'a dit qu'elle avait quand même besoin d'un numéro, j'ai rentré « 0000000000 » et je lui ai demandé si elle comptait vérifier que c'était le bon. Elle a rentré ça dans son ordinateur, qui n'a pas bronché, et j'ai eu ma carte de fidélité.

Ne pas pouvoir joindre facilement administrations et entreprises

On est en 2014, mais malgré ça, les services administratifs ou les entreprises commerciales sont encore très rarement joignables efficacement par e-mail. Ce qui est une honte, mais le problème reste entier : pour contacter un service public, une boutique ou un support commercial quelconque, le téléphone reste le moyen le plus sûr d'avoir une réponse. J'ai donc assez rapidement fini par acheter du crédit Skype pour pouvoir passer des coups de fil au besoin. Conclusion : ne le faites pas. Ça n'est pas très cher, mais le service est très mauvais, avec des temps de latence beaucoup trop grands. Il m'est arrivé plusieurs fois que mon interlocuteur raccroche au bout de quelques secondes, n'entendant personne au bout du fil, à cause du décalage audio.

Je suis donc allé voir la concurrence et ai acheté du crédit Google Hangouts. Et contrairement à Skype, là, ça marche parfaitement. Leurs prix sont vraiment honnêtes (2 centimes la minute vers les fixes, depuis n'importe où), et la qualité de la communication est nickel — même, par exemple, de la Russie vers la France. Le seul bémol est l'obligation de se créer du même coup un compte Google+, mais comme un concours de programmation m'avait déjà obligé à le faire, ça ne me gêne pas trop — et puis, je n'y publie rien et je n'ai quasiment pas de contacts.

Ne pas être joignable

Voir la section « avantages ».

Non, mais pour de vrai.

Non non, vraiment, ne pas être joignable est un vrai confort et c'est principalement ça qui a amélioré ma qualité de vie. Mais soyons honnêtes, ça n'a pas que des avantages : lorsque l'on a rendez-vous avec quelqu'un, c'est pratique de passer un petit coup de fil lorsqu'on y est pour se retrouver. Il a fallu m'adapter : donner des rendez-vous à des emplacements géographiques beaucoup plus précis à mes amis, et arriver un peu en avance. Et lancer des cailloux sur les amis susmentionnés lorsqu'ils ne sont pas à l'heure ^^

C'est un peu gênant, mais je me suis adapté (et je suis plus ponctuel qu'avant). Je me rends bien compte que le fait de ne pas avoir de téléphone est perçu comme un caprice un peu gênant pour les gens que je dois retrouver quelque part à une certaine heure ; mais en même temps, arriver à l'heure à l'emplacement précis est quand même (théoriquement) normal, donc je n'ai pas l'impression de demander l'impossible. Et en pratique, les gens s'adaptent bien et j'ai des amis (que je ne nommerai pas :D) qui ne sont pas ponctuels en temps normal, et qui font un effort lorsqu'ils ont rendez-vous avec moi. Victoire \o/

Ne plus pouvoir avoir de longues conversations téléphoniques avec ses proches

Je n'ai jamais aimé les conversations téléphoniques, donc je n'ai jamais eu ce type de conversations téléphoniques en y prenant du plaisir. Pour garder contact, je communique par e-mail, par IRC, par cartes postales et par Skype (oui, je sais, je devrais utiliser quelque chose de libre et de chiffré, mais allez expliquer ça aux gens technophobes). Et j'aime mille fois mieux avoir une longue discussion avec quelqu'un par visioconférence plutôt que par téléphone.

Ne pas pouvoir [insérer ici une possibilité quelconque des smartphones]

Je n'ai jamais eu de smartphone, donc je ne me rends pas bien compte. J'ai toujours bien vécu sans GPS, sans traducteur automatique, sans lampe torche, sans boussole, etc. Pour ce qui est de se divertir lors d'un trajet, j'ai une liseuse (qui peut même, en cas de besoin, se connecter à une borne Wi-Fi) et un lecteur MP3.

Avantages et changements positifs

Si j'ai continué l'expérience et que j'ai l'intention de la poursuivre tant que je peux, c'est que globalement, j'en suis content. J'ai déjà évoqué quelques raisons. Je suis plus ponctuel et mes amis le sont aussi, mes paiements en ligne sont significativement plus sécurisés qu'avant, et la motivation d'origine est toujours aussi pertinente : je ne suis plus géolocalisable. Ça me donne une réelle impression de liberté d'aller physiquement quelque part en me disant qu'aucun algorithme, aucune base de données, aucune agence n'est au courant de mes déplacements. Bien sûr, si quelqu'un voulait me cibler personnellement et me filer, cela lui serait toujours possible, mais mon activité en ligne serait compliquée à récupérer (et une partie significative de ma vie et de mes interactions avec le monde extérieur passe par Internet), et je ne peux pas vraiment lutter contre une filature physique. Mais il faudrait un mandat (un vrai) pour faire ça légalement, donc c'est rassurant.

Le second gros avantage, c'est au niveau du confort de vie. Avant de m'en débarrasser, je n'avais jamais remarqué à quel point la présence permanente d'un outil de communication dans sa poche était oppressant. En temps normal, on peut être dérangé n'importe quand, même si on est au milieu de quelque chose d'important, par une vibration dans sa poche (je suppose ici que le téléphone est en mode vibreur ; les gens qui en plus dérangent tous ceux dans leur environnement immédiat devraient être jetés dans le lac acide susmentionné). Et on a un besoin complètement irrationnel de savoir ce qui se passe, tout de suite. C'est peut-être important ! Qui sait ? Peut-être que je généralise — en tous cas, en ce qui me concerne, je n'exagère pas.

Lorsqu'on met le téléphone en mode silencieux, c'est pire : on pourrait à chaque instant recevoir un appel ou un SMS sans le savoir. Il faut donc vérifier le plus souvent possible que ce n'est pas le cas. On perd probablement un temps invraisemblable à jeter un œil torve à un écran vide de toute notification, mais ça ne change rien.

Sans téléphone… Pas de problème. Lorsque l'on fait une tâche quelconque — lire un livre, réfléchir à la preuve d'un théorème, discuter avec quelqu'un, profiter d'un bon repas, regarder un film, écrire un article de blog illisible car beaucoup trop long et totalement inintéressant, on la fait vraiment, sans une possibilité toujours ouverte d'être déconcentré, ou de se déconcentrer tout seul. C'est probablement quelque chose que tout le monde connaît déjà : quand on fait du sport, ou qu'on va au cinéma ou au théâtre, on est pris à 100% par ce qu'on est en train de faire (a priori, tout du moins), on est pas constamment en communication potentielle avec l'extérieur. Imaginez ça, en permanence. Joie, bonheur, Zen et qualité de vie significativement améliorée.

Les gens ne peuvent plus, soudainement, décider de se manifester dans ma vie à l'improviste. À part en venant chez moi, mais ça nécessite une plus grande quantité de motivation, donc ça n'arrive qu'en cas d'urgence ou de bonne surprise. De toute façon, lorsque je suis chez moi (ou que je travaille) et que l'on m'envoie un mail (ou un message instantané), je le lis rapidement, donc ça couvre déjà une bonne partie des cas d'utilisation du téléphone. En fait, après en avoir parlé avec des gens, une très grande majorité de raisons pour lesquelles on aurait besoin de me transmettre de l'information tombent dans la catégorie « faisable par mail », ou bien « non urgent ».

Oui oui, je suis parfaitement conscient de à quel point ce dernier paragraphe doit me faire ressembler à un control freak, tant pis :D

À part ça, quelques derniers trucs auxquels je pense, qui ne pèsent pas vraiment dans la balance, mais que je mentionne par souci d'exhaustivité. Ne pas avoir de téléphone économise du temps (si on met bout à bout toutes les fois où on jette un coup d'œil sur son téléphone…), de l'argent et du poids à transporter. Ça crée spontanément des conversations parce que ça n'est pas commun. C'est une raison en moins de procrastiner (j'ai dû passer un temps absurde sur des jeux débiles de téléphone portable, et pourtant, c'étaient loin d'être des bons jeux, je parle des trucs fournis de base avec les OS des vieux Nokia/Samsung).

Conclusion

Ne pas avoir de téléphone c'est bien :D Bon, faire du prosélytisme n'aurait absolument aucun sens — pour des tas de gens, avoir et utiliser un téléphone portable n'a rien d'un choix. Mais bon, mon expérience a l'air de montrer que ce n'est pas le cas de tout le monde, que l'on peut s'en sortir sans et que ça peut même être plutôt enthousiasmant. Bon, je pourrais écrire à peu près n'importe quoi ici, parce que personne ne va lire cet article en entier de toute façon. Ça tombe bien, je suis sacrément mauvais lorsqu'il s'agit d'écrire des conclusions.

Que font les thésards en maths de leurs journées ?

2014-07-24T00:00:00+02:00

Ce texte est une traduction collaborative de ce billet de Yasha Berchenko-Kogan, par a3nm, Arthur, elarnon, Ish, Lau, Yap et moi-même.

Que font les thésards en maths de leurs journées ?

Quand vous êtes en thèse, vous passez une bonne partie de votre temps à lire des livres et des articles pour tenter de comprendre leur contenu. Mais les maths, ça ne se lit pas aussi bien qu'un roman policier. Ça ne se lit pas non plus comme un livre d'histoire ou un article du Monde, à vrai dire.

Le premier problème que vous rencontrez, lorsque vous arrivez à la frontière de ce qui est connu en maths, c'est que les mots pour décrire les concepts n'existent pas encore. Parler de ces idées, c'est un peu comme essayer d'expliquer à quelqu'un qui n'en a jamais vu ce qu'est un aspirateur, en n'utilisant que des mots de 5 lettres ou moins.

Comment pourriez-vous formuler ça ?

« C'est un outil qui pompe pour que le sol chez soi ne soit plus sale. »

C'est certainement mieux que rien, mais ça ne vous dit pas tout ce que vous pourriez vouloir savoir à propos des aspirateurs. Peut-on utiliser un aspirateur pour laver les rayonnages d'une bibliothèque, ou un chat, ou un trottoir ?

Les auteurs d'articles et de livres tentent de communiquer ce qu'ils ont compris du mieux qu'ils peuvent, compte tenu de ces restrictions. C'est certainement mieux que rien… Mais si vous voulez travailler à votre tour avec des aspirateurs, vous avez besoin d'en savoir beaucoup plus.

Heureusement, les mathématiciens ont un outil incroyablement puissant pour transmettre des informations : l'écriture mathématique. Lorsqu'ils imaginent de nouveaux concepts, ils utilisent — et inventent au besoin — des symboles et des notations très explicites, ainsi que des règles logiques pour les manipuler. C'est un peu l'équivalent d'une spécification technique et de schémas pour fabriquer un aspirateur à partir de pièces détachées.

L'avantage, c'est que désormais, vous pouvez (en théorie) savoir sans aucune ambiguïté ce qu'un aspirateur peut ou ne peut pas faire. Le problème, c'est que vous n'avez toujours aucune idée de ce à quoi les pièces servent ni de pourquoi elles sont arrangées de cette manière, si ce n'est grâce à la phrase cryptique : « C'est un outil qui pompe pour que le sol chez soi ne soit plus sale ».

Maintenant, vous vous retrouvez en thèse, et votre directrice vous donne un papier fondamental, « Un outil qui pompe des trucs ». L'introduction vous dit que « C'est un outil qui pompe pour que le sol chez soi ne soit plus sale » et tout un tas d'autres choses vagues mais qui ont l'air raisonnables. Le gros du papier est composé de schémas et de descriptions de l'aspirateur. Puis viennent quelques références : « De l'air qui pompe ce qui est sale », « Des pales qui vont très vite », « Ce qu'on peut faire avec les trous dans le mur, à l'aide de fils en métal ».

Et ensuite ? En pratique, vous êtes à votre bureau, vous vous asseyez et vous réfléchissez. Sauf que ce n'est pas si simple. D'abord vous vous dites que, héhé, on dirait presque qu'il y a un sous-entendu graveleux dans ce titre. Puis vous lisez l'introduction qui explique avec des mots simples ce dont ça va parler — sans donner le moindre détail.

Puis, vous passez aux schémas. Vous vous perdez un peu dans tous ces dessins, mais vous passez du temps à les analyser, les uns après les autres. Vous refaites certaines démonstrations, histoire de vérifier que vous les avez bien comprises. De temps en temps, vous trouvez un résultat absurde, et vous cherchez ce que vous avez mal compris, pour le relire et recommencer les calculs. Il arrive parfois que la faute soit dans le papier, et que ça soit ça qui vous ait induit en erreur.

Au bout d'un moment, les pièces du puzzle s'assemblent et vous arrivez enfin à avoir une compréhension intuitive de ce qu'est un aspirateur. En fait, vous êtes maintenant l'un des experts en aspirateurs, en tout cas pour ce modèle précis, et vous comprenez une bonne partie des détails de son fonctionnement. Vous en êtes super fier, même si vous êtes encore loin du niveau de votre directrice de thèse. Elle, elle connaît tout un tas d'autres genres de modèles d'aspirateurs, même des récents comme des Roombas, et en plus, elle travaille sur un projet sur la climatisation qui est un peu lié mais quand même très différent.

Vous êtes ravi de pouvoir enfin parler d'égal à égale avec votre directrice, au moins sur ce sujet-là, mais il reste un truc à faire… Remplir une thèse.

Du coup, vous pensez à de nouvelles choses qu'on pourrait faire avec un aspirateur. Au début, ça ressemble à : « On pourrait peut-être utiliser un aspirateur pour nettoyer des étagères. Ça serait super utile !! ». Puis, vous faites une recherche sur Google Scholar et il se trouve que quelqu'un d'autre l'a déjà fait il y a une bonne dizaine d'années.

OK, prochaine idée : « Et si on utilisait un aspirateur pour nettoyer des chats ? » Ça aussi, ça serait super utile. Malheureusement, une petite recherche dans la littérature révèle que quelqu'un d'autre a déjà essayé, mais qu'il n'a pas eu de bons résultats. Mais vous êtes un jeune thésard confiant, et commencez à avoir un petit peu d'expérience. Vous estimez donc que vous disposez de quelques petites techniques nouvelles, qui pourraient permettre de contourner les problèmes rencontrés par l'autre chercheur, et obtenir un aspirateur qui nettoie aussi les chats. Vous passez plusieurs mois dessus, mais, hélas, vous n'aboutissez pas au résultat voulu.

Du coup, après un peu de réflexion et avoir fait un peu de recherche annexe en rallonges électriques, vous pensez qu'il serait possible d'utiliser un aspirateur pour nettoyer des trottoirs. Vous regardez la littérature, et il semble que personne n'a jamais pensé à le faire. Chouette ! Vous annoncez fièrement votre idée à votre directrice de thèse, mais elle griffonne sur un bout de papier des calculs que vous ne comprenez pas vraiment, et vous répond qu'aspirer à l'extérieur, c'est probablement inutile. Un aspirateur serait trop petit pour gérer toute la surface extérieure, on dispose déjà d'autres outils bien plus adaptés pour nettoyer les trottoirs, etc.

Ça continue comme ça pendant pas mal d'années, et vous finissez par écrire une thèse ayant pour sujet « Si on retourne un aspirateur et qu'on en submerge l'embout, on peut faire des bulles ! ».

Votre jury de thèse a du mal à voir dans quelles circonstances cela pourrait bien être utile, mais ça a l'air plutôt cool et puis, les bulles, c'est joli. Du coup, ils pensent qu'on pourrait peut-être en tirer quelque chose d'utile un jour. Peut-être.

Et, en effet, quelle chance ! Une petite centaine d'années plus tard, votre idée (combinée avec pas mal d'autres) permettra de développer des pompes à air pour aquariums, un outil qui se révélera essentiel pour un domaine de recherche en plein essor : les habitats artificiels pour poissons rouges.

Youpi !

Gérer ses mails en local : étape 4, tout chiffrer avec GPG !

2014-06-25T00:00:00+02:00

Ce billet fait partie d'une série d'articles présentant la façon dont je gère mes mails en local. Si vous êtes arrivés là sans lire l'introduction, c'est probablement une bonne idée de commencer par le début =)

Étape 0 : Introduction
Étape 1 : Synchronisation IMAP avec OfflineIMAP
Étape 2 : Envoi d'e-mails avec msmtp et msmtpq
Étape 3 : Configuration de mutt
Étape 3 bis : Dose supplémentaire de mutt
Étape 4 : Chiffrement et signature avec PGP ← vous êtes ici !

Notre configuration, jusqu'ici, n'est pas très sécurisée. Le problème principal est que tous nos mots de passe sont stockés en clair sur le disque dur : si quelqu'un y a accès, il peut non seulement lire nos mails mais il a un accès direct à notre serveur IMAP et SMTP, tant qu'on ne change pas la configuration. On pourrait rétorquer que si l'on fait attention, on peut faire en sorte que personne n'ait un accès à la machine ; et dans la majorité des situations, avec quelques précautions évidentes - verrouiller l'écran de son laptop dès qu'on s'en éloigne, etc. - c'est un argument qui se tient. Le problème, c'est que si le disque dur est non chiffré et que quelqu'un a un accès physique et prolongé à la machine (par exemple, si on vous l'a volé, ou que vous l'avez laissé sans surveillance pendant un temps suffisamment long pour laisser le temps à un attaquant de lancer un Live CD), les données seront compromises (et l'attaque peut très bien ne laisser quasiment aucune trace).

Pour résoudre ce problème grave, on va installer GPG (Gnu Private Guard) et modifier notre configuration pour planquer les données sensibles. Ça sera par ailleurs une excellente occasion pour se servir du même logiciel pour signer électroniquement les mails qu'on envoie, et les chiffrer quand c'est possible.

Si vous n'avez jamais entendu parler d'OpenPGP (le protocole implémenté par GnuPG) et que vous ne savez pas du tout ce que c'est qu'une paire de clés publique/privée, c'est probablement une bonne idée d'aller lire quelques ressources sur le sujet (par exemple, la page Wikipédia consacrée au principe de la cryptographie asymétrique). Dans toute la suite, je vais supposer que vous comprenez les notions de clé privée, clé publique, et que vous comprenez l'idée de base que l'on va implémenter ici.

Premiers pas

Installation

Pour l'installation, on installe GnuPG, ainsi qu'un autre paquet dont on va détailler l'utilité plus tard. La commande qui invoque le logiciel est gpg mais le nom du paquet est gnupg :

aptitude install gnupg gnupg-agent pinentry-gtk2

Ensuite, il faut se créer (au minimum) une paire clé publique / clé secrète si l'on veut pouvoir chiffrer quoi que ce soit. Lancez donc la commande :

gpg --gen-key

et laissez-vous guider. Les choix par défaut sont en général très bien (même si je pense que ça ne coûte pas grand-chose de toujours sélectionner la taille de clé la plus grande disponible). On va vous demander une phrase de passe, évidemment, parce que si la clé secrète (qui se trouve sur votre disque dur) n'est pas elle-même chiffrée, quelqu'un qui vous vole votre disque dur pourra la lire et déchiffrer ce qu'il veut avec. Inutile de préciser qu'il faut choisir une phrase de passe solide, je recommande pour ça la méthode XKCD (pour les non-anglophones : quelques (au moins quatre) mots aléatoires de la langue française les uns à la suite des autres - comme correctchevalbatterieagrafe - forment un mot de passe à la fois plus sûr et plus facile à retenir qu'un truc rempli de transformations bizarres comme Tr0ub4doUr&3).

On a notre paire de clés, disons que son identifiant est EA627AA3. On peut s'amuser à chiffrer et déchiffrer des documents :

echo "Encryptons joyeusement un fichier inutile" > inutile.txt
cat inutile.txt
gpg --encrypt -r EA627AA3 --armor inutile.txt
cat document.txt.asc
gpg --decrypt document.txt.asc

mais je ne m'étendrais pas sur l'étendue des possibilités de GPG ; ce tutoriel cherche juste à expliquer comment se servir en pratique de GPG pour augmenter la sécurité de sa configuration. Si vous voulez des informations plus détaillées, vous pouvez allez jeter un œil du côté de la documentation officielle, qui est à la fois complète et très lisible (et en français).

Configuration

GnuPG requiert une quantité assez minime de configuration. Par contre, par défaut, il va vous demander votre phrase de passe dès qu'il essaie d'accéder à vos clés : en pratique, dès que vous envoyez un mail signé, que vous recevez un mail chiffré, ou qu'il tente de déchiffrer un fichier - donc, tout le temps.

Pour que ça ne soit pas trop pénible, on utilise gpg-agent, qui nécessite un peu plus de configuration. Commencez par décommenter la ligne contenant use-agent dans le dossier ~/.gnupg/gpg.conf (si ce fichier n'existe pas, lancez gpg dans un terminal, puis appuyez sur Ctrl-D).

Puis, créez et éditez le fichier ~/.gnupg/gpg-agent.conf, et entrez-y les lignes suivantes :

pinentry-program /usr/bin/pinentry-gtk-2
default-cache-ttl 43200
max-cache-ttl 43200

en remplaçant 43200 par le temps, en secondes, pendant lequel vous voulez que gpg-agent se souvienne de votre phrase de passe (donc la fréquence à laquelle il va vous la redemander). Ici, toutes les 12 heures. Pour vérifiez que ça fonctionne, lancez la commande suivante dans un terminal :

eval "$(gpg-agent --daemon)"

et lancez une commande qui nécessite votre phrase de passe (par exemple, chiffrez un fichier quelconque); vous allez pouvoir constater que c'est gpg-agent qui s'occupe de vous la demander et que si vous faites ça plusieurs fois de suite, il l'aura gardé en mémoire entre deux fois consécutives.

Ne pas stocker ses mots de passe en clair

On a pour l'instant des mots de passe en clair dans les configurations de msmtp, et de OfflineIMAP. À la place, on va plutôt les stocker dans des fichiers à part, qui seront chiffrés. Commencez par créer un répertoire où vous voulez dans votre système (~/.mdp, par exemple), c'est là que l'on va les mettre.

msmtp

Dans la configuration de msmtp, pour l'instant, on a une ligne qui ressemble à :

password gungjbhyqunirorraorggre

supprimez cette ligne, et copiez le mot de passe dans ~/.mdp/msmtp, par exemple. Il faut que ce fichier contienne votre mot de passe et rien d'autre : pas d'espace ni de retour à la ligne. Chiffrez ce fichier, et supprimez-le de façon sécurisée :

cd ~/.mdp/msmtp
gpg --encrypt -r EA627AA3 --armor msmtp
shred -z -v msmtp

maintenant, à la place de la ligne qui contenait votre mot de passe, ajoutez la ligne :

passwordeval gpg --batch -d --use-agent --yes /home/votreidentifiant/.mdp/msmtp.gpg 2>/dev/null

(évidemment, en changeant « votreidentifiant » par votre nom d'utilisateur). Vous êtes en train de lui dire « pour trouver le mot de passe, exécute la commande suivante » au lieu de directement « voilà le mot de passe ». À chaque fois qu'il va avoir besoin du mot de passe, il va déchiffrer le fichier ~/.mdp/msmtp.gpg, en utilisant gpg-agent pour ne pas vous demander votre mot de passe si il s'en souvient.

Votre mot de passe SMTP n'est donc plus disponible en clair sur votre disque dur, mais mis à part un mot de passe que vous devez rentrer régulièrement (à intervalles que vous choisissez), rien n'a changé dans l'utilisation quotidienne de msmtp. Si vous utilisez msmtp avec plusieurs comptes différents, n'oubliez pas de créer un fichier par mot de passe et de faire les modifications partout, bien sûr.

OfflineIMAP

Pour OfflineIMAP, on va faire essentiellement la même chose. Seulement, le fichier de configuration n'a pas d'option aussi simple que le passwordeval de msmtp, mais permet à la place d'utiliser un script Python. Téléchargez donc le fichier suivant, enregistrez-le quelque part (par exemple, comme ~/.offlineimap.py), et rectifiez la ligne contenant votreidentifiant.

Puis, dans le fichier de configuration d'OfflineIMAP (~/.offlineimaprc), ajoutez la ligne

pythonfile = ~/.offlineimap.py

dans la section [general], puis remplacez la ligne remotepass par :

remotepass = mailpasswd("offlineimap")

en supposant que, de façon similaire à tout à l'heure, vous aviez stocké votre mot de passe dans le fichier ~/.mdp/offlineimap.gpg. Choisissez des noms plus spécifiques si vous gérez plusieurs comptes à la fois, et stockez autant de mots de passe que vous voulez de la même façon.

Cron fait des siennes

Si vous êtes arrivés jusque là, tout devrait normalement bien marcher… Sauf cron. En effet, on utilise gpg-agent pour mettre la phrase de passe de la clé GPG en cache, gpg-agent a besoin de variables d'environnements pour fonctionner, et cron n'a pas accès aux mêmes variables d'environnements que vous. Ça engendre des situations qui sont un cauchemar à débugger, mais voilà la solution que j'ai fini par trouver après avoir sué sang et eau pour faire marcher l'automatisation de tout ça.

Éditez le fichier de configuration de cron avec crontab -e. Commencez par y ajouter, au tout début, la ligne :

DISPLAY=:0

pour que lorsque gpg-agent aura oublié votre phrase de passe GPG, il sache sur quel écran afficher sa petite fenêtre qui va vous la demander. Ensuite, pour chacune des lignes où vous invoquez soit offlineimap, soit msmtp (ou msmtp-queue), ajoutez au début de la commande :

. /home/votreidentifiant/.gpg-agent-info && export GPG_AGENT_INFO &&

par exemple, la commande d'OfflineIMAP de quelques articles en arrière était :

*/2 * * * * /usr/bin/offlineimap > /dev/null 2> /dev/null

et elle va devenir :

*/2 * * * * . /home/votreidentifiant/.gpg-agent-info && export GPG_AGENT_INFO && /usr/bin/offlineimap > /dev/null 2> /dev/null

(mais vous feriez mieux, dans un premier temps, de remplacer les /dev/null par des emplacements où vous pouvez lire les messages que renvoie la commande, pour pouvoir débugger en cas de problème).

Et comme ça, ça devrait fonctionner - on utilise un fichier créé par gpg-agent qui contient la variable d'environnement qu'il faut, ce qui permet aux futurs appels à gpg de savoir où trouver (ou demander) la phrase de passe.

Chiffrez et signez vos messages

Passons aux choses sérieuses : on va utiliser notre jolie paire de clés pour signer tous les messages envoyés via mutt, et chiffrer ceux qui sont possibles. Déjà, si vous avez des amis qui utilisent GPG, c'est le moment d'aller ajouter leurs clés publiques dans votre trousseau :

gpg --search-keys lenomdevotrepote

(suivez les instructions pour les ajouter à votre trousseau) et d'exporter la vôtre sur le serveur officiel de GnuPG :

gpg --send-keys EA627AA3

remplacez bien sûr ici et dans toute la suite EA627AA3 par l'identifiant de votre clé.

Dans le fichier de configuration de mutt, ajoutez une ligne du style source ~/.mutt/gpg pour mettre dans un même fichier tout ce qui concerne GPG (et si vous comptez utilisez plusieurs clés différentes plus plusieurs comptes différents, faites plusieurs fichiers, et sourcez-les au bon endroit).

Dans le fichier en question, glissez donc tout un tas de commandes compliquées pour dire quelles commandes utiliser : mutt connaît le principe d'OpenPGP, mais est prévu pour pouvoir utiliser n'importe quel logiciel qui parle le même protocole. Du coup, il faut lui indiquer à la main toutes les commandes de chiffrement, de déchiffrement, de signature, etc. En pratique, recopiez tout ça : à part l'identifiant de la clé, vous n'avez rien à changer.

# Commandes à utiliser avec gpg
set pgp_decode_command="gpg --no-verbose --batch --output - %f"
set pgp_verify_command="gpg --no-verbose --batch --output - --verify %s %f"
set pgp_decrypt_command="gpg --no-verbose --batch --output - %f"
set pgp_sign_command="gpg --no-verbose --batch --output - --armor --detach-sign --textmode %?a?-u %a? %f"
set pgp_clearsign_command="gpg --no-verbose --batch --output - --armor --textmode --clearsign %?a?-u %a? %f"
set pgp_encrypt_only_command="/usr/lib/mutt/pgpewrap gpg --batch --quiet --no-verbose --output - --encrypt --textmode --armor --always-trust --encrypt-to 0xEA627AA3 -- -r %r -- %f"
set pgp_encrypt_sign_command="/usr/lib/mutt/pgpewrap gpg --batch --quiet --no-verbose --textmode --output - --encrypt --sign %?a?-u %a? --armor --always-trust --encrypt-to 0xEA627AA3 -- -r %r -- %f"
set pgp_import_command="gpg --no-verbose --import -v %f"
set pgp_export_command="gpg --no-verbose --export --armor %r"
set pgp_verify_key_command="gpg --no-verbose --batch --fingerprint --check-sigs %r"
set pgp_list_pubring_command="gpg --no-verbose --batch --with-colons --list-keys %r" 
set pgp_list_secring_command="gpg --no-verbose --batch --with-colons --list-secret-keys %r" 
set pgp_good_sign="^gpg: Good signature from"

Ensuite vient la « vraie » configuration. Dans l'ordre, on va indiquer :

qu'on utilise gpg-agent,
la clé qu'on utilise pour signer,
qu'on veut signer tous les messages sortants,
qu'on chiffre automatiquement les réponses à des messages signés (parce que quand on sait que quelqu'un signe ses mails, on va pouvoir chiffrer les messages qu'on lui envoie),
qu'on chiffre aussi automatiquement les réponses à des messages chiffrés,
et qu'on souhaite vérifier la signature de tous les messages reçus (ce qui, en supposant que vos contacts protègent suffisamment bien leurs clés secrètes, garantit que personne n'est en train d'usurper leur identité).

set pgp_use_gpg_agent
set pgp_sign_as=0xEA627AA3
set crypt_autosign
set crypt_replyencrypt
set crypt_replysignencrypted
set crypt_verify_sig

Voilà un bon début, et ça peut même vous suffire. Sachez quand même que certains clients de messagerie (notamment des vieuuux Outlook) n'aiment pas recevoir des messages signés, et n'affichent qu'une erreur lorsqu'ils en reçoivent (ce qui est incroyablement stupide, vu qu'une signature n'est rien de plus qu'un petit fichier texte joint à chaque mail, mais bon). Dans ce cas, on peut avoir envie de rajouter des hooks du genre :

send-hook '~t @vetagro-sup\.fr' "set crypt_autosign=no"

dans la configuration de mutt. Notez que si vous mettez la ligne précédente telle quelle et que vous envoyez un mail à un des destinataires concernés par le hook, l'option crypt_autosign vaudra no pour toute la suite de cette exécution de mutt. Il faut donc ajouter, avant la ligne précédente, un hook qui remet l'option dans son état désiré :

send-hook . "set crypt_autosign=yes"

Si après, ponctuellement, vous avez envie de ne pas signer un mail (ou de le chiffrer, ou de façon générale de changer les paramètres sur un mail envoyé), c'est la touche p qui permet de faire ça, juste avant l'envoi d'un message.

À part ça, il manque une fonctionnalité pourtant assez naturelle : le fait de chiffrer automatiquement les messages lorsqu'on a la clé publique du destinataire dans son trousseau. Il n'y a pas d'option pour ça, donc j'utilise un hack très crade : un script qui génère automatiquement un fichier de configuration mutt avec des lignes du type :

send-hook "!~l ~t machin\\.truc@bidule\\.wat" "set pgp_autoencrypt pgp_autosign"

pour chaque adresse machin.truc@bidule.wat présente dans le trousseau. Le script est trouvable par ici, et pour l'utiliser, il suffit de le rendre exécutable, de l'exécuter et de sourcer le fichier obtenu dans la configuration de mutt (il s'appelle par défaut pgp_auto). Vous pouvez aller jeter un œil au code du script si ça vous amuse, c'est du beau sed bien violent. Lancez le script à nouveau de temps en temps, lorsque votre trousseau grossit (demandez à cron de le faire une fois par semaine, par exemple).

Considérations de sécurité

Vous avez peut-être l'impression que vous avez fait dépendre plusieurs de vos mots de passe d'un mot de passe unique, ce qui n'a pas vraiment l'air d'améliorer la sécurité du système. C'est une remarque qui n'est pas totalement infondée, c'est pourquoi la phrase de passe GPG est extrêmement importante, et doit donc être solide et n'être stockée à aucun endroit du système (si il y a un mot de passe que vous devriez retenir par cœur et ne recopier nulle part, c'est celui-ci).

Néanmoins, maintenant, si on vous vole votre disque ou qu'on pirate votre ordinateur, l'attaquant n'a pas un accès direct aux mots de passe de vos comptes de messagerie - et si votre phrase de passe GPG est bonne, il ne pourra pas disposer des ressources matérielles nécessaires pour les trouver (ça lui est totalement impossible sans votre phrase de passe). Vous me direz « mais gpg-agent retient mon mot de passe, donc il doit bien être quelque part… » : vous avez raison, mais gpg-agent stocke ce mot de passe dans la RAM : dès que votre ordinateur est éteint, il disparaît en quelques secondes (à moins de plonger ladite RAM dans de l'azote liquide - mais ça paraît raisonnable de supposer que le risque est minime). Pas de problème à ce niveau-là non plus, donc !

Si vous voulez faire les choses jusqu'au bout et suivre les conseils avancés des professionnels de la sécurité des systèmes d'information, cette page (en anglais) répertorie les pratiques à adopter pour limiter les risques au maximum.

Conclusion

C'est à peu près tout, je crois. Et comme je ne crois pas avoir raté quoi que ce soit de majeur, j'imagine que ça conclut cette série sur la gestion locale de ses mails avec des outils légers, bien conçus et configurables à l'infini ; le tout avec une bonne couche de sécurité. N'hésitez pas à m'envoyer corrections et suggestions pour améliorer cette série de tutoriels !

^{Au risque de me répéter d'article en article, un grand merci à
a3nm pour ses remarques et suggestions ayant permis de
compléter et d'améliorer ce billet.}

Gérer ses mails en local : étape 0, introduction.

2014-04-08T00:00:00+02:00

Ce billet est le premier d'une courte série d'articles longs. Elle a pour objectif de décrire la façon dont je gère mes courriels en local, sur mon laptop, sous la forme d'un tutoriel que j'espère accessible pour quelqu'un de débutant qui veut démarrer avec mutt.

Depuis le logiciel utilisé pour se connecter en IMAP sur mon compte et récupérer les nouveaux messages, jusqu'au client SMTP qui s'occupe de les envoyer, en passant par tous les petits trucs de configuration que j'utilise pour gérer mes différentes boîtes mail, je vais essayer d'être à peu près exhaustif.

Précisons dès maintenant que le but de cette est de présenter une configuration faite pour fonctionner avec mutt. Elle est adaptable pour un autre client mail minimaliste, mais si vous voulez utiliser un gros logiciel qui fait du tout-en-un (comme Thunderbird), ça n'est pas du tout pertinent de suivre ce tutoriel.

Je vais commencer par les trucs simples et nécessaires pour finir sur les trucs et astuces divers qui rendent mes fichiers de configuration longs et compliqués, qui maximisent le confort d'utilisation et qui constituent un exemple de la puissance potentielle de mutt (ou au moins d'une petite partie).

Un détail technique : ce tutoriel décrit la configuration de mon laptop, qui tourne sous Debian Sid. Il devrait cependant être adaptable sans problème pour n'importe quelle machine sous Linux et probablement aussi sous d'autres systèmes Unix : on ne manipule que des fichiers de config' dans le $HOME et tous les logiciels utilisés sont disponibles sous n'importe quelle distribution.

Donc, dans l'ordre.

Étape 0 : Introduction ← vous êtes ici !
Étape 1 : Synchronisation IMAP avec OfflineIMAP
Étape 2 : Envoi d'e-mails avec msmtp et msmtpq
Étape 3 : Configuration de mutt
Étape 3 bis : Dose supplémentaire de mutt
Étape 4 : Chiffrement et signature avec PGP

Bonne lecture !

Gérer ses mails en local : étape 1, sychronisation IMAP avec OfflineIMAP.

2014-04-08T00:00:00+02:00

Étape 0 : Introduction
Étape 1 : Synchronisation IMAP avec OfflineIMAP ← vous êtes ici !
Étape 2 : Envoi d'e-mails avec msmtp et msmtpq
Étape 3 : Configuration de mutt
Étape 3 bis : Dose supplémentaire de mutt
Étape 4 : Chiffrement et signature avec PGP

Donc, OfflineIMAP est un utilitaire qui va aller se connecter à un serveur IMAP et copier tout ce qu'il y a dedans. En fait, il va même faire mieux que ça : il va synchroniser tout ce qui se passe d'un côté de l'autre, pour que ce soit toujours le même contenu qui soit sur le serveur et sur le client. Par exemple, si je me connecte avec OfflineIMAP à une adresse GMail, que je récupère un message non lu et que je l'ouvre avec un client mail, à la prochaine exécution de OfflineIMAP, il va envoyer au serveur « C'est bon, tu peux noter que ce mail a été lu ». De la même façon, si je supprime un mail du côté client, ça va le supprimer sur le serveur - bien entendu, ce comportement par défaut peut être changé.

Donc, commençons par le début.

Installation et configuration

On installe OfflineIMAP :

aptitude install offlineimap

on crée un dossier pour mettre les mails qu'on va récupérer :

mkdir ~/Mail

et on modifie le fichier de config', ~/.offlineimaprc (en le créant si ça n'a pas été fait automatiquement lors de l'installation).

Le fichier de config' de OfflineIMAP est très simple à comprendre et à modifier. Il commence par une section [general] qui va contenir des morceaux de configuration globale :

[general]
accounts = dam,spam,ddf
ui = quiet

ici, la ligne accounts = dam,spam,ddf déclare les différents comptes auxquels il va se connecter, et la ligne ui = quiet signifie que lorsqu'on lance offlineimap, on ne veut pas qu'il pose de questions à l'utilisateur (ce qui est logique, étant donné qu'on va exécuter cette commande automatiquement plus tard). Changez dam,spam,ddf en des noms (quelconques) pour reconnaître vos différentes adresses mail avant de poursuivre.

Pour chaque compte c ainsi défini, on va ajouter trois sections : [Account c], [Repository c_local] et [Repository c_remote]. Voici par exemple ce que contient la section pour mon compte nommé dam :

[Account dam]    
localrepository = damien_local
remoterepository = damien_remote

[Repository dam_local]
type = Maildir
localfolders = ~/Mail/ikura_damien/

[Repository dam_remote]
type = IMAP
remotehost = desfontain.es
remoteuser = damien
remotepass = nyyunvygbgururyvksbffvy
ssl = yes
sslcacertfile = /etc/ssl/certs/ca-certificates.crt

La plupart des lignes se comprennent immédiatement.

Les trois premières sont juste des déclarations pour la suite.
La section [Repository dam_local] contient des informations comme le type de la boîte mail locale (« Veut-on stocker tous ses mails dans un seul gros fichier ou bien plutôt avoir un fichier par e-mail dans un gros dossier ? » - la bonne réponse à cette question est « un fichier par e-mail », d'où le type Maildir et non pas Mailbox), et le dossier qui va contenir les mails de ce compte.
La section [Repository dam_remote] contient le type de la connexion distante, l'adresse du serveur, l'utilisateur, le mot de passe, le fait qu'on utilise SSL et l'emplacement des certificats. Si votre adresse est truc@machin.com, vous avez probablement envie de remplacer damien par truc et desfontain.es par imap.machin.com, ou machin.com, ou encore autre chose suivant le nom du serveur IMAP auquel vous voulez vous connectez. Les noms des serveurs IMAP des principaux fournisseurs d'accès sont trouvables par ici. Bien sûr, il faut aussi remplacer le mot de passe. Les deux commandes concernant SSL sont importantes, sans ça, votre mot de passe va joyeusement voyager en clair jusqu'au serveur.

Cette configuration marche si vous avez votre propre serveur IMAP, et fonctionne pour à peu près tous les fournisseurs de mail… Sauf GMail, qui a une configuration aussi bizarre que décriée par ceux qui programment des logiciels comme OfflineIMAP. Pour synchroniser une adresse GMail, la section remote doit ressembler à :

type = Gmail
remoteuser = ddfontaines@gmail.com
remotepass = eryrnfrgursnyfrcebcurg
realdelete = no

où realdelete vaut no si l'on veut que supprimer un mail en local le mette dans la corbeille de GMail, et yes si on veut le supprimer du serveur « pour de vrai ».

Automatisation avec cron

On n'a clairement pas envie de taper offlineimap dans une console à chaque fois que l'on veut récupérer ses mails. Il convient donc de dire au système de faire ça tout seul comme un grand. Pour ça, on utilise cron, installé de base sous Debian et dérivés, programme qui lit un fichier de configuration et exécute les commandes qu'il y a dedans à intervalles réguliers. Pour modifier ce fichier, on tape dans une console :

`crontab -e`

et on rajoute une ligne ressemblant à ça :

`*/2 * * * * /usr/bin/offlineimap > /dev/null 2> /dev/null

en remplaçant les deux /dev/null par les endroits où on veut logger ce que renvoie la commande, si on a envie de le faire. Le */2 * * * * signifie « toutes les deux minutes », et on peut le modifier pour changer la fréquence à laquelle on veut que le système aille chercher les nouveaux messages. Pour plus d'informations sur la syntaxe de cron, on peut aller voir sa page Wikipédia, par exemple.

Il y aurait plus à dire sur OfflineIMAP, notamment la possibilité de ne récupérer que certains dossiers d'un compte sur un serveur IMAP, mais ça sort du cadre de ce billet.

Gérer ses mails en local : étape 2, envoi d'e-mails avec msmtp et msmtpq.

2014-04-08T00:00:00+02:00

Étape 0 : Introduction
Étape 1 : Synchronisation IMAP avec OfflineIMAP
Étape 2 : Envoi d'e-mails avec msmtp et msmtpq ← vous êtes ici !
Étape 3 : Configuration de mutt
Étape 3 bis : Dose supplémentaire de mutt
Étape 4 : Chiffrement et signature avec PGP

Donc, maintenant qu'on est arrivés à récupérer nos e-mails, on aimerait bien en envoyer. Mutt, le client mail, ne sait pas faire ça - ou pour être précis, depuis la dernière version, il sait faire ça, mais l'implémentation est récente et ne permet pas de faire une file d'attente de messages à envoyer lorsqu'on est hors ligne (on y reviendra). J'utilise donc msmtp qui fait bien son travail, qui est simple à configurer et qui vient avec une solution de queuing.

Configuration de base

Sans surprise, on installe msmtp :

aptitude install msmtp

et on ouvre le fichier ~/.msmtprc pour modifier la configuration.

Tout en haut du fichier, on trouve la configuration qui dit qu'on veut utiliser ssl (toujours pour ne pas envoyer son mot de passe en clair), qui précise qu'on veut avoir la méthode d'authentification la plus sûre disponible, qui choisit le fichier dans lequel msmtp va écrire des logs, et qui désactive les autres méthodes d'enregistrement de logs.

defaults
tls on
tls_starttls on
auth on
logfile /.msmtp.log
syslog off

Puis, pour chaque compte SMTP auquel on veut se connecter, on ajoute un bloc de configuration qui ressemble à ça :

account dam
host smtp.desfontain.es
port 465
user damien
password gungjbhyqunirorraorggre
from damien@desfontai.nes
tls_trust_file /etc/ssl/certs/ca-certificates.crt

en remplaçant smtp.desfontain.es et 465 par l'adresse de votre serveur SMTP et le port sur lequel il écoute (encore une fois, c'est trouvable par ici pour les principaux fournisseurs de mails), damien par ce qu'il y a à gauche du @ dans votre adresse mail, et en changeant le mot de passe et l'adresse mail. À partir de là, pour envoyer un mail écrit dans un fichier f, la commande à exécuter sera msmtp -a dam < f pour utiliser le bloc de configuration qui commence par account dam. Ne le faites pas, il faudrait que vous écriviez les headers à la main et ça serait un peu pénible =)

On peut rajouter autant de blocs de ce type que l'on veut dans le .msmtprc, pour pouvoir appeller msmtp avec différents arguments (et ainsi pouvoir se connecter à différents serveurs SMTP, ou au même serveur avec plusieurs comptes différents). Ah oui, dernière chose importante : le fichier .msmtprc doit avoir des permissions fixes pour que msmtp accepte de le lire, donc vous aurez peut-être besoin de lancer un chmod 600 ~/.msmtprc pour que ça fonctionne.

Faire du queuing avec msmtpq

Donc, on a un système d'envoi de mails qui fonctionne. Maintenant, si on veut répondre à un mail alors qu'on n'est pas connecté à Internet (dans un train, un avion, une salle de cours au wifi pourri de Paris 7…), la seule solution est de rédiger le mail, de l'enregistrer en brouillon dans le client mail, et de penser à l'envoyer plus tard lorsqu'on sera connecté. C'est pénible et ça a l'air automatisable… Ce qui me fait une excellente introduction pour msmtpq, un script qui permet de mettre tous les mails envoyés dans un dossier (qui agit comme une queue, ou file d'attente en bon français), et de les envoyer sur Internet dès que c'est possible.

Si vous avez installé msmtp par votre gestionnaire de paquets, vous avez déjà msmtpq qui traîne sur votre machine à un endroit obscur : /usr/share/doc/msmtp/examples/msmtpq. On va donc se connecter en root, mettre le script dans un endroit accessible pour l'utilisateur et changer trois lignes pour le configurer correctement.

su -
cd /usr/share/doc/msmtp/examples/msmtpq
cp msmtp* /usr/local/bin/
chmod +x /usr/local/bin/msmtpq /usr/local/bin/msmtp-queue

On ouvre le fichier /usr/local/bin/msmtpq, toujours en root, avec son éditeur préféré, et il y a deux lignes à modifier : celle qui commence par Q= et celle qui commence par LOG=. Dans les deux cas, il faut remplacer la valeur par défaut par (respectivement) le dossier dans lequel on a envie de stocker les mails de la file d'attente, et le fichier dans lequel on veut logger l'activité de msmtpq. Par exemple, chez moi :

Q=~/.msmtp.queue
LOG=~/.msmtp.queue.log

il faut créer le dossier et le fichier en question et leur donner les bonnes permissions, en utilisateur normal cette fois-ci :

mkdir ~/.msmtp.queue
chmod 700 ~/.msmtp.queue
chmod 600 .msmtp.log

et c'est tout ! Les derniers bouts de config' nécessaires pour utiliser msmtpq en pratique concernent mutt, donc on y reviendra.

Automatisation du processus

De la même façon que pour OfflineIMAP, on a envie de faire régulièrement des appels à msmtpq pour lui dire « si la file d'attente n'est pas vide, réessaie d'envoyer les mails qu'il y a dedans ». Ça se fait à la main avec la commande msmtp-queue -r, donc la ligne à rajouter dans le fichier qui s'ouvre en tapant crontab -e est :

*/2 * * * * /usr/local/bin/msmtp-queue -r > /dev/null 2> /dev/null

et voilà le travail.

Gérer ses mails en local : étape 3 bis, du rab' de mutt :D

2014-04-08T00:00:00+02:00

Étape 0 : Introduction
Étape 1 : Synchronisation IMAP avec OfflineIMAP
Étape 2 : Envoi d'e-mails avec msmtp et msmtpq
Étape 3 : Configuration de mutt
Étape 3 bis : Dose supplémentaire de mutt ← vous êtes ici !
Étape 4 : Chiffrement et signature avec PGP

Donc, au cas où je ne vous ai pas convaincu que mutt c'était le Bien™, que l'article précédent vous a laissé perplexes et que vous êtes en train de vous dire que c'est quand même beaucoup de travail pour avoir quelque chose de vraiment chouette à utiliser, je vais faire un second essai pour vous convaincre. Entre autres, je vais essayer de vous convaincre qu'on peut ajouter des fonctionnalités vraiment avancées et personnalisées si on a envie, tout comme on peut émuler à peu près n'importe quel avantage d'un client mail grand public.

Quelques macros pour commencer

Quand j'ai commencé à recevoir un nombre de mails par jour qui se comptait en dizaines et non plus en unités, il s'est vite posé le problème des mails importants qui se font enterrer sous des piles de messages qui le sont moins. Je me suis donc mis à utiliser la fonction « flag » (F comme raccourci, pour faire apparaître un message en surbrillance si on a un jeu de couleurs adapté) pour marquer tous les mails auxquels je devais répondre, ou qui contenaient quelque chose dont je devais m'occuper. Malheureusement, ça ne suffisait pas, une fois que le message en question était trop loin dans ma liste de mails pour apparaître, j'oubliais son existence.

J'ai trouvé une solution qui me convient en utilisant des macros qui listent les messages susceptibles d'être importants, et n'affichent que ceux-là. J'utilise des raccourcis commençant par une virgule, parce que c'est la touche qui fait office de <Leader> dans ma configuration de vim, du coup j'ai l'habitude de la combiner avec d'autres. Donc, les messages dont je suis susceptible de devoir m'occuper sont les messages marqués comme importants, ceux que je n'ai pas encore lus, ainsi que les récents auxquels je n'ai pas répondu alors qu'ils me sont adressés personnellement. Ça donne :

macro index ,r "l((~N|~O|~F)!~D!~P)|(~d<1w!~Q)\n"

ceux qui sont systématiquement dignes d'intérêt sont les messages non lus, ou ceux explicitement notés comme importants (avec la fonction de flag) :

macro index ,i "l((~N|~O|~F)!~D!~P)\n"

et on a besoin d'un raccourci facile pour revenir à la vue normale, où l'on voit tous les mails :

macro index ,, "l~A\n"

ce qui fait que cette astuce n'est pas juste un bout de config' dont je ne me sers pas, c'est qu'en fait, j'exécute la commande ,r (qui montre les messages potentiellement intéressants) à chaque fois que j'ouvre un dossier dans mutt :

folder-hook . push ',r=*'

et cette vue-là contient (en pratique) toujours les mails marqués comme importants, parce qu'elle cache tous les mails auxquels j'ai répondu ou ceux dont je ne suis pas le destinataire.

Gérer les pièces jointes et les mails en HTML

Dans un client mail graphique, on peut en général naviguer dans un menu pour indiquer au programme avec quoi on veut ouvrir les pièces jointes. Dans mutt, cette configuration se fait via le fichier indiqué dans la variable maicap_path du .muttrc. Dans le mien, il y a :

set mailcap_path = ~/.mutt/mailcap

et dans le fichier en question, on met une ligne par type de fichier. Par exemple, dans le mien, on trouve :

application/pdf; chromium %s
image/*; feh %s

pour dire d'ouvrir les PDFs avec Chromium (oui, c'est ce que j'utilise comme lecteur PDF, faute de mieux), et les fichiers de type « image » (jpg, png, etc.) avec feh.

Le fichier mailcap sert aussi à indiquer comment on veut lire les mails en HTML. Ces atrocités ne devraient pas exister et les auteurs des clients mails qui en envoient par défaut devraient mourir par le feu, mais dans la vraie vie, les mails en HTML existent, on les reçoit et il faut bien en faire quelque chose. J'utilisais une solution sale à base de w3m à une époque, et puis a3nm m'a soufflé la solution tout aussi crade mais un peu plus efficace suivante :

text/html; ~/.bin/mutt_bgrun firefox %s > /dev/null 2> /dev/null; nametemplate=%s.html
text/html; iconv -f %{charset} %s | elinks -dump %{charset} -dump -dump-color-mode 1 -dump-width 76 /dev/stdin 2>/dev/null | sed 's/ * $//' | sed 's/   //' ; copiousoutput

elle utilise links par défaut pour afficher le corps du message (ce qui donne en général un résultat, heu, pas très beau, mais si le contenu n'est pas trop bourré de CSS affreux, ça reste lisible, et ça permet d'afficher rapidement les liens présents dedans). Si ça ne suffit pas, alors je tape v pour ouvrir la liste des fichiers constituant le mail, et si je sélectionne celui en .html, c'est Firefox qui me l'ouvre dans un nouvel onglet. C'est assez sale parce qu'il faut un script supplémentaire (disponible ici, ce n'est pas moi qui l'ai écrit) et que l'appel à ELinks est prévue pour fonctionner avec une taille de fenêtre fixe (ici, 76 caractères de large).

Le contenu complet de mon fichier mailcap est disponible par ici.

Un script pour les étourdis dans mon genre

Ça va paraître absurde, mais une des choses qui m'a le plus manqué quand je suis passé de l'interface Web de GMail à mutt, c'est la fonctionnalité (ou peut-être est-ce une extension, je ne me souviens plus) « afficher un message de confirmation lorsqu'on essaie d'envoyer un message dont le contenu a l'air de sous-entendre qu'il faudrait qu'il y ait une pièce jointe, mais qu'il n'y en a pas ». Parce que les mails suivis immédiatement d'un second mail « Oups, j'ai oublié la pièce jointe, la voilà », ça ne fait pas très sérieux (surtout quand on oublie la pièce jointe dans le second mail (ne riez pas)).

Mais, magie des possibilités infinies de configuration de mutt, il suffit de faire un script qui fait ça. J'en ai trouvé un sur le wiki de mutt, que je me souviens d'avoir modifié à plusieurs reprises mais je ne me souviens plus pourquoi exactement. La version que j'utilise est disponible par là, et l'idée est de remplacer l'appel à msmtpq de la variable sendmail du .muttrc par un appel à ce script. Si on l'appelle avec des paramètres, il appellera msmtpq avec les mêmes paramètres, donc ça marche bien (et ça m'a évité d'être ridicule un nombre de fois ridiculeusement élevé). Il nécessite zenity pour afficher le message de confirmation.

t-prot, pour économiser de la place sur l'écran

Je n'ai rien contre les gens qui répondent aux mails en coupant le message original en morceaux, et en répondant entre les morceaux : lorsque le mail concerne plusieurs points distincts, c'est plutôt pratique et je fais moi-même comme ça de temps en temps. Le problème, c'est que les informations moins utiles (les anciens messages auxquels on répond, qui portent le joli nom de TOFU) peuvent parfois prendre une place démesurée sur l'écran, si on ne prend pas la peine de couper le passage cité et qu'il y a plusieurs réponses imbriquées. Sur certaines mailing-lists, c'est un vrai problème, parce que six pages successives pour un message où il n'y a qu'une vingtaine de lignes ajoutées par rapport aux messages précédents, c'est pas du tout pratique.

Et donc sans surprise, des gens ont écrit un script qui résout le problème, et qui tronque le TOFU pour faciliter la lecture du nouveau contenu. Ça s'appelle t-prot, c'est disponible par ici et l'installation consiste juste à le mettre quelque part dans son $PATH en le rendant exécutable. Puis, dans le .muttrc, il faut ajouter quelques lignes pour l'invoquer automatiquement…

set display_filter='t-prot -cemt --pgp-move-vrf --pgp-short --bigq=10,4 -Mmutt -S -s -w'

… quelques macros pour s'en servir aisément (ici, 0 pour voir le message original, et 1 pour réactiver le tronquage du TOFU)…

macro generic 0 ":unset display_filter\n" "Turn TOFU protection off"
macro generic 1 ":set display_filter='t-prot -cemt --bigq=10,4 -M=mutt -S -s -w'\n" "Turn TOFU protection on"
macro pager 0 ":unset display_filter; exec exit\n:exec display-message\n" "Turn TOFU protection off"
macro pager 1 ":set display_filter='t-prot -cemt --bigq=10,4 -M=mutt -S -s -w'; exec exit\n:exec display-message\n" "Turn TOFU protection on"

… et un peu de couleurs pour qu'on voie quand t-prot a fait disparaître quelque chose :

color body      brightmagenta   black   "^\\[---.*"
color body      green           black   "^#v[-+]"

si vous êtes inscrits sur des listes de diffusion, ce truc tout bête a le potentiel de vous changer la vie :-)

Indexation efficace avec notmuch

Une des choses qui a probablement fait le succès de GMail, c'est son outil de recherche de messages : rapide, efficace et facile à utiliser. Mutt a aussi un système de recherche utilisant des expressions régulières, et qui est donc très puissant et permet de faire des requêtes qui correspondent exactement à ce qu'on recherche. Le problème, c'est que lorsqu'on commence à vouloir rechercher un terme présent dans le corps d'un message parmi une boîte mail en contenant plusieurs milliers… Ça prend un temps linéaire en la taille de la boîte et donc c'est un peu long.

Mais joie, bonheur et allégresse : il existe un indexeur, Notmuch, qui permet de rendre le traitement de ce type de requête instantanée. Ça prend un peu de place sur le disque dur (j'ai 4 Go de mails, et les bases de données de notmuch nécessitent 700 Mo), mais vu le prix du Go de nos jours, c'est vraiment pas un problème. Donc, pour installer cette petite merveille, on passe par les paquets :

aptitude install notmuch

et on a un peu de configuration à faire une fois que c'est fait, mais il n'y a même pas besoin de modifier le moindre fichier de configuration. Il suffit en effet de lancer la commande :

notmuch setup

et de répondre gentiment aux questions permettant au programme de savoir quels sont les mails qui viennent de nous, où ils se trouvent sur le système, etc.

Une fois que c'est fait, on rajoute quelques macros dans mutt pour utiliser la recherche par notmuch de la façon la plus naturelle possible :

macro index S "<enter-command>unset wait_key<enter><shell-escape>notmuch-mutt --prompt search<enter><change-folder-readonly>~/.cache/notmuch/mutt/results<enter>" "search mail (using notmuch)"
macro index L "<enter-command>unset wait_key<enter><shell-escape>read -p 'notmuch query: ' x; echo \$x >~/.cache/mutt_terms<enter><limit>~i \"\`notmuch search --output=messages \$(cat ~/.cache/mutt_terms) | head -n 600 | perl -le '@a=<>;chomp@a;s/\^id:// for@a;$,=\"|\";print@a'\`\"<enter>" "show only messages matching a notmuch pattern"

ici, les touches S et L (respectivement « Search » et « Limit ») fonctionnent de la même façon que leurs homologues en minuscules par défaut dans mutt, sauf qu'ils utilisent le moteur de notmuch pour faire leur recherche. C'est aussi simple que ça !

On me signale dans l'oreillette que notmuch permet de faire des choses encore plus cool que ça, par exemple de l'étiquetage de messages, mais n'ayant jamais testé cette fonctionnalité, je ne peux pas vous en dire grand-chose.

Conclusion provisoire

Bon, cette fois, je ne crois pas avoir oublié grand-chose (mis à part l'utilisation intensive de PGP qui mérite un article à part). Il faudrait peut-être que je mentionne le réglage sendmail_wait de mutt, qui est un compromis relativement important entre le temps d'attente nécessaire pour mettre un mail envoyé dans la file de msmtpq, et le temps que je me laisse pour répondre « non » au script qui vérifie si je n'ai pas oublié une pièce jointe, mais du coup, je ne sais pas trop dans quelle section en parler. Je verrai ça plus tard.

Gérer ses mails en local : étape 3, rendre le tout utilisable avec mutt !

2014-04-08T00:00:00+02:00

Étape 0 : Introduction
Étape 1 : Synchronisation IMAP avec OfflineIMAP
Étape 2 : Envoi d'e-mails avec msmtp et msmtpq
Étape 3 : Configuration de mutt ← vous êtes ici !
Étape 3 bis : Dose supplémentaire de mutt
Étape 4 : Chiffrement et signature avec PGP

On commence enfin à en avoir fini avec la configuration « sous le capot », et on va enfin pouvoir voir directement les conséquences de nos bidouillages. Je vous présente donc Mutt, le client mail moins pourri que les autres.

_{C'est même, à traduction approximative près, leur slogan
officiel.}

Mutt est un client mail en mode console qui, conformément à la philosophie Unix, a été conçu pour être uniquement un client mail, c'est à dire qui lit un dossier de types Maildir, et qui permet de gérer son contenu efficacement. Il est très rapide, efficace, clair, et surtout, configurable à l'infini.

Installation et premiers pas

Pour l'installer, sans surprise, aptitude install mutt en root fera l'affaire. Pour le lancer, il suffit de lui préciser le dossier que l'on veut qu'il lise. Par exemple :

mutt -f ~/Mail/ikura_damien

vu que dans mon .offlineimaprc, j'avais indiqué ce dossier comme destination d'une de mes boîtes mail.

Je laisse faire au lecteur ses premiers pas dans mutt. Globalement, c'est plutôt intuitif - j/k ou les flèches directionnelles pour se déplacer, Entrée pour ouvrir un mail, q pour revenir au menu précédent… Dès qu'on cherche à faire une action, il suffit de taper ? au clavier pour obtenir la liste des commandes disponibles avec une description courte. On s'y fait assez vite, il n'y a pas besoin d'un tutoriel détaillé comme pour vim, par exemple. Par contre, par défaut, la configuration n'est pas très utilisable. Modifions donc le fichier de config', ~/.muttrc, pour en faire un mutt aux petits oignons qui fait exactement ce qu'on veut.

Évidemment, en pratique, devoir taper quelque chose d'aussi comme mutt -f ~/Mail/ikura_damien quand on veut ouvrir sa boîte mail, c'est affreusement long, donc j'ai un alias dans mon ~/.bash_aliases :

alias dam="mutt -f ~/Mail/dam"

où dam est un lien symbolique vers ~/Mail/ikura_damien (ce qui permet de changer de dossier dans mutt en cliquant c, et en entrant =dam, au lieu de =ikura_damien).

Réglages internes

Alias

Mutt a un système d'alias minimaliste que je trouve pratique. L'idée est de taper « maman » dans le champ « To: » d'un mail qu'on veut envoyer, au lieu de adressedemamaman@gmail.com. Pour ajouter un alias, appuyer sur a alors qu'un mail de la personne en question est sélectionné.

set alias_file=~/.muttalias
source ~/.muttalias
set reverse_alias

Je sais que d'autres utilisent des logiciels de carnet d'adresses plus complexes (abook, ou des systèmes basés sur ldbd) mais en ce qui me concerne, ça me suffit.

Cache

Mutt a une fonction, désactivée par défaut, pour mettre certaines données (des en-têtes ou même le contenu de messages) en cache quelque part. Ça permet, notamment, de charger beaucoup plus rapidement le contenu de boîtes de réception récemment ouvertes. Pour activer cette fonction, on peut par exemple créer un dossier cache dans le ~/.mutt et ajouter :

set header_cache = ~/.mutt/cache/headers
set message_cachedir = ~/.mutt/cache/bodies

dans le ~/.muttrc.

Identités alternatives

Le comportement de mutt dépend parfois de la condition « est-ce que le message courant est un message reçu, ou un message envoyé » (par exemple, si on essaie de « répondre » à un message qu'on a envoyé, on a pas envie de se répondre à soi-même…). Et comme tout ce qu'il sait faire, c'est lire le contenu de dossiers, il n'a pas de méthode infaillible pour ça. Il faut donc l'aider avec un morceau de configuration dans lequel on lui dit quelles adresses e-mail sont les notres.

alternates ".*@desfontain.es|ddfontaines@gmail.com"

Configuration spécifique au dossier dans lequel on se trouve

C'est bien beau, tout ça, mais on aimerait bien que mutt interagisse avec le reste du système. Par exemple, qu'il sache quelle commande exécuter lorsqu'on lui dit d'envoyer un mail. Le paramètre pour ça s'appelle sendmail. Assez logiquement, si on veut utiliser msmtpq, il faudrait entrer :

set sendmail = "/usr/local/bin/msmtpq"

sauf que c'est plus compliqué que ça : on veut utiliser le contenu du .msmtprc pour envoyer les e-mails de plusieurs façons différentes, suivant si on est dans une boîte ou dans une autre.

On peut faire ça dans mutt, en utilisant des hooks. Dans le .muttrc, on met quelque chose de ce type :

folder-hook +dam "source ~/.mutt/damien"
folder-hook +ikura_damien/.* "source ~/.mutt/damien"

pour chaque dossier en local. Le fichier indiqué, ici ~/.mutt/damien, contient des morceaux de configuration qui ne seront pris en compte que si le dossier courant est ~/Mail/ikura_damien ou ~/Mail/dam. Dans le morceau de configuration en question, on met donc plein de choses.

On précise à msmtp la section de sa configuration à utiliser quand on veut envoyer un mail :

set sendmail = "/usr/local/bin/msmtpq -a damien"

on envoie les mails en mettant le bon champ « From: » :

set from = "damien@desfontai.nes"

on se met en copie de chaque mail envoyé (pas mal de gens avec qui j'ai discuté trouvent ça bizarre, moi j'aime bien voir sur une même page les mails que j'envoie et ceux que je reçois) :

my_hdr bcc: damien@desfontai.nes

du coup, ça ne sert à rien de garder une copie des mails envoyés dans un autre dossier :

unset record

et enfin, on indique l'endroit où on veut stocker les brouillons :

set postponed=+"ikura_damien/drafts"

Affichage et interface

Moins de questions, plus d'efficacité

Pas besoin de demander confirmation avant de sauver un message dans un dossier ou lorsqu'un message est déplacé par un script :

set noconfirmappend
set move = no

pas non plus besoin de poser cinquante mille questions sur les headers lorsqu'on répond à un mail :

set fast_reply

pour envoyer un mail, appuyer sur « Entrée » après avoir fermé l'éditeur, ça paraît naturel :

bind compose <Return> send-message

par ailleurs, ouvrir les boîtes mails compressées naturellement, ça permet de gagner du temps le jour où on en a l'utilité :

open-hook \\.gz$ "gzip -cd %f > %t"
close-hook \\.gz$ "gzip -c %t > %f"
append-hook \\.gz$ "gzip -c %t >> %f"

et d'un coup, ça va déjà plus vite :-)

Utiliser l'éditeur de son choix

Évidemment, une grande partie du temps qu'on passe sur un client mail consiste à envoyer des mails, donc le choix (et la bonne configuration) de l'éditeur de texte utilisé est aussi important que celui du client mail lui-même.

set editor="vim -c 'set tw=70 et'"

J'utilise vim, avec ma configuration habituelle (que je détaillerai dans un prochain billet, peut-être, un jour), en lui indiquant en plus d'utiliser des lignes de 70 caractères, pour être non seulement en règle vis-à-vis de la RFC sur le sujet mais pour avoir un peu de marge (et que les réponses, qui vont décaler chaque ligne de deux caractères en rajoutant les >, respectent toujours la RFC).

En passant, on en profite pour afficher les en-têtes du mail dans l'éditeur lui-même, ce qui permet de rajouter des destinataires ou de changer le sujet plus facilement qu'en faisant ça à l'intérieur de mutt.

set edit_headers = yes

Ah, et les signatures automatiques, je trouve ça horripilant, donc évitons.

unset signature

Avoir un joli affichage, c'est important

Par défaut, mutt manque sacrément de couleurs, et n'a pas vraiment une utilisation optimale de l'écran par défaut. Bien entendu, ses possibilités infinies de configuration permettent facilement non seulement de combler les lacunes de l'affichage par défaut, mais aussi d'obtenir une interface qui convient exactement aux besoins de chaque utilisateur.

Déjà, on utilise le pager de mutt parce que généralement, on a de la place sur l'écran : quand on consulte un message, on a une partie de l'écran qui permet de voir quels sont les quelques mails précédents et suivants, comme un petit menu. C'est très pratique.

set pager_context=5
set pager_index_lines=6

Ensuite, j'ai horreur de l'affichage de la liste de mails « par pages », où lorsqu'on descend plus bas que ce qui est déjà affiché, on se retrouve tout en haut de la page suivante. C'est beaucoup moins fluide qu'avec le bout de config' qui supprime ce phénomène.

set menu_scroll
set menu_context=6

Quand quelqu'un répond à un mail, on a envie de pouvoir accéder au mail original rapidement, et c'est particulièrement vrai lors de grosses discussions avec plein de ramifications. On va donc dire à mutt de trier les messages par fil de discussion, et il va même nous afficher les discussions compliquées sous la forme d'un joli arbre dans la liste.

set sort=threads
set sort_aux="last-date-received"
set strict_threads

Des couleurs, vite !

Bon, ça va déjà mieux, mais ça manque d'un truc important : la couleur. Avec les hooks de mutt, on peut profiter de la puissance des expressions régulières pour colorer n'importe quoi de n'importe quelle couleur. Ce morceau de config' prend vite de la place, donc on peut le mettre dans un fichier à part, que l'on appelle de la façon suivante :

source ~/.mutt/colors

j'ai mis mon ~/.mutt/colors personnel en ligne. Je ne pourrais pas me passer de la fonction qui colore les mails adressés à moi personnellement différemment (de façon beaucoup plus visible) que les mails reçus parce que je suis sur une liste de diffusion : en général, ceux de la première catégorie sont beaucoup plus importants.

Pour une interface vraiment aux petits oignons

Continuons avec quelques trucs moins importants, qui sont plus du confort qu'autre chose. La genre de barre bleue en haut ne sert franchement à rien donc enlevons-la :

set help = no

j'aime bien marquer visuellement la fin des e-mails par des tildes :

set tilde

je n'ai pas envie de « voir » quand une ligne a été coupée en deux, c'est moche :

set nomarkers

je n'ai pas envie de voir toutes les en-têtes d'un mail, mais seulement celles susceptibles de m'intéresser :

ignore *
unignore From: Subject To Cc Date Reply Organization Newsgroup

j'ai envie que les lignes soient coupées intelligemment, entre les mots, lorsqu'elles ne tiennent pas sur l'écran :

set smart_wrap

je suis content que les entrées du menu « alias » soient triés en fonction de l'alias et non pas du nom ou de l'adresse réelle de la personne :

set sort_alias = alias

et pour finir, afficher la version de mutt au démarrage, ça ne coûte rien et c'est joli :

push <show-version>

joie, bonheur, allégresse, mon client mail ressemble exactement à ce dont je rêvais quand j'étais petit.

Faire fonctionner un tunnel IP over DNS

2014-02-05T00:00:00+01:00

J'ai essayé de faire fonctionner une solution IP over DNS sur mon serveur l'autre jour, et après avoir un peu galéré, j'ai fini par y arriver. J'ai été assez désagréablement surpris de la qualité médiocre des tutoriaux disponibles en ligne sur le sujet : la majorité donnent plein de détails inutiles (en expliquant par exemple comment on installe un logiciel) et considèrent qu'une fois qu'on a fait marcher la configuration de base, on a gagné et finissent là le tutoriel (alors qu'en pratique, on a envie de faire autre chose que juste envoyer des pings sur le serveur, et c'est pas évident si on ne sait pas comment faire).

Ce billet est donc une tentative d'expliquer le principe, la configuration et l'utilisation d'un logiciel qui s'appelle iodine et qui fait de l'IP over DNS.

Principe et intérêt

Vous pouvez sauter jusqu'au dernier paragraphe de cette section si vous vous fichez de savoir ce qui se passe à « bas niveau » lors d'un tunnelling IP over DNS et que vous voulez juste savoir comment on arrive à l'étape « se connecter à Internet sans payer depuis un wifi mal protégé ». Ce qui suit est inspiré en grande partie par ce billet publié par Digital Bond sur le sujet.

Quand on utilise Internet, par exemple quand on navigue sur le Web, ce qui se passe « en pratique », c'est que l'ordinateur qu'on utilise envoie des petits paquets IP qui contiennent des informations (par exemple, « je veux récupérer le contenu de cette page », « je veux envoyer tel mail à telle adresse », etc.). Dans ces paquets, le morceau d'information « cette page » ou « telle adresse » est différent de l'information que l'utilisateur a l'impression d'utiliser : il ne s'agit pas d'une adresse web comme https://desfontain.es/blog/, ou d'une jolie adresse mail, mais d'une adresse IP (du genre 5.9.79.154 ou 2a01:4f8:161:9281:4000::beef selon si on utilise IPv4 ou IPv6). Pour transformer la jolie adresse web qu'un humain peut retenir et communiquer facilement en une adresse IP, c'est le protocole DNS qui est utilisé. Donc, quand on tape http://damien.desfontain.es dans un navigateur, le navigateur va commencer par envoyer un paquet disant « je cherche l'adresse IP de damien.desfontain.es » à un serveur DNS local (dont il connaît déjà l'adresse IP), et le serveur DNS en question transmettra cette information jusqu'aux serveurs DNS responsable de la gestion de desfontain.es (dans mon cas, dns102.ovh.net et ns102.ovh.net). Ceux-là connaissent ma zone DNS, et la réponse se trouve dedans.

Lors de cette communication, des « données » sont échangées entre « la machine qui a originellement émis la requête DNS » et les serveurs DNS gérant mon serveur, ici les serveurs d'OVH. Je peux aussi choisir de ne pas déléguer tout ou partie de ma zone DNS, pour que lors d'une requête spéciale, ça ne soit pas les serveurs d'OVH qui soient interrogés mais le mien. Dans l'exemple qui suit, je modifie ma zone DNS pour dire « toutes les requêtes concernant des adresses finissant par .dns.desfontain.es sont gérées par mon serveur »… Et c'est ça qui permet de détourner l'utilité première du DNS pour faire des choses intéressantes.

En effet, supposons maintenant que la connexion qu'on utilise laisse passer les requêtes DNS mais bloque le reste. Rien ne m'empêche de coder des choses dans les données qui sont échangées par ce biais entre mon ordinateur local et mon serveur… Par exemple, des paquets IP « normaux ». C'est le principe de l'IP over DNS : on va envoyer depuis le client tout un tas de requêtes DNS de la forme « envoie-moi l'adresse associée à nudhrpbhpbh.dns.desfontain.es », où le serveur va répondre « c'est [une certaine adresse], et par ailleurs voilà un peu de données pour que le paquet fasse la bonne taille : lbhwhfgybfggurtnzr », et ce charabia correspond en fait à un échange contenant des données « intéressantes » encodées de cette façon.

Ça paraît tordu, mais en fait c'est utile : il est très fréquent (dans les gares, hôtels, aéroports, et même chez les particuliers munis de certaines box) de rencontrer des réseaux Wifi qui sont non protégés, mais qui redirigent toutes les requêtes HTTP vers une page (« portail captif ») qui demande des identifiants, ou propose de payer pour accéder à Internet par ce réseau. Ces réseaux bloquent toutes les requêtes, à part les requêtes DNS, qui sont nécessaires pour permettre la redirection des pages Web normales vers le portail captif, et la résolution des adresses « autorisées » (par exemple, la page d'authentification). Je crois. En fait, je ne suis pas certain de la raison profonde pour laquelle il n'existe pas de système de portail captif qui bloque les requêtes DNS sans embêter les utilisateurs normaux, mais vu que ça n'existe pas, je suppose qu'il doit y avoir une raison profonde. Si quelqu'un la connaît, ça m'intéresse.

Donc, faire passer tous les paquets IP par des requêtes DNS, ça sert à se connecter à Internet depuis un gros paquet d'endroits sans payer ni avoir les identifiants de tous les grands fournisseurs d'accès à Internet qui mettent des réseaux publics dans la box de leurs abonnés. Ça a l'air super cool comme ça donc avant qu'un lecteur enthousiaste ne passe une demi-heure à configurer ça et soit déçu à la fin, je préviens maintenant : même quand ça marche, c'est vraiment très, très lent, et la connexion est très loin d'être stable. C'est plus une solution d'appoint, et une démonstration de faisabilité intéressante.

Prérequis

Il faut pour utiliser cet outil, disposer d'un serveur sur lequel on peut installer iodine, et posséder un nom de domaine sur lequel on peut manipuler les entrées DNS. Je vais dans toute la suite supposer que les deux machines sont sous Linux.

On va dire que le serveur dont vous disposez a comme adresse coucou.com et que son IP est 42.17.42.17.

Configuration

Installation

Installer iodine sur le client et le serveur. Sous Debian et dérivés, on tape dans une console root :

aptitude install iodine

et pour les autres systèmes, allez voir le site officiel pour avoir les instructions d'installation.

Modification de la zone DNS

Ajouter les entrées suivantes à la zone DNS du serveur :

dns     IN  A   42.17.42.17
t       IN  NS  dns.coucou.com

et attendre que ça se propage (sinon, on fait des tests et on comprend pas pourquoi ça marche pas), quelques heures devraient être plus que largement suffisantes. C'est utile pour dire plus tard à iodine quel genre de requête écouter : en l'occurence, les requêtes sur t.coucou.com et non pas juste sur coucou.com comme en temps normal.

On peut remplacer "dns" par n'importe quoi, et "t" par n'importe quoi d'autre - par contre, le fait que "t" ne fasse qu'un seul caractère est relativement important, ça laisse plus de place pour les données et donc ça accélère la vitesse de connexion du tunnel DNS.

Lancement du démon sur le serveur

Lancer en root sur le serveur :

iodined 10.0.0.1 t.coucou.com

ce qui équivaut à lui dire « lance le démon d'iodine, donne l'adresse IP 10.0.0.1 au serveur, et fais-le écouter sur t.coucou.com ». Le programme demande un mot de passe, qui peut être n'importe quoi jusqu'à 32 caractères. Après cette commande, on peut vérifier notamment par :

ifconfig

(en root, toujours) qu'une nouvelle interface est apparue dans la liste (elle s'appelle en général dns0), c'est à travers elle que va passer tout le trafic géré par iodine.

Lancement du tunnel sur le client

Lancer en root sur le client :

iodine -f 42.17.42.17 t.coucou.com

l'option -f permet de lancer ça au premier plan et donc, de savoir si jamais ça plante. Évidemment, du coup, si on ferme le terminal dans lequel on a lancé la commande, ça marche plus. Dans la liste des lignes qui s'affichent alors, il devrait y avoir :

Setting IP of dns0 to 10.0.0.2
Server tunnel IP is 10.0.0.1

(avec potentiellement 10.0.0.autrechoseque2). Et comme pour le serveur, une catégorie de plus (aussi appelée dns0) devrait être apparue dans ce que renvoie (en root) :

ifconfig

Pour vérifier que tout va bien, on peut essayer de lancer :

ping 10.0.0.1

depuis le client, normalement ça devrait retourner quelque chose. De même, faire un ping sur 10.0.0.2 depuis le serveur devrait aussi retourner quelque chose. Sinon, hmmm, il y a un problème, et il faut vraisemblablement essayer de fouiller dans le manuel de iodine et de jouer avec les options.

Faire passer les paquets d'une interface à l'autre

Si on a réussi à pinger 10.0.0.1 depuis le client, ça veut dire qu'on arrive à lui dire bonjour en passant par DNS : c'est bien ! Maintenant, on aimerait faire un truc encore plus cool et accéder à l'extérieur. Par défaut, bien sûr, ça n'est pas possible : du point de vue du serveur, tout ce qui passe par l'interface dns0 n'a aucune raison d'être renvoyé sur autre chose. Il faut donc activer (en root) le forwarding d'une interface à l'autre :

sysctl -w net.ipv4.ip_forward=1

et lui dire plus précisément de renvoyer tout ce qui vient de 10.0.0.* (la plage d'adresses IP associées à iodine) vers eth0, et pareil dans l'autre sens (toujours en root) :

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

Si l'interface « normale » du serveur n'est pas eth0 (il faut aller voir dans ce que renvoie ifconfig pour le savoir), il faut bien sûr remplacer eth0 par l'interface pertinente par laquelle on se connecte à Internet en temps normal.

Tester si on arrive à dire bonjour à Internet

Normalement, à ce stade, on devrait atteindre l'extérieur en passant par notre jolie configuration. Vérifier que tout marche toujours bien et relancer les commandes iodined/iodine si besoin (la connexion peut mourir s'il ne passe rien dessus pendant trop longtemps), et essayer d'envoyer un message vers l'extérieur en passant par notre interface depuis le client :

ping -I dns0 google.com

si ça marche, joie, bonheur et allégresse.

Faire passer du SSH à travers notre tunnel

Bon, c'est bien gentil, mais on a envie de faire passer autre chose que ping par notre système. Par exemple, on voudrait bien faire passer du SSH. Mais contrairement à ping, il est impossible de dire à ssh « passe par telle interface », ça se décide au niveau du noyau. Il faut donc bidouiller le routage IP pour dire au noyau « envoie tout ce qui va vers telle machine par notre serveur ». Ça se fait de la façon suivante, en admettant que l'adresse IP du serveur SSH auquel vous vouliez vous connecter est 71.24.71.24 :

ip route add 71.24.71.24 via 10.0.0.1

(bien entendu, il faut faire ça en root, un utilisateur normal n'a pas le droit de décider de ce genre de truc). Maintenant, si on essaie :

ssh user@71.24.71.24

(ou bien l'URL du serveur et non pas son IP), ça va automatiquement passer par le tunnel. Si ça marche, joie, bonheur, et désillusion lorsqu'on ce rend compte à quel point ça lagge. C'est le prix de passer par des paquets DNS ! C'est pas vraiment prévu pour ça. Si ça marche pas, il y a quelque chose qui ne va pas.

Faire passer une connexion au Web à travers notre tunnel

Pour aller plus loin que « se connecter à une machine en SSH », on peut ajouter plus de choses dans la table de routage. Au lieu de router une machine en particulier, on peut router une plage d'adresses IP. Pour lui dire « ne prends en compte que les n premiers bits », on utilise la notation /n. Par exemple, la commande :

ip route add 71.24.0.0/16 via 10.0.0.1

signifie « fais passer tout ce qui vient d'une adresse en 71.24.*.* via 10.0.0.1 ». Ainsi, si un navigateur essaie d'accéder à un site appartenant à cette adresse IP, la requête va passer par le système d'IP over DNS. Le problème c'est qu'on ne veut pas que les requêtes DNS elles-mêmes passent par là (le DNS over DNS, c'est relativement dénué d'intérêt). La solution la plus simple est vraisemblablement de disposer d'un serveur SSH, et de passer par un tunnel SSH. Pour ça, on fait comme au point 7) en faisant passer les requêtes envoyées à l'adresse du serveur par 10.0.0.1, puis on lance :

ssh -ND 3128 user@serveur.com

sur le client. Cette commande ne renvoie rien et c'est normal, on laisse la fenêtre ouverte, on va régler les paramètres de proxy de son navigateur pour lui dire d'utiliser le proxy localhost, sur le port 3128, en précisant que c'est un proxy Socks version 5, et hop. Tout ce qui passe par le navigateur passera par le tunnel SSH, qui lui-même passe par le pont formé par iodine.

Magie ! On est essentiellement en train de faire de l'HTTP over SSH over DNS, ce qui est quand même rigolo.

Conclusion

Bon, revenons sur Terre, tout ça rame quand même affreusement. Si vous êtes arrivés jusqu'à ce stade, vous avez probablement eu l'occasion de réaliser que c'était quand même très, très moyennement utilisable. La « bonne » façon d'utiliser un tunnel DNS en pratique, c'est probablement de ne faire que du SSH, et d'aller chercher les informations qu'on veut récupérer en utilisant l'excellent Weboob ou bien un navigateur en mode texte. Ça permet que ça soit le serveur qui fasse les « vraies » requêtes qui prennent plein de bande passante, et que la seule chose qui passe du serveur au client, ce soit les requêtes et le texte des pages transformées. Pour avoir testé ça dans diverses situations, c'est généralement lent mais utilisable.

_{_{Merci à a3nm et louis
pour leur relecture et corrections.}}

De la configuration d'un serveur mail

2014-02-04T00:00:00+01:00

J'ai récemment installé un serveur mail sur mon serveur. Je voulais que tout soit autohébergé : les mails eux-mêmes, le moyen d'y accéder, ainsi que le serveur SMTP qui envoie les mails vers l'extérieur. Bien sûr, je tenais aussi à ce que tout ce qui pouvait être chiffré le soit, en particulier que je ne risque pas de me faire intercepter quoi que ce soit lorsque je me connecte au serveur. Ça m'a pris un temps vraiment long, j'ai perdu pas mal de temps sur quelques problèmes, et je n'ai trouvé nulle part une liste de toutes les choses qu'il fallait que je fasse pour arriver à mes fins.

Ce billet est donc une tentative d'établir cette liste, de mentionner chacun des problèmes embêtants que j'ai rencontré, et la façon dont j'en suis venu à bout. Ça ne sera pas un tutoriel détaillé, ça prendrait trop de temps de le faire, il aurait fallu que je note tout ce que j'ai fait au fur et à mesure pour ça. Info potentiellement utile : j'ai fait tout ça sur une machine qui tourne sous Debian Wheezy, avec un noyau 3.2.0-4-amd64.

Liste de trucs qu'il a fallu que je fasse

Installer les bons paquets Debian :
- postfix, le serveur mail ;
- dovecot-imapd, le serveur IMAP ;
- opendkim et opendkim-tools, qui sert ajouter le protocole DKIM à ses mails sortants, ce qui évite de passer pour un spammeur aux yeux de certains grands serveurs mails comme Yahoo! ;
- postfix-tls, pour que le serveur mail sache utiliser TLS ;
- et enfin, cyrus-common-2.2 et sasl2-bin, pour faire de l'authentification sécurisée au serveur SMTP.
Configurer ma zone DNS (sur le manager de la société qui me fournit mon nom de domaine, ici OVH) pour :
- rajouter un champ MX pour le serveur mail pour dire quel sous-domaine utiliser pour le SMTP sur desfontain.es (ici, smtp.desfontain.es) ;
- et ajouter deux champs (un de type A et un de type AAAA, respectivement pour l'IPv4 et pour l'IPv6) pour lier smtp.desfontain.es à la bonne IP.
Changer mon hostname en smtp.desfontain.es.
Ajouter un utilisateur par boîte mail que je veux créer.
Configurer Postfix et dovecot pour envoyer mes premiers mails.
Configurer les alias Postfix qui vont bien : j'ai envie que toutes les adresses du type ,se.niatnofsed@retsamtsop ,se.niatnofsed@retsamtsoh etc., atterrissent dans ma boîte mail, mais sans créer un utilisateur par adresse.
En profiter pour mettre des regex dans les alias en question : je veux que n'importe quelle adresse de la forme se.niatnofsed@iouqetropmin.maps soit reconnue comme valide et redirigée vers une adresse spam maître. Ça permet de donner une adresse différente à chaque fournisseur de serveur ou site marchand sur Internet, et si jamais des spammeurs la récupèrent, on peut savoir qui a vendu mon adresse (et lancer des œufs sur leur maison) et la bloquer.
Rajouter un champ SPF dans ma zone DNS pour ne pas passer pour un spammeur.
Configurer OpenDKIM pour encore moins passer pour un spammeur.
Rajouter un champ DKIM dans ma zone DNS pour que mes signatures DKIM puissent être vérifiées par les destinataires de mes messages.
Ajouter un reverse DNS IPv4 et IPv6 pour ne pas passer pour un spammeur aux yeux de Google, qui vérifie spécifiquement (pour une raison qui m'échappe, mais alors, complètement) que le DNS et que le reverse DNS correspondent. C'est un truc qui se configure dans les options de mon hébergeur, pas sur mon serveur lui-même.
Créer et mettre en place un certificat SSL signé par une autorité externe (StartSSL) sur desfontain.es. (Non, ça n'a aucun rapport avec le reste.)
Créer un certificat SSL pour smtp.desfontain.es, ici sur CAcert : autant c'est important d'avoir un certificat signé par une autorité reconnue par tout le monde pour mon site Web (je ne veux pas que les visiteurs de mon site reçoivent un message d'erreur lorsqu'ils essaient de s'y connecter en HTTPS), autant ça l'est beaucoup moins pour mon serveur SMTP où je suis a priori le seul à me connecter.

Normalement, avec ça, trouver les mots à googler pour chaque détape ne devrait pas être difficile. Comme d'habitude, si vous trouvez que quelque chose n'est pas clair et que vous avez des questions, n'hésitez pas à m'envoyer un mail.

Problèmes rencontrés

À l'étape d'ajout du champ SPF, j'ai mis du temps à comprendre qu'il fallait impérativement cliquer sur « Type SPF » dans le manager d'OVH, parce que même si en théorie ça Devrait Marcher™, ça ne fonctionnait pas lorsque je rajoutais un champ TXT comme l'indiquait mon tutoriel.
Exactement la même chose à l'étape d'ajout du champ DKIM. C'est très foireux parce qu'en plus, lorsque ça ne marche pas directement lorsqu'on change le DNS, c'est normal, il faut le temps que ça se propage, du coup on ne s'alarme pas, et on perd plein de temps.
La plus grosse prise de tête que j'ai eue était probablement pour établir une communication entre Postfix (qui forme et envoie les messages) et OpenDKIM (qui les signe avec la clé globale du serveur). Dans la majorité des tutoriaux que j'ai trouvé sur le sujet, les deux communiquent en passant par un port particulier de localhost. Pour une raison qui m'échappe toujours (un ami m'a après suggéré que c'était potentiellement parce qu'il y avait peut-être un localhost IPv4 et un localhost IPv6 ?), ça ne fonctionnait désespérément pas, alors même que les deux démons tournaient : netstat renvoyait bien opendkim qui écoutait sur le bon port, et les logs de postfix indiquaient désespérément « Connection refused ». Je m'en suis sorti en les faisant communiquer par un fichier de socket :
- dans /etc/defaults/opendkim :
```
SOCKET="local:/var/spool/postfix/var/run/opendkim/opendkim.sock"
```
- et dans /etc/postfix/main.conf :
```
smtpd_milters = unix:/var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock
```

Ah oui, et évidemment, au début, j'avais mis le même chemin dans les deux cas et ça ne marchait pas, parce que postfix est lancé dans un chroot.

Au moment où je voulais faire des tests d'authentification à mon serveur SMTP par SASL, la majorité des tutoriels utilisent la commande :
```
telnet smtp.serveur.ext 25
```

et il m'a fallu un certain temps pour piger que si ça ne fonctionnait pas, ça n'était pas à cause de mon serveur mais de mon fournisseur d'accès à Internet local qui bloquait le port 25. Pour pouvoir non seulement faire des tests mais aussi utiliser msmtp (mon client smtp local) depuis chez moi au quotidien, j'ai dû utiliser le port 465 à la place. Il a fallu que j'indique ça dans la configuration de msmtp en utilisant l'option port (incroyable), et que je décommente la ligne commençant par smtps dans /etc/postfix/master.cf.

Liens

J'ai pas noté au fur et à mesure ce que j'ai fait, j'aurais pu écrire un tutoriel bien mieux foutu si j'y avais pensé. Par contre, j'ai quand même l'habitude de mettre des liens en commentaire de mes fichiers de configuration, pour me souvenir de l'origine d'un bout de code. En général, le lien comporte des explications, donc ça aide à se souvenir de ce que telle ligne fait à cet endroit-là. Voilà donc la liste des liens présents dans mes fichiers de config' :

un article sur le site de StartSSL pour faire fonctionner nginx (mon serveur Web) avec SSL ;
un tutorial pour l'installation de OpenDKIM ;
une page de wiki pour la configuration « de base » du serveur mail - c'est en français, ce qui vaut la peine d'être mentionné ;
et un tutorial pour la configuration d'une authentification chiffrée via TLS au serveur SMTP.

Conclusion

C'était vraiment long de faire tout ça, de l'ordre de quelques dizaines d'heures. Une partie importante du travail que j'ai eu (et des soucis que j'ai rencontrés) vient du fait que je voulais avoir mon propre serveur SMTP, donc non seulement héberger le stockage de mes mails et la gestion de mon nom de domaine, mais aussi leur envoi vers l'extérieur. Il aurait probablement été plus simple d'utiliser un SMTP externe, par exemple celui de l'ENS. Mais j'ai appris plein de choses sur le fonctionnement du système d'e-mails, donc je ne regrette pas d'y avoir passé du temps.

J'ai fait tout ça dans le but de me rendre aussi indépendant que possible des services centralisés qui s'occupaient des mails auparavant, et pour avoir plus de contrôle sur le caractère privé de mes données. En pratique, l'immense majorité de mes mails est toujours interceptable (et, selon toute probabilité, interceptée) car une part infime de mes contacts utilise des méthodes de chiffrement comme GPG. Et comme le protocole d'envoi d'e-mails n'est clairement pas conçu pour la sécurité, les métadonnées sont toujours interceptables au moment où elles passent sur le réseau.

Néanmoins, je vois quelques différences importantes : d'une part, le contenu de mes correspondances n'est pas utilisé pour faire des statistiques ou de la publicité ciblée. D'autre part, si quelqu'un veut lire et surveiller mes mails, il faut qu'il intercepte ce que j'envoie et reçois en permanence, ça devient impossible d'aller juste voir mon fournisseur de messagerie électronique pour lui dire « tiens, fais-nous une copie des messages dans la boîte aux lettres de telle personne ». Ça me semble être une amélioration significative qui valait le coup d'y passer autant de temps.

En revanche, il faut admettre que le gain en terme de vie privée entre « avoir son propre serveur SMTP » et « utiliser un serveur SMTP externe de confiance (celui d'une université, par exemple) » est quasi-nul, et c'est pourtant ça qui m'a pris le plus de temps. Le seul avantage que je vois, c'est qu'on ne peut jamais être sûr qu'un serveur SMTP que l'on ne contrôle pas n'est pas compromis (c'est évident si on parle de ceux de multinationales américaines, mais après tout, ça n'est pas délirant d'imaginer que ceux des universités, points stratégiquement importants s'il en est, aient des backdoors de services de renseignements divers).

_{_{Merci à a3nm pour sa relecture et ses propositions
d'améliorations.}}

Bienvenue !

2014-02-03T00:00:00+01:00

Ici commence mon blog. Je n'ai qu'une vague idée de ce que je vais mettre dedans, ça va probablement être principalement constitué de morceaux de configuration, de compte-rendus de bidouillages, de coups de gueule divers et, soyons réalistes, d'une bonne dose de chaos. Il sera vraisemblablement écrit en français, parce que la majorité des articles que j'ai envie d'écrire pour l'instant existent déjà ailleurs, et en mieux, en anglais. Quand ce n'est pas le cas et que j'ai l'orgueil de penser que ce que je raconte est susceptible d'intéresser un plus large public, il est possible que j'écrive en anglais.

Je vais déjà commencer par faire une section « À propos » comme il est d'usage, puis je vais évoquer la licence sous laquelle ce blog est placé.

À propos

Je m'appelle Damien Desfontaines, et les informations que vous pourriez avoir envie de connaître sur moi se trouvent sur la version sérieuse de ma page personnelle. Allez jeter un coup d'œil à la version plus funky, elle est plutôt originale et vous amusera peut-être.

Je parle en mon nom propre seulement, toutes les divagations postées sur ce blog n'engagent que moi, et sauf mention contraire, je suis l'auteur de tous les billets.

La licence

Je profite de ce premier billet pour présenter la licence que j'utilise pour mon blog. Il s'agit de la CC0, plus connue sous le nom de « domaine public ». Un résumé en français est disponible par ici, et le texte légal en anglais peut se trouver par là. Ça signifie que j'abandonne tous mes droits sur ce que je publie ici : n'importe qui peut copier, modifier, ou distribuer tout ce que je raconte, sans avoir besoin de me demander ni même d'être obligé de me citer.

Ça me paraît un choix naturel, mais l'expérience montre que c'est une licence qui est rarement utilisée en pratique, même par les barbus libristes qui militent contre la propriété intellectuelle. Je vais tenter d'expliquer les deux propriétés principales de cette licence.

La première, c'est que le monde extérieur peut faire absolument n'importe quoi de ce mes travaux sans me demander mon avis. Le raisonnement derrière ça est simple : j'ai envie que le plus de monde possible aie un accès à ce que je peux publier, je n'ai pas la moindre intention de gagner des sous avec, et si quelqu'un a envie de réutiliser une partie de ce que j'ai fait (que ça soit pour une utilisation commerciale ou non - je ne pense pas que vouloir gagner de l'argent soit une motivation intrinsèquement mauvaise), je n'ai pas envie de l'embêter avec des obligations légales à me demander mon avis. Si il veut en faire quelque chose que je désapprouve, eh bien tant pis, il est libre de le faire. Je ne vois pas quelle légitimité j'aurais à dire « hé, non, je suis pas d'accord avec ce que tu dis là, donc vu que j'ai une possibilité légale de t'interdire de le dire (parce que tu réutilises une partie de mes travaux), je vais faire usage de cette possibilité pour te censurer », tout en continuant par ailleurs de militer pour une liberté d'expression la plus large et la plus exempte d'exceptions possible.

La seconde, et c'est celle que j'ai le plus de mal à expliquer aux gens, c'est que je ne considère pas que ce soit légitime de ma part d'exiger, en le précisant dans la licence sous laquelle je place mes textes, que l'on me cite à chaque fois que l'on réutilise mes travaux. Même les barbus les plus convaincus ont l'air de tenir à ce qu'on les crédite lorsqu'on réutilise ce qu'ils ont produit : toutes les licences utilisées en pratique (la BSD, la MIT, toutes les Creative Commons autres que CC0, la GPL…) comprennent cette obligation. Je suis, pour ma part, convaincu que ne pas citer l'auteur original des productions que l'on réutilise ou que l'on redistribue, c'est essentiellement se conduire comme un malpropre de la pire espèce, et que ce type de comportement est antisocial et malhonnête. Néanmoins, je ne pense pas que ça soit pertinent de faire appel - ou même de considérer l'éventualité de faire appel - à la Grande Machine Étatique pour aller geindre « le méchant pas beau, là, il a réutilisé ce que j'ai écrit en prétendant que c'est lui qui l'avait écrit ». À l'ère d'Internet, si ça se produit, j'en entendrai parler un jour ou l'autre, et je pense que lui pourrir sa réputation en informant ses lecteurs (ou ses clients) de la malhonnêteté dont il fait preuve est un châtiment beaucoup plus logique que d'aller embêter des juges payés par le contribuable pour essayer de lui grapiller trois sous.

Par ailleurs, la question de la Postérité™ (et d'une façon générale, le concept de lier pour l'éternité son nom à son œuvre) est à des kilomètres de mes préoccupations ; j'aime l'idée de laisser une trace positive sur le reste du monde après ma mort (j'espère qu'elle sera constituée d'idées intéressantes, de concepts fertiles et d'apports positifs à mon entourage et à la société en général), mais je me fiche complètement qu'elle soit reliée à mon nom et à l'individu que j'incarne. Si je signe de mon nom ce que je publie, c'est que c'est beaucoup plus simple en pratique que d'essayer d'être anonyme, et puis que je serais ravi que ça puisse m'apporter des choses chouettes en pratique (que des gens trouvent intéressant ce que j'écris et viennent en discuter avec moi, que des gens me remercient pour un article, que mes pauvres réflexions soient moins banales que ce j'imagine et m'ouvrent des opportunités quelconques, que sais-je encore). En fait, en y réfléchissant, même en mettant tout ce qu'on raconte dans le domaine public, on continue à se conduire de façon égoïste rien qu'en ayant l'orgueil d'apposer sa signature sur sa production =)

Bon, j'ai écrit un pavé beaucoup trop gros sur ce sujet, et j'ai probablement perdu la moitié de mes lecteurs en route, un peu comme quand j'envoie des mails pour donner des nouvelles à ma famille. En même temps, c'est un défaut dont je ne pense pas pouvoir me débarrasser facilement, donc autant que mes éventuels lecteurs commencent tout de suite à s'y habituer.