Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.


Google inverse les noms de domaines

Première rédaction de cet article le 16 janvier 2020
Dernière mise à jour le 20 janvier 2020


Le 16 janvier au matin, il y avait une bogue amusante (qui a duré quelques jours) dans le moteur de recherche Google. Les noms de domaine étaient dans certains cas inversés, plus exactement mélangés dans l'affichage.

Quand on cherche quelque chose dans ce moteur de recherche (sur une machine de bureau, car c'est différent sur les mobiles), Google affiche pour chaque résultat :

  • L'endroit où a été trouvé le résultat, sous une forme vaguement inspirée des breadcrumbs (Google affichait autrefois un URL, ce qui était plus intelligent mais a sans doute été changé sur demande du marketing car « M. Michu ne comprend rien aux URL » et Google n'aime pas éduquer les utilisateurs),
  • Le titre de la page, qui est un lien hypertexte (en promenant son pointeur dessus, on voit l'URL s'afficher en bas à gauche, ce qui est utile pour savoir où on va avant d'y foncer),
  • La date et un résumé.

On voit ici un exemple : google-recherche-echos.png

L'endroit de la page est fabriqué à partir de l'URL mais n'est pas un URL. Il commence par un nom de domaine et se continue par un chemin dans le site. Mais ce qui est amusant est que cet affichage est bogué. Dans certains cas, le nom de domaine est mélangé. L'exemple précédent est correct mais, si je cherche le département de physique de l'Université de Cambridge : google-recherche-cavendish.png

Le vrai nom de domaine est www.phy.cam.ac.uk mais Google affiche phy.www.cam.ac.uk. Autre exemple, avec le gouverneur de Californie : google-recherche-gouverneur.png

Ici, le vrai nom était www.gov.ca.gov mais Google affiche gov.www.ca.gov. L'URL vers lequel pointe le résultat est néanmoins correct, comme on le voit avec cet autre exemple (Firefox affiche l'URL de destination en bas à gauche) : google-recherche-escargot.png

Pourquoi cette bogue ? La raison fondamentale est sans doute une incompréhension des noms de domaine, notamment du fait que le nombre de composants d'un nom soit quelconque (contrairement à une légende répandue.) Vous noterez que les seuls noms ainsi massacrés sont des noms ayant plus de trois composants. Mais c'est curieux de la part de Google, dont les services ont d'habitude très peu de bogues.

Mais on peut aussi voir dans cette bogue le résultat d'une mentalité très fréquente dans le Web, et particulièrement chez Google, comme quoi les noms de domaine ne sont pas une information pertinente et peuvent être cachés, ou massacrés, sans problème.

Merci à Jean-Philippe Pick pour avoir noté le phénomène. Le problème a été réparé le 19 novembre, sans nouvelles de Google ou sans information publiée.


L'article seul

Fiche de lecture : Unix: A history and a Memoir

Auteur(s) du livre : Brian Kernighan
Éditeur : Kindle Direct Publishing
9781695978553
Publié en 2020
Première rédaction de cet article le 14 janvier 2020


Ce livre est une histoire du système d'exploitation Unix, par une des personnes qui ont suivi l'aventure d'Unix depuis le début, Brian Kernighan.

D'abord, Kernighan écrit très bien, il a un vrai talent pour tout expliquer, y compris les questions informatiques complexes (comme le fameux tube, une des inventions les plus marquantes dans Unix). Ensuite, il a lui-même travaillé au développement d'Unix (il a notamment participé à la création du langage C, dans lequel Unix a été rapidement réécrit, après ses débuts en langage d'assemblage.) Cela lui permet de faire revivre une époque aujourd'hui bien distante.

Il y a fort longtemps, dans un pays lointain, pas du tout dans la Silicon Valley mais à Murray Hill, un gentil roi, la compagnie AT&T avait installé son service de recherche et développement, les Bell Labs. Les Bell Labs (qui existent encore aujourd'hui sous ce nom mais ne sont plus que l'ombre de ce qu'ils étaient) sont devenus une légende de la physique, de la mathématique et de l'informatique, avec pas moins de neuf prix Nobel obtenus (non, l'invention d'Unix n'a pas été récompensée par un prix Nobel.)

C'est dans ce pays merveilleux que deux informaticiens, Ken Thompson et Dennis Ritchie, après le semi-échec du projet Multics, et le retrait des Bell Labs de ce travail, se sont attaqués à une de ces tâches où tous les gens raisonnables vous disent « c'est complèment irréaliste, jeune homme, vous n'êtes pas sérieux ». Ils ont écrit un système d'exploitation et Unix était né, prêt à conquérir le monde. Ce livre est l'histoire d'Unix. Elle est pleine de rebondissements, de crises, de discussions.

Pour rappeler l'importance d'Unix, il faut se souvenir que beaucoup de choses qui nous semblent aujourd'hui évidentes en informatique ne l'étaient pas à l'époque. Par exemple, la grande majorité des systèmes d'exploitation imposaient de fixer une taille maximale à un fichier avant sa création. Si elle était trop faible, on devait re-créer un autre fichier et copier les données. Si cette taille était trop élevée, on gaspillait de l'espace disque. Unix a mis fin à cela et, aujourd'hui, cela va de soi. De même Unix a unifié les différents types de fichiers. Avant Unix, plusieurs systèmes d'exploitation avaient des commandes différentes pour copier un fichier contenant un programme Cobol et un fichier de données !

L'atmosphère très spéciale des Bell Labs, informelle, avec peu de bureaucratie, un accent mis sur les compétences et pas sur les titres (une méritocratie, une vraie) a beaucoup aidé à développer un système d'exploitation à succès. Kernighan raconte beaucoup d'histoires amusantes, mais consacre également du temps à l'analyse des facteurs importants dans le succès des Bell Labs. Il insiste sur les facteurs physiques (« geography is destiny ») : tout le monde sur le même site, et un mélange de bureaux fermés (même les stagiaires avaient leur propre bureau fermé, loin de l'open space bruyant empêchant la concentration) et de pièces communes où on pouvait aller quand on voulait, discuter et interagir avec les autres. Les Bell Labs ont été un cas peut-être unique, où toutes les conditions étaient réunies au même endroit, pour produire une étonnante quantité d'inventions géniales. Le tout était aidé par un financement stable et un management qui laissait les chercheurs tranquilles. Il est curieux (et triste) de noter qu'une entreprise 100 % capitaliste comme AT&T donnait plus de liberté et de stabilité financière à ses chercheurs qu'une université publique d'aujourd'hui, où les chercheurs doivent passer tout leur temps en travail administratif, en évaluation, et en recherche d'argent.

Aux Bell Labs, il était fréquent pour un chercheur de travailler sur plusieurs sujets de front et le livre de Kernighan donne une petite idée de la variété des sujets. Anecdote personnelle : j'ai utilisé (très peu !) le système Ratfor que l'auteur avait écrit, quand je faisais du calcul numérique.

Une particularité d'Unix est en effet la profusion d'outils pour informaticiens qui ont été développés sur ce système. L'auteur consacre de nombreuses pages à ces outils en insistant sur le fait que le goupe Unix des Bell Labs maîtrisait toujours la théorie et la pratique. Chaque membre du groupe pouvait écrire une thèse en informatique théorique, et inventer puis programmer des outils utiles. Mais on oublie souvent que les premiers utilisateurs d'Unix n'étaient pas que des informaticiens. Le premier argument « de vente » d'Unix auprès de la direction des Bell Labs était ses capacités de… traitement de texte. Le service des brevets de Bell Labs déposait beaucoup de brevets, et leur préparation prenait un temps fou. En bons informaticiens, les auteurs d'Unix ont automatisé une grande partie des tâches, et les juristes se sont mis à préparer les demandes de brevets sur Unix…

De nos jours, on associe souvent Unix au logiciel libre, puisque Linux, FreeBSD et bien d'autres héritiers de l'Unix original sont libres. Mais à la grande époque des Bell Labs, ces considérations politiques étaient absentes. Kernighan n'en parle jamais et, au contraire, insiste sur le verrouillage de bien des innovations par des brevets. C'est en raison de la licence restrictive de l'Unix d'AT&T que des systèmes comme Linux ou FreeBSD n'ont plus une seule ligne du code original d'AT&T : il a fallu tout réécrire pour échapper aux avocats.

Kernighan ne fait pas que raconter des anecdotes édifiantes. Il corrige également quelques légendes. Par exemple, le fameux commentaire dans le code source d'Unix « You are not expected to understand this » ne veut pas du tout dire « lecteur, tu es stupide, laisse ce code aux pros » mais « il n'est pas nécessaire de comprendre ce bout de code pour comprendre le reste ».

Vous ne serez pas surpris d'apprendre que le livre a été composé sur Unix, avec groff et Ghostscript.


L'article seul

Rapport de la députée Forteza sur les technologies quantiques

Première rédaction de cet article le 12 janvier 2020


Le 9 janvier 2020, la députée Paula Forteza a rendu le rapport « Quantique : le virage technologique que la France ne ratera pas ». Quelques points sur ce rapport.

Le terme de « quantique » a un fort potentiel de hype pour les années à venir (surtout depuis l'annonce par Google de l'obtention de la suprématie quantique). Dans le contexte de la physique, il désigne quelque chose de clair (mais pas forcément de simple à comprendre !) Appliqué aux technologies, c'est plus compliqué. Et ce rapport couvre toutes les utilisations futures de la quantique, ce qui fait beaucoup. Globalement, le rapport est rigoureux sur la partie scientifique (il y a eu de bons conseillers, et ils ont été bien écoutés, donc des point délicats comme la différence entre qubits physiques et logiques, toujours oubliée par les marketeux, est bien décrite) mais plus contestable sur la partie politique. Je ne vais pas reprendre tous les points (lisez le rapport, vous ne vous ennuierez pas, et vous apprendrez des choses) mais seulement ceux qui me semblent particulièrement discutables.

Le point le plus curieux concerne la distribution quantique de clés (parfois appelée par abus de langage « cryptographique quantique »). La partie technique du rapport note à juste titre les nombreuses limitations (le rapport parle de « verrous ») de cette technique, que ses promoteurs présentent comme la solution magique à tous les problèmes de sécurité de l'Internet (ce qu'elle n'est pas). Mais la partie « propositions » du rapport oublie complètement ces limitations et assène qu'il faut mettre le paquet pour le développement de la QKD. On dirait vraiment que l'analyse de la technologie et les recommandations ont été écrites par des personnes différentes.

Le rapport est plus cohérent sur la question de la cryptographie post-quantique (cf. aussi mon exposé à pas Sage En Seine et le point de vue très différent de Renaud Lifchitz.) Encore que la partie résumée à l'attention des décideurs, comme souvent, présente le problème comme sans doute plus proche qu'il ne l'est (et propose de commencer à déployer les solutions en 2022 !) Le rapport semble pousser au déploiement immédiat d'algorithmes post-quantiques, alors qu'aucun n'est normalisé. (Et, puisqu'il s'agit d'un rapport officiel, on peut noter que le RGS, et notamment son annexe cryptographique, ne sont pas mentionnés.) Si vous voulez en savoir plus sur la cryptographie post-quantique, je vous recommande l'exposé de Magali Bardet lors de la JCSA de juillet 2019.

Ensuite, ce rapport reprend malheureusement le style de tant de rapports officiels précédents : pas d'autre proposition que de donner beaucoup d'argent à Atos ou Thales dans l'espoir que cela fera avancer les choses, meccano institutionnel (créer un comité machin), discours sur la grandeur de la France et sa maitrise de toutes les technologies et toutes les sciences, référence à la startup magique, croyance que la recherche fondamentale se pilote d'en haut (on annonce bien haut que la quantique est une priorité et paf, cela suffit à ce que les résultats arrivent), et surtout, aucune remise en cause des obstacles que rencontre actuellement la recherche. Par exemple, le rapport propose d'« encourager » (ça ne coûte rien…) les chercheurs à candidater à des programmes de financement européens mais sans se demander pourquoi il n'y a pas davantage de telles candidatures. (C'est en partie parce que les chercheurs passent déjà plus de temps dans la paperasserie et dans la chasse aux subventions que dans la recherche. Mais on ne pouvait pas attendre d'une députée du parti du gouvernement qu'elle critique l'organisation actuelle de la recherche.)

Le rapport propose de fournir un calculateur quantique accessible en ligne (pardon, le rapport dit « cloud », c'est plus poétique) pour faire du QCaaS (Quantum Computing as a Service). C'est déjà proposé par IBM et AliBaba. Cela ne veut pas dire qu'il soit inutile d'en créer d'autres, meilleurs et/ou différents mais cela ne montre pas une énorme ambition.

D'autre part, certaines propositions auraient mérité d'être développées, notamment sur les moyens à mettre en œuvre. Ainsi, la proposition de créer des enseignements d'algorithmique quantique dans vingt cycles d'enseignement supérieur est une très bonne idée mais pas un mot n'est dit sur le recrutement d'enseignants, alors que justement les compétences en ce domaine ne sont pas largement répandues.

Le rapport, je l'ai dit, est globalement rigoureux, mais dérape quand même parfois par exemple quand, à propos de programmation, il pointe l'importance de développer des langages de programmation adaptés, de haut niveau (ce qui est une très bonne idée) mais cite ensuite comme exemple Q#, qui est justement un langage de très bas niveau, où on manipule les portes logiques directement. Vous imaginez programmer un ordinateur classique ainsi ? Seule la syntaxe de Q# est « de haut niveau », les concepts manipulés ne le sont pas. Au passage, si vous êtes prorgrammeur ou programmeuse, le site de questions/réponses StackExchange a une déclinaison sur le calcul quantique.

Un point que j'ai apprécié, par contre, est l'insistance sur les « technologies habilitantes ». Il s'agit de toutes les techniques qui permettent de réaliser des dispositifs quantiques, notamment la cryogénie. C'est à juste titre que le rapport rappelle qu'un ordinateur quantique n'est pas seulement composé de qubits, c'est d'abord un gros réfrigérateur.

Sur la forme, je note l'abus de termes en anglais, qui n'aide pas à la compréhension.

Notez que l'IETF a un travail en cours sur la cryptographie post-quantique et un groupe de recherche sur les réseaux quantiques, qui a produit plusieurs documents intéressants (je vous recommande draft-irtf-qirg-principles, qui explique bien la quantique, avant d'expliquer ce que pourrait être un réseau quantique. Le RIPE-NCC a déjà organisé un hackathon sur ce sujet.)


L'article seul

Un système anti-censure qui évolue en autonomie : Geneva

Première rédaction de cet article le 10 janvier 2020


La lutte technique de la liberté d'expression contre la censure sur l'Internet n'est pas près de s'arrêter. Chaque fois que les censeurs conçoivent de nouvelles techniques, les défenseurs de la liberté mettent au point de meilleurs méthodes pour leur échapper, les censeurs améliorent alors leurs techniques, et ainsi de suite. La partie est donc difficile pour ceux et celles qui réalisent des dispositifs anti-censure, car il faut en permanence suivre et s'adapter. D'où l'idée d'un système qui évolue « tout seul ». Le génial Geneva utilise le concept des algorithmes génétiques, pour s'adapter à la censure et évoluer automatiquement en même temps qu'elle.

Geneva traite le cas des systèmes de censure Internet de type Homme du Côté. Dans ces systèmes (il en existe beaucoup d'autres ; les censeurs ont de l'imagination, et beaucoup plus d'argent et d'hommes que les défenseurs de la liberté), le censeur peut observer les paquets IP qui passent, et générer ses propres paquets, mais il ne peut pas modifier les paquets envoyés. (Dans les systèmes d'Homme du Milieu, par exemple le pare-feu d'une entreprise, l'attaquant peut modifier ou jeter les paquets, ces systèmes sont donc plus efficaces mais aussi plus coûteux, et parfois plus difficiles à intégrer dans l'infrastructure. Ils sont donc moins employés à l'échelle d'un pays, où le trafic est important. Mais rappelez-vous toujours que les censeurs utilisent plusieurs techniques, et souvent une combinaison de techniques, ajoutant par exemple les résolveurs DNS menteurs.) Un exemple d'attaque de l'Homme du Côté est un système qui observe le SNI dans les requêtes TLS (par exemple HTTPS) et, s'il voit un nom de domaine interdit (ou même simplement un mot censuré, par exemple Falun Gong en Chine), il génère un paquet TCP RST (ReSeT, RFC 793, section 3.1) vers l'émetteur ou le destinataire, coupant ainsi la connexion. TLS ne protège pas contre ces attaques, puisque, contrairement à QUIC, TLS ne chiffre pas la couche Transport. (Rappelez-vous également que l'Homme du Côté voit tous les paquets, il a donc la partie bien plus facile que l'attaquant aveugle des RFC 5927 ou RFC 5961.)

Contre de telles techniques de censure, la solution habituelle (et de nombreuses ont été développées) est de semer la confusion chez l'Homme du Côté, en envoyant des paquets qui seront interprétés différemment par le censeur et par le vrai destinataire. Par exemple, on envoie un paquet TCP RST avec un TTL qui lui permet d'atteindre la machine du censeur mais pas celle du destinataire. Le censeur croira alors que la connexion est finie, alors qu'en fait elle continuera. (Le censeur, dans le cas d'un État, a des moyens importants mais pas illimités. Il a donc intérêt à libérer de la mémoire en « oubliant » les connexions terminées, ce qui fait que le reste de la communication est ignoré.) L'inconvénient de ces stratégies est qu'il faut recommencer souvent, puisque les techniques de censure évoluent. Chaque fois que la censure se perfectionne, des contournements existants deviennent inefficaces et on est à nouveau censuré jusqu'au développement (lent et laborieux) d'un nouveau contournement. La lutte contre la censure est donc un combat éternel entre l'épée et la cuirasse.

Que peuvent apporter les algorithmes génétiques ici ? Un algorithme génétique est un algorithme qui reprend les grands concepts de la sélection naturelle. On choisit un ensemble de fonctions, on leur donne des règles de mutation, une fonction d'évaluation du résultat (qui joue le rôle de la survie du plus apte) et on laisse ensuite le système évoluer. On peut ainsi explorer un espace de solutions très large en bien moins de temps.

Tout l'art du concepteur d'algorithmes génétiques est dans la liberté plus ou moins grande qu'il ou elle laisse aux mutations. Si on laisse les mutations se faire au hasard, l'écrasante majorité des stratégies produites seront non viables, et l'exploration de l'espace des solutions prendra des siècles. Mais si on contraint fortement les mutations possibles, l'algorithme n'ira jamais bien loin, il restera sur les sentiers battus et ne fera pas de découverte disruptive.

Geneva tourne sur la machine du client, celui ou celle qui veut accéder à des contenus censurés. Geneva définit les solutions contre les attaques de l'Homme du Côté en trois parties : un déclencheur (trigger) qui dit quand lancer la solution, des actions qui disent ce qu'on va faire (par exemple créer un nouveau paquet) et des arbres (action trees) qui coordonnent la succession des actions. Par exemple, la stratégie mentionnée plus haut (un paquet TCP RST avec un TTL conçu pour atteindre le censeur mais pas le destinataire) s'exprimerait, dans le DSL de Geneva :

[TCP:flags:A]-

duplicate(send,
          tamper(TCP:flags:R)(
              tamper(IP:TTL:replace:10)
                  (send)))

-| \/
  

Le terme [TCP:flags:A] est le déclencheur : quand on envoie le TCP ACK (accusé de réception), on duplique ce paquet et on envoie à la fois le vrai et une copie ayant le bit R (RST) et un TTL diminué, pour n'atteindre que le censeur et lui faire croire que la connexion est finie. Un autre exemple corrompt délibérément la somme de contrôle TCP : certains censeurs ignorent cette somme de contrôle, ce qui permet d'envoyer un paquet (par exemple RST) qui ne sera lu que par l'Homme du Côté.

Geneva commence avec un ensemble de solutions faites à la main, les individus sur lesquels va s'exercer l'évolution. Ensuite, les mutations se produisent, portant sur les déclencheurs, sur les actions, et sur les arbres (la succession des actions). Geneva teste ensuite les résultats des mutations en cherchant à se connecter à un site Web censuré. Le critère de sélection est donc la réussite dans le contournement de la censure. (Les règles exactes sont plus complexes, car il faut éviter de se laisser pièger dans des minima locaux ; ce n'est pas parce qu'une solution marche qu'elle est la meilleure. Et puis certains systèmes de censure ne sont pas déterministes ; soit suite à une bogue, soit délibérement pour compliquer l'analyse, ils ne bloquent pas toujours.)

Geneva a été mis en œuvre en Python, utilisant évidemment Scapy, et le NFqueue de Netfilter sur Linux pour accéder au réseau. Notons que certaines opérations nécessitent d'être root (modifier les en-têtes IP) mais pas toutes (changer le découpage des données en segments TCP), ce qui permet dans certains cas de faire tourner Geneva, ou du moins le script (la stratégie) sélectionné, sans être root. Le code pour exécuter les scripts (mais pas encore celui avec l'algorithme génétique) est disponible en ligne.

Quels sont les résultats ? Eh bien, Geneva fonctionne, et même très bien d'après ses auteurs. En seulement quelques heures, il trouve une stratégie de contournement de la censure. Geneva a été testé dans le laboratoire, face à des solutions de censure connues, mais aussi en vrai sur le terrain, en Chine face au GFW, en Inde et au Kazakhstan. Disons-le tout de suite, en matière de censure, le GFW est le seul système intéressant, les autres sont vraiment primitifs. Geneva n'a eu aucun problème à trouver une stratégie pour échapper aux censures indienne et kazakhstanaise (simplement mettre le SNI dans deux segments TCP différents suffit, au Kazakhstan) mais le GFW lui a donné plus de fil à retordre. Le script :

[TCP:flags:PA]-fragment{tcp:8:True}(send,send)-|
[TCP:flags:A]-tamper{TCP:seq:corrupt}(send)-| \/
  

a réussi à passer. J'ai également bien aimé la stratégie FRAPUN (ainsi nommée en raison des bits de l'en-tête TCP qu'elle met à 1.)

Un des avantages des algorithmes génétiques est qu'ils peuvent trouver des solutions auxquelles leurs auteurs n'ont pas pensé (mais qu'ils peuvent expliquer a posteriori). Plus drôle, Geneva a aussi trouvé une solution que les auteurs du programme n'ont pas pu expliquer, mais qui marche face au GFW :

[TCP:flags:PA]-
fragment{tcp:8:True}(send,
fragment{tcp:4:True}(send, send))-| \/

Ce très bon article se termine par une discussion sur l'avenir de la lutte anti-censure. Geneva ne va évidemment pas mettre un point final à la question, il est certain que les censeurs s'y adapteront (c'est un problème classique en sécurité informatique : les logiciels distribués publiquement peuvent être utilisés par les bons comme par les méchants.)

J'ai aussi apprécié que l'article n'utilise pas de buzzwords comme IA ou machine learning. Aujourd'hui, où les chercheurs doivent passer davantage de temps à chercher des subventions et de l'impact médiatique (l'un n'allant pas sans l'autre) plutôt qu'à chercher, c'est appréciable. Mais, hélas, le dépôt git du projet, lui, le fait.

Notez que l'article mentionne des considérations éthiques. Lancer Geneva sur une machine en Chine peut vous attirer des ennuis. (L'Inde est moins dangereuse, de ce point de vue.) Certes, Geneva n'est pas trop bavard en octets mais son comportement si particulier pourrait être remarqué par les systèmes de surveillance que déploient la plupart des pays. C'est un problème fréquent quand on étudie la censure. Il faut donc bien prévenir les utilisateurs (ce que rappelle bien la section Disclaimer dans la documentation d'installation du logiciel.)


L'article seul

Historique dans RDAP

Première rédaction de cet article le 9 janvier 2020


Le protocole RDAP permet d'obtenir des informations sur une ressource enregistrée dans un registre, par exemple un RIR. Une extension permet d'avoir accès à l'histoire d'une ressource.

RDAP est normalisé dans les RFC 7480, RFC 7481 et RFC 7482. L'extension n'a jamais été normalisée, mais elle est déployée à l'APNIC. Voici un exemple d'utilisation, pour avoir l'histoire de l'adresse IP 2001:dc0:2001:11::194 :

% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194
...
  

Bon, d'accord, le résultat est confus. C'est du JSON donc on utilise jq pour le formatter plus joliment :

% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194 | jq .
...
      "applicableFrom": "2019-02-14T05:37:22Z",
      "applicableUntil": "2019-07-29T03:31:05Z",
      "content": {
        "country": "AU",
        "name": "APNIC-AP-V6-BNE",
        "type": "ASSIGNED PORTABLE",
        "startAddress": "2001:dc0:2000::",
        "ipVersion": "v6",
        "endAddress": "2001:dc0:3fff:ffff:ffff:ffff:ffff:ffff",
        "objectClassName": "ip network",
        "handle": "2001:0DC0:2000::/35",
...
  

On récupère un tableau d'enregistrements, chaque enregistrement étant valable de applicableFrom à applicableUntil. Pour voir combien de changements a vu ce préfixe IP, on va utiliser les fonctions de sélection de jq :

% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194 | \
    jq ".records|.[].applicableFrom"
...
  

Ça fait 48 changements, comme on pourrait le compter avec jq :

% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194 | \
    jq "[ .records|.[].applicableFrom ] | length"
49
  

Il avait été prévu à un moment de normaliser cette extension RDAP à l'IETF (Internet-Draft draft-ellacott-historical-rdap). Mais ça n'a pas suscité suffisamment d'intérêt. D'ailleurs, l'extension n'est même pas dans le registre des extensions RDAP. Une telle extension serait pratique pour l'investigation, mais pose aussi des problèmes de vie privée (plus de droit à l'oubli).


L'article seul

50 ans

Première rédaction de cet article le 1 janvier 2020


Non, ce n'est pas mon âge. Mais, aujourd'hui, l'« epoch » d'Unix et de l'Internet a cinquante ans.

J'ai toujours été fasciné par les calendriers. C'est un intérêt courant chez les informaticiens, d'autant plus que la quasi-totalité des logiciels qui manipulent des dates sont bogués, en partie en raison de la complexité du problème.

Tous les calendriers commencent par une date spéciale. Cela peut-être la naissance d'un prophète, le début de sa prédication, une insurrection, une proclamation, un serment, une grande bataille, ou un autre événement important, réel ou imaginé. Il y a avant et puis après. Ainsi, le calendrier légal en France, comme dans la plupart des pays du monde, est fondé sur la date de naissance (supposée…) de Jésus-Christ. Pour le laïciser un peu, on parle désormais d'« ère commune » et nous sommes donc le 1 janvier 2020 de l'ère commune (en anglais, CE, pour « common era ».)

Cette date spéciale se nomme en anglais « epoch » et nous allons parler ici d'une « epoch » intéressante, le premier janvier 1970.

Car le choix de la date spéciale est crucial. Elle sépare l'histoire en deux, avant, âge de ténèbres, d'ignorance et d'oppression, et après, âge du bonheur et de la lumière. D'où le choix d'événements grandioses pour distinguer l'avant et l'après.

Mais les ordinateurs ne sont pas romantiques. Ils se moquent des grands sentiments et des passions humaines, ils sont gérés par la pure rationalité. Quand on a besoin de définir une « epoch », pour les ordinateurs, il n'est pas nécessaire d'utiliser une date émouvante. Et, comme on a rarement besoin, sauf si l'ordinateur est utilisé par un historien, de manipuler dans un programme informatique des dates très anciennes, autant prendre une « epoch » récente. Le premier janvier 1970, certains lecteurs et lectrices de ce texte étaient déjà nés, ainsi que l'auteur de ces lignes (mais je n'avais pas encore mon bac).

C'est ainsi que le système d'exploitation (logiciel de base de la machine) le plus utilisé dans le monde, Unix, utilise comme « epoch », comme date spéciale, le 1 janvier 1970, il y a juste cinquante ans. Cette date a été choisie simplement parce qu'elle était, au moment du choix, située dans un passé récent et qu'elle était facile à mémoriser.

Unix compte tous les temps en secondes écoulées depuis le 1 janvier 1970 à 0h0mn, temps universel. Évidemment, ce n'est que la représentation interne, dans la mémoire du système. Les applications destinées aux utilisateurs affichent la date d'une manière plus habituelle. La très forte prévalence d'Unix dans l'Internet (la quasi-totalité des serveurs, et la grande majorité des clients) fait que cette epoch est également, de facto, celle de l'Internet, qui a commencé à peu près au même moment. (Jérôme Mainaud, merci à lui, me fait remarquer que le protocole de synchronisation d'horloges NTP, très répandu sur l'Internet, a une autre epoch, le 1 janvier 1900.)

Si vous êtes en ce moment sur une machine Unix dotée d'un « shell », d'un interpréteur de commandes, et que vous avez le programme « GNU date » (sur des systèmes comme Ubuntu ou Mint, c'est le programme date par défaut), vous pouvez afficher le nombre de secondes écoulées depuis l'« epoch » en tapant :

date +%s

Le premier janvier 2020, à 0h0mn en temps universel, il affiche 1 577 836 800.

Une lecture recommandée : « Calendrical calculations », d'Edward Reingold et Nachum Dershowitz (Cambridge University Press).

Merci à Hervé Le Crosnier (C&F Éditions) pour l'inspiration pour cet article.


L'article seul

Articles des différentes années : 2020  2019  2018  2017  2016  2015  2014  Précédentes années

Syndication : en HTTP non sécurisé, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu, en HTTPS, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.