Posté par Psychofox (Mastodon) .
Évalué à 9.
Dernière modification le 03 janvier 2022 à 16:35.
En fait non ce n'est pas la date qu'ils stockent, mais le numéro de version des updates. Et d'après ce que j'ai compris le numéro de version des updates n'a pas toujours été basé sur la date, raison pour laquelle ce choix de int32 n'a pas été vu comme un problème quand le code a été écrit.
Exchange doit encore comporter du très vieux code donc je ne suis pas choqué de voir que ce genre de bug existe. Sans connaissance que la date pourrait être encodée dans le numéro de version, le dev responsable de ce code n'avait probablement pas idée qu'un numéro de version puisse dépasser 2147483647 durant l'existence de Exchange. À un rythme d'1 update par jour il faut plus de 5 millions d'années pour passer de 1 à 2147483647!
Alors on pourrait mettre le blâme sur les gens qui ont décidé de changer de convention de nom car ce bug aurait probablement pu être détecté par des tests. Mais bon sans être fan de Microsoft, je ne leur jetterait pas tant la pierre. Ce genre de bug tu peux en trouver à peu près partout.
Il y a quelqu'un quelque par qui s'est dit qu'encoder YYmmddHHMM dans un entier c'était pas si mal ou quelqu'un qui s'est dit que cette chaîne de caractères ne contenait que des nombre donc pourquoi pas en faire un entier. C'est là qu'est le problème.
Tout le monde écrit des bugs, c'est juste intéressant de regarder où est arrivé le problème pour ne pas le reproduire.
Non justement, personne ne s'est dit ça. Le dev a utilisé un int32 pour le numéro de version, ce qui est raisonnable (même si uint serait a priori plus adapté).
Un gars du marketing (ou d'ailleurs) s'est dit qu'un numéro de version basé sur la date serait plus adapté qu'un bête numéro de version incrémenté à chaque release, ce qui n'est pas idiot. Ça permet d'avoir une idée de à quel point la version est vieille. Il n'avait probablement aucune idée du stockage en int32 quelque part (au niveau de la mise à jour c'est visiblement une chaîne de caractères).
Donc personne ne s'est dit YYMMDDhhmm -> int32.
Après, on peut se demander l'intérêt d'avoir heures et minutes dedans, avoir 2 chiffres pour différencier jusqu'à 100 mises à jour le même jour est largement suffisant.
On peut aussi se demander quel niveau de validation est effectué sur les mises à jour avant qu'elles soient distribuées.
Et on peut surtout se demander pourquoi des gens utilisent Exchange…
Il semble qu'ils s'en servent effectivement comme date. Logiquement le fait de lire un entier, le serialiser en string décimal puis de le parser en date pourrait mettre la puce à l'oreille :)
Après, on peut se demander l'intérêt d'avoir heures et minutes dedans, avoir 2 chiffres pour différencier jusqu'à 100 mises à jour le même jour est largement suffisant.
De ce que je comprends, c'est une vérification au démarrage, donc ils n'ont même pas exécuté quelque part le binaire distribuer ?
Après, on peut se demander l'intérêt d'avoir heures et minutes dedans, avoir 2 chiffres pour différencier jusqu'à 100 mises à jour le même jour est largement suffisant.
Mais ne permet pas d'être autonome : tu dois garder à un endroit le numéro de build, et j'imagine que l'idée était de ne pas s'emmerder avec ça (peu de risque que 2 builds soient faites à la même heure/minute, donc pas de stockage de ce qui a été compilé avant).
je ne dis pas que c'est bien ou mal, juste l'idée (sans doute).
# Bug de l'an 2022
Posté par NicolasP . Évalué à 10. Dernière modification le 02 janvier 2022 à 02:20.
Exchange OnPremise stocke en interne des dates au format YY / MM /DD HH:MM dans un int signé.
La première date en 2022 est 2 201 010 000 (22 01 01 00 00). Petit problème, c'est au delà de la valeur maximum d'un entier signé …
[^] # Re: Bug de l'an 2022
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 8.
Discuté sur "/." https://it.slashdot.org/story/22/01/01/2333225/year-2022-bug-breaks-email-delivery-for-microsoft-exchange-on-premise-servers
Et sur "r/sysadmin" https://www.reddit.com/r/sysadmin/comments/rt91z6/exchange_2019_antimalware_bad_update/
Mais comme disait un autre touite, pourquoi faire simple quand on peut faire compliqué et bogué ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Bug de l'an 2022
Posté par Psychofox (Mastodon) . Évalué à 9. Dernière modification le 03 janvier 2022 à 16:35.
En fait non ce n'est pas la date qu'ils stockent, mais le numéro de version des updates. Et d'après ce que j'ai compris le numéro de version des updates n'a pas toujours été basé sur la date, raison pour laquelle ce choix de int32 n'a pas été vu comme un problème quand le code a été écrit.
Exchange doit encore comporter du très vieux code donc je ne suis pas choqué de voir que ce genre de bug existe. Sans connaissance que la date pourrait être encodée dans le numéro de version, le dev responsable de ce code n'avait probablement pas idée qu'un numéro de version puisse dépasser 2147483647 durant l'existence de Exchange. À un rythme d'1 update par jour il faut plus de 5 millions d'années pour passer de 1 à 2147483647!
Alors on pourrait mettre le blâme sur les gens qui ont décidé de changer de convention de nom car ce bug aurait probablement pu être détecté par des tests. Mais bon sans être fan de Microsoft, je ne leur jetterait pas tant la pierre. Ce genre de bug tu peux en trouver à peu près partout.
[^] # Re: Bug de l'an 2022
Posté par barmic 🦦 . Évalué à 8.
Il y a quelqu'un quelque par qui s'est dit qu'encoder YYmmddHHMM dans un entier c'était pas si mal ou quelqu'un qui s'est dit que cette chaîne de caractères ne contenait que des nombre donc pourquoi pas en faire un entier. C'est là qu'est le problème.
Tout le monde écrit des bugs, c'est juste intéressant de regarder où est arrivé le problème pour ne pas le reproduire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bug de l'an 2022
Posté par cg . Évalué à 1.
J'avoue, j'avais fait le même genre de chose pour les serial de zones DNS, très mauvaise idée.
[^] # Re: Bug de l'an 2022
Posté par Colin Pitrat (site web personnel) . Évalué à 6. Dernière modification le 06 janvier 2022 à 12:05.
Non justement, personne ne s'est dit ça. Le dev a utilisé un int32 pour le numéro de version, ce qui est raisonnable (même si uint serait a priori plus adapté).
Un gars du marketing (ou d'ailleurs) s'est dit qu'un numéro de version basé sur la date serait plus adapté qu'un bête numéro de version incrémenté à chaque release, ce qui n'est pas idiot. Ça permet d'avoir une idée de à quel point la version est vieille. Il n'avait probablement aucune idée du stockage en int32 quelque part (au niveau de la mise à jour c'est visiblement une chaîne de caractères).
Donc personne ne s'est dit YYMMDDhhmm -> int32.
Après, on peut se demander l'intérêt d'avoir heures et minutes dedans, avoir 2 chiffres pour différencier jusqu'à 100 mises à jour le même jour est largement suffisant.
On peut aussi se demander quel niveau de validation est effectué sur les mises à jour avant qu'elles soient distribuées.
Et on peut surtout se demander pourquoi des gens utilisent Exchange…
[^] # Re: Bug de l'an 2022
Posté par barmic 🦦 . Évalué à 4.
Il semble que si. Si je regarde là :
source : forum Microsoft
Il semble qu'ils s'en servent effectivement comme date. Logiquement le fait de lire un entier, le serialiser en string décimal puis de le parser en date pourrait mettre la puce à l'oreille :)
De ce que je comprends, c'est une vérification au démarrage, donc ils n'ont même pas exécuté quelque part le binaire distribuer ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Bug de l'an 2022
Posté par Zenitram (site web personnel) . Évalué à 4.
Mais ne permet pas d'être autonome : tu dois garder à un endroit le numéro de build, et j'imagine que l'idée était de ne pas s'emmerder avec ça (peu de risque que 2 builds soient faites à la même heure/minute, donc pas de stockage de ce qui a été compilé avant).
je ne dis pas que c'est bien ou mal, juste l'idée (sans doute).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.