Peu de temps après Y2K, nous avons fait des blagues sur  » next up, Y2038! »mais à l’époque, c’était une éternité dans le futur et probablement le problème de quelqu’un d’autre. Maintenant que nous sommes à mi-chemin, et que nous avons déjà atteint le point où les problèmes de Y2038 peuvent provoquer des pannes logicielles, c’est une bonne occasion de commencer à planifier pour Y2038. Par exemple, les logiciels peuvent déjà avoir des problèmes avec la durée de vie des certificats de 20 ans ou les prêts hypothécaires de 20 ans, et la fréquence de ces problèmes ne fera qu’augmenter à mesure que nous nous rapprocherons de l’année 2038. Chez Akamai, nous procédons déjà à une planification et à des tests internes ciblés de manière stratégique pour l’année 2038, et il semble probable que la portée de ce travail continuera de s’étendre au cours des 19 prochaines années, à mesure que cet effort important augmentera d’urgence.

Très peu de choses ont mal tourné le 1er janvier 2000 pour nous (à court de Javascript sur un site marketing Akamai affichant « 19100 » comme date actuelle !), mais une chose qui manque est que l’impact mondial limité ce soir-là était dû à deux facteurs: 1) la quantité de préparation avancée qui a été effectuée; 2) de nombreux « problèmes Y2K » se sont effectivement produits des années à l’avance plutôt que pendant le renversement lui-même. Les secondes intercalaires sont à certains égards plus effrayantes que les problèmes de format de date en ce sens qu’elles sont plus difficiles à tester et que l’impact se produit beaucoup moins à l’avance. Il y a un risque que l’absence d’impacts de l’année 2038 amène les organisations et les technologues à se préparer sous-pour l’année 2038. Il est également plus difficile d’expliquer « Y2038 » aux profanes que Y2K, ce qui rend potentiellement plus difficile la priorité et la concentration du travail avancé. Le grand nombre de dispositifs intégrés de l’Internet des objets (IoT) devenant omniprésents dans notre environnement rend également le risque probable et l’impact potentiel considérablement plus élevés pour Y2038 que pour Y2K.

Notre première expérience avec la planification de l’année 2038 (en plus de voir un choc de la part des gens en entendant des préoccupations soulevées au début dans 19 ans) est qu’une approche progressive et ciblée est nécessaire à ce stade. Des programmes beaucoup plus impliqués et complets seront certainement nécessaires pendant un certain nombre d’années. Dans cette phase initiale, certains domaines sur lesquels se concentrer incluent: 1) les logiciels traitant des heures et des dates futures; 2) les formats de messages et de fichiers sur le fil; 3) appareils à longue durée de vie déployée et leurs dépendances. Bien sûr, à mesure que nous nous rapprocherons, il deviendra essentiel de commencer à se concentrer sur des ensembles plus larges de systèmes, notamment en veillant à ce qu’ils puissent traverser la transition de l’an 2038 en toute sécurité.

Logiciel traitant des dates futures

Le domaine sur lequel il faut se concentrer au départ est peut-être le logiciel traitant des dates futures, par exemple pour la gestion des certificats X.509 ou pour la planification financière. Il existe de nombreuses représentations de format de date et d’heure, qui n’auront pas toutes un problème Y2038. Par exemple, les logiciels ayant besoin de gérer les temps des siècles passés (bien avant 1970) choisissaient souvent des représentations de date et d’heure différentes. Cependant, en testant les cas de certificats X.509 (tels que utilisés pour HTTPS) et les autorités de certification (CAS), nous avons trouvé de nombreux problèmes logiciels en laboratoire qui commencent à survenir avec les certificats et les CAS expirant après Y2038.

OpenSSL en particulier a plusieurs formats de temps, ASN1_UTCTIME ayant une limite dans Y2049 (un problème distinct à planifier à partir de Y2038), utilisez donc les fonctions ASN1_TIME pour assurer la compatibilité avec toutes les plages de temps. La conversion des délais d’expiration d’une bibliothèque telle qu’OpenSSL en time_t 32 bits est un domaine supplémentaire susceptible d’avoir des problèmes.

Dans beaucoup de ces cas, il a été possible de résoudre les problèmes simplement en portant et en compilant des logiciels hérités pour des architectures 64 bits (par exemple, pour passer d’un entier time_t de 32 bits à un time_t de 64 bits). Dans d’autres cas, des modifications plus étendues ont été nécessaires, en particulier lorsque les temps sont convertis en entiers pour les mathématiques ou lorsque les formats de fil de message sont impliqués ou lorsque les valeurs sont stockées dans des bases de données. Lors des tests et de la fixation de la prise en charge des CAS sur 20 ans, une chose qui s’est avérée est que les dépendances en aval entrent également en jeu. Par exemple, si une date de 20 ans dans le futur est introduite dans un système de journalisation ou un système de surveillance, et si ceux-ci alimentent à leur tour des systèmes d’alerte, des bases de données de rapports ou des systèmes de provisionnement, ceux-ci peuvent également nécessiter des correctifs.

Formats de messages et de fichiers sur le fil

Comme mentionné ci-dessus, lorsque des horodatages 32 bits sont placés dans des messages, des bases de données ou des formats de fichiers, l’impact peut s’étendre bien au-delà d’un système spécifique. Ce sont également des systèmes avec des dépendances externes où une planification plus avancée est souvent nécessaire car les interactions traversent les frontières du système. Pour ces collections de systèmes d’interopérabilité, les modifications peuvent devoir être publiées dans un ordre spécifique et la rétrocompatibilité entre souvent en jeu. De plus, s’il existe des protocoles normalisés de manière formelle ou informelle qui utilisent des valeurs d’horodatage d’époque 32 bits dans les messages, toute migration ou correction pourrait être fondée sur la correction de la norme. En tant que tels, ceux-ci deviennent importants à craindre comme avec une chaîne de dépendances telle que:

1. Mettre à jour le protocole /les normes pour prendre en charge les horodatages post-Y2038.
2. Implémentez la prise en charge de la norme mise à jour dans les bibliothèques logicielles.
3. Obtenez une nouvelle version des bibliothèques incorporées dans les progiciels.
4. Obtenez des progiciels inclus dans le nouveau produit d’expédition.

Ensuite, si chacun de ces délais prend quelques années et que le produit d’expédition a une longue durée de vie, les longs délais de livraison peuvent déjà poser problème.

Les appareils à longue durée de vie déployée et leurs dépendances

Un autre domaine sur lequel il faut commencer à se concentrer tôt est celui des appareils à longue durée de vie de déploiement. Comme nous venons de le mentionner, il est également important de suivre les dépendances externes de ces périphériques. Les appareils embarqués livrés avec du matériel 32 bits peuvent également ne pas avoir une solution facile de « compiler simplement pour un time_t 64 bits » via une mise à jour logicielle, ou cela pourrait avoir un impact inacceptable sur les performances.

Les automobiles connectées et autres appareils IoT sont probablement un sujet de préoccupation spécifique, mais je suis sûr qu’il existe de nombreux autres types d’appareils et d’applications similaires. Par exemple, compte tenu des tendances actuelles, il est probable que plus de 10% des voitures vendues aujourd’hui fonctionneront encore en 2038, et avec l’augmentation de l’âge des véhicules et du nombre de véhicules sur la route, cela pourrait être encore plus élevé. S’il faut quelques années pour que les automobiles d’expédition soient généralement conformes à la norme Y2038, avec la distribution actuelle (et croissante) des âges des véhicules à moteur, nous pourrions nous retrouver avec une fraction importante d’automobiles susceptibles d’avoir de graves problèmes dans dix-neuf ans. Ce même modèle existe probablement dans d’autres industries, comme dans l’électronique grand public (comme les consoles de jeux à domicile et les téléviseurs intelligents), où les appareils peuvent être livrés avec des certificats CA de plus de 20 ans préinstallés.

Les appareils ayant une longue durée de vie déployée peuvent nécessiter des tests plus complets à la fois de l’appareil et de ses dépendances, tels que des tests pour que le système d’exploitation et le logiciel continuent de fonctionner correctement avant, pendant et après le point de transition Y2038.

Bonne Année!

Le problème Y2038 est dans une catégorie similaire à IPv6: il s’agit d’un déploiement sur plusieurs décennies qui, dans le cas général, est important mais pas encore Urgent (selon la matrice d’Eisenhower). De ce point de vue, c’est le moment idéal pour commencer à planifier, à trier et à tester avant qu’il ne devienne urgent (ou trop tard). Concentrez-vous d’abord sur les logiciels traitant des dates futures, des formats de messages et de fichiers sur le fil et des appareils à longue durée de vie déployée. Ensuite, utilisez l’expérience de l’objectif initial pour élaborer un programme plus complet au cours des prochaines années. Quoi qu’il en soit, définissez une barre minimale et commencez à vous assurer que les nouveaux logiciels, systèmes, protocoles et produits que vous construisez et déployez n’introduisent pas de problèmes Y2038 et signalent les problèmes lorsque vous voyez des horodatages 32 bits depuis l’époque unix inclus dans les nouvelles conceptions.

Erik Nygren est Fellow et Architecte en chef de l’organisation d’ingénierie des plateformes d’Akamai. Il fêtera ses 20 ans à Akamai en juin prochain.

Merci à plusieurs personnes d’Akamai pour leurs contributions à cet article.

Bien que des précautions aient été prises lors de la préparation de ce document, Akamai Technologies, Inc. n’assume aucune responsabilité pour les erreurs, omissions ou dommages résultant de l’utilisation des informations contenues dans les présentes. Les informations contenues dans le présent document peuvent être modifiées sans préavis. Akamai et le logo Akamai wave sont des marques déposées ou des marques de service aux États-Unis (Reg. Pat AMÉRICAIN. &Tm. Hors). Publié le 10 janvier 2019.