Es ist evtl. nicht soooo mega schlau den größten und am meisten verwendeten Mailserver der Erde als "einzigen Bug" zu bezeichnen - vor allem in diesem Fall.
Der Bug selbst betrifft ja nicht mal Exchange selbst... daher ist die Aussage halt auch massiv am Ziel vorbei. Artikel überhaupt ganz gelesen? :-)
| Zitat von T-Virus |
Dort wird Datum und Uhrzeit als signed int32 codiert.
Dies führte aber genau ab 2022 zu einem Überlauf, was sich zwar mit uint32 für einige Jahre beheben liese, aber auch dann nicht sinnvoll gelöst wäre.
Für solche Dinge sollte man immer einen entsprechenden Timestamp Datentyp verwenden.
|
Um solch eine Aussage zu tätigen, muss man wissen, woher der Ursprung des Bugs kommt.
Wie Papst schon sagte: Zeitstempel sind komplex und es gab von Haus aus in den Grundzügen der Programmierung keinen Datentypen von Zeiten - man hat das alles immer über Ganzzahlen abgedeckt; bestes Beispiel: Unix Timestamp.
Der Ursprung des Bugs kommt aus den ~80ern, aus dem C/C++ Bereich und aus der Welt der Mikro Optimierungen.
Die Art und Weise, wie in Exchange (bzw. nicht in Exchange selbst sondern in einer Zusatzkompotente vom Malware Scanning) ist extrem weit verbreitet in der C++ Welt.
Zu dieser Zeit gab es ganz einfach kein anderer Datentyp, und durch die extrem hohen Abhängigkeiten, ist das alles andere als trivial "mal kurz auf einen anderen Datentypen" zu gehen.
Dass der Y2K22 Bug kommen wird, war nichts unbekanntes - genauso wie dass das
Jahr-2038-Problem kommen wird.
Letzteres ist auch ein bekanntes, riesiges Problem, das auch in .NET viele Komponenten und zB Authentifizierungsstandards und die ganzen Betriebssysteme selbst noch treffen wird.
JwtSecurityTokenHandler token expiration date validation fails if date more than 25 years
Ich weiß auch, dass Industrie-Anlagen vom YK22 und YK38 Bug betroffen sind... das sind Dinger, die eine Laufzeit haben - da wird niemand während der Entwicklung dran denken.
