Bonjour Nal,
Une petite blague pour l'année 2022 qui ne t'a pas encore été compté (mouarf).
Il se trouve que certain développeurs ont stocké la date dans des entiers signés en 32bits sous la forme : YYMMDDhhmm. Vous l'avez ? Le plus grand entier stockable est 2147483647 et la date du 1er janvier 2022 est : 2201010000.
Paf, pastèque !
Le plus connu se trouve dans Exchange mais ce n'est pas le seul. Je te laisse faire le tour de la toile avec le doux nom du dit bug : y2k22.
Bonne journée.
# Le lien arstechnica
Posté par Jona . Évalué à 4.
https://arstechnica.com/information-technology/2022/01/exchange-server-bug-gets-a-fix-after-ruining-admins-new-years-plans/
[^] # Re: Le lien arstechnica
Posté par Jérôme FIX (site web personnel) . Évalué à 8.
… et ici sur LinuxFR : https://linuxfr.org/users/nicolasp-2/liens/une-structure-de-date-visionnaire
# Pas la date
Posté par Colin Pitrat (site web personnel) . Évalué à 5.
Ce n'est pas la date mais le numéro de version, qui à ce format basé sur la date. Le fix consiste à patcher le numéro de version de la mise à jour pour la faire commencer par 21.
Ce que je trouve fou c'est d'avoir publié une mise à jour pour le jour de l'an. Et visiblement pas beaucoup testée…
[^] # Re: Pas la date
Posté par Zenitram (site web personnel) . Évalué à 1.
Ben… le bug ayant été vu le jour de l'an, c'est assez normal…
Ils n'ont pas eu beaucoup de temps.
[^] # Re: Pas la date
Posté par gasche . Évalué à 4. Dernière modification le 06 janvier 2022 à 16:21.
Si je comprends bien, le bug est causé par une mise à jour qui a été faite le jour de l'an (avant que le bug soit découvert), et dont le numéro de version (22…) a révélé le bug.
Cela a entraîné ensuite une deuxième mise à jour corrective avec un numéro de version… plus petit, ne provoquant donc plus le bug. (C'est une rustine qui corrige le symptôme mais pas le problème, j'imagine pour se donner le temps de le corriger proprement avec moins de stress.)
[^] # Re: Pas la date
Posté par barmic 🦦 . Évalué à 9.
2112330001
Le 33 décembre 2021 leur gestion de la date a l'air nickel :p
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas la date
Posté par groumly . Évalué à 3.
Le seul mec dispo le 1er janvier était un dev php, faut pas (trop) lui en vouloir.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pas la date
Posté par barmic 🦦 . Évalué à 2.
D'autant que j'imagine que la version précédente n'était pas 2112312359
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas la date
Posté par barmic 🦦 . Évalué à 10.
De ce que je vois c'est une vérification qui est faite au démarrage du service. Je me demande s'ils ont même exécuté le binaire final ailleurs que chez leur client.
Ça relativise quand un ancien de chez Microsoft expliquent qu'ils ne sortent pas des patchs à l'arrache et font des tests significatifs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas la date
Posté par Psychofox (Mastodon) . Évalué à 4.
En l'occurence ce n'est pas un patch mais une base de définitions de malware. Donc je peux très bien imaginer un meeting avec un manager dire à un moment donné "on est toujours en retard face aux concurrents X, Y, on doit livrer les bases de définitions plus vite". Et un ingénieur de dire "on fait des tests pour chaque base de définitions mais depuis qu'on fait ces tests on n'a jamais vu une seul erreur et il n'y a aucune raison parce que ce n'est pas du code, on peut peut-être les supprimer pour livrer plus vite".
Et pouf on vire les tests.
La question après reste de l'impact:
- est-ce que l'image de marque de exchange a souffert au point qu'une seule entreprise va dire j'en ai marre, je migre sur autre chose ? Sachant que sortir d'exchange (comme sortir d'autres truc comme Lotus Notes ou Groupwise) ce n'est pas du tout facile et c'est le genre de gros projet que toute le monde préferrerait laisser à son successeur. Au pire ça a du donner l'envie à certains admins de migrer d'un exchange on-prem vers office365 pour ne pas avoir à bosser le 1er janvier et laisser Microsoft résoudre son problème tout seul.
- est-ce que ça a coûté cher aux clients? Il n'y a il me semble pas eu de perte de donnée puisque l'email est asynchrone et que la plupart des serveurs de mails essayent de renvoyer pendant 2 à 4 jours. En terme de disruption de flux de travail le 1er janvier pas grand monde bosse. Ça a du faire chier des admins qui étaient de piquets et des organisations qui bossent 24/24 (services hospitaliers, etc) mais ceux-ci n'utilisent pas en général l'email et les public folders pour des urgences donc ça n'a pas du être très dérangeant.
Donc passé le momen cocasse de se dire "ha ha ha une date en int32 les n00bs!" l'impact n'est pas si grand. Du coup doit-on dans ce cas rajouter ce test à chaque sortie de baseline ou simplement produire le patch, tester sur des numéros de versions prévues pour ces 30 prochaines années et ajouter un commentaire dans la doc interne que si on change ce code ou la nomemclature de version il faut retester?
[^] # Re: Pas la date
Posté par barmic 🦦 . Évalué à 5.
Ça dépend de la qualité que tu cherche à produire.
Vraiment. On écrit tous des bugs et personne ne peut dire que ça peut ne pas exister, mais la manière que tu as de gérer les bugs d'assurer qu'ils en arrivent moins va changer l'image de ce que tu produit. Pas la première fois, ni même la seconde fois, mais ça devient une culture d'entreprise et ça peut mal finir. Boeing s'est tapé en moins de 2 ans un gros problème sur son 737 MAX entre autre à cause du logiciel et la même pour un module qu'ils ont produit pour la NASA et où la NASA leur a dit qu'ils allaient eux-même revoir tout le code.
Et l'excuse consistant à se cacher derrière le marketing, le manager ou autre, ça va 3 minutes. Ils ne connaissent pas ton métier, c'est normal c'est pas le leur. Donc c'est à toi d'expliquer ce qui peut et ce qui ne peux pas se faire.
Je ne dis pas que MS applique le comportement que tu décrit. Je n'en sais strictement rien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas la date
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 06 janvier 2022 à 17:54.
D'après Microsoft c'est les 2.
source : forum Microsoft
De ce que je comprends ils encodent dans le numéro de version la date et s'en servent pour savoir s'il faut faire une mise à jour.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas la date
Posté par claudex . Évalué à 4.
Et si je comprends bien, ce n'est pas un patch du 1er janvier à l'origine du problème, c'est le fichier de signature généré automatiquement tous les jours qui ce numéro de version.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas la date
Posté par barmic 🦦 . Évalué à 2.
J'en doute, mais je n'arrive pas à en savoir vraiment plus (internet est spamé d'info peu pointue). Si on regarde la solution indiquée par MS, c'est vraiment la version qu'ils ont publiée qui a le problème. Ce que je comprends c'est qu'ils mettent à jour ensemble le moteur et un fichier signature qui va avec et que le moteur vérifie la signature (je ne sais pas s'il s'agit d'une signature cryptographique ou d'une liste de signatures qu'il tente de chercher dans les mails).
Si c'était un processus automatique qui produit ce fichier régulièrement en fonction de la date courante toutes les versions seraient impactées.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas la date
Posté par claudex . Évalué à 4.
Même si c'est ça, rien ne dit que le moteur a été mis à jour, ça peut être simplement le fichier de signature si les deux sont publiés ensemble.
Quelles version ne sont pas impactées ? D'après ton lien, ça parle de "Exchange Server 2016 and Exchange Server 2019", ça ne dit pas qu'il y a des exceptions.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas la date
Posté par barmic 🦦 . Évalué à 2.
Ils demandent de supprimer le moteur. Ils ont publié une nouvelle version de ce dernier sachant qu'ils ont des numéros de versions distincts.
Il n'y a qu'une seule version d'impacter. La première étape du fixe c'est de vérifier que tu as installé la version problématique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pas la date
Posté par claudex . Évalué à 5.
Ça ne donne pas un numéro de version précis problématique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas la date
Posté par barmic 🦦 . Évalué à 2.
Je comprends pas ce que tu veux dire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# pas grave
Posté par Funix (site web personnel, Mastodon) . Évalué à 6.
je me souviens au boulot on avait des systèmes qui passaient pas l'an 2000, pas grave on a remonté les horloges de 10 ans dans le temps et le tour était joué :-)
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: pas grave
Posté par Anthony Jaguenaud . Évalué à 4.
Du coup, tu as provoqué le bug de l’an 2010 ;-)
[^] # Re: pas grave
Posté par Funix (site web personnel, Mastodon) . Évalué à 3.
en fait non, on a eu le temps de faire évoluer les systèmes en question
https://www.funix.org mettez un manchot dans votre PC
# Pfff oh les cons... euh ça arrive
Posté par stopspam . Évalué à 10. Dernière modification le 06 janvier 2022 à 21:04.
(1) Oh les cons j'ai pensé en lisant mes flux RSS hier matin en tombant sur cette actu.
J'ai aussitôt envoyé un mail private joke à mon sysadmin qui m'a confirmé que : de la même manière que nous étions immunisés de log4shell grâce à notre politique de
non mise à joursécurité, ce bug de l'an 2022 ne concernait pas notre increvable Exchange 2007.Quelques minutes plus tard, serilog (dotnet #1) me remonte des erreurs de retour de paiement d'un de nos sites de vente : "arithmetic overflow" sur OrderId. Après analyse en db : ce numéro de facture est généré sous la forme "YYMMDDxxxxx" et stocké dans un int32…
(1) euh ça arrive à tout le monde #metoo
# Paf coup de vieux
Posté par beug . Évalué à 1.
22 ans.. P€ ¢ © ® 22 ans..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.