Exchange 2022 Bug

Also das MS Exchange scheint ein einziger großer Bug zu sein. Was da alles hochkommt.
Das neueste: 2022-Bug

Was mich daran mehr stört ist die Art des Fehler.
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.

https://twitter.com/jroosen/status/1477120097747677184

T-Virus

Ohne jetzt den Bug beschönigen zu wollen.
Zeitstempel sind mit eine der komplexeren Sachen, die man programmieren kann, gerade wenn man Hardwarenah oder mit einer älteren, evtl. portierten Codebasis unterwegs ist.
Aber einen Zeitstempel Dezimal in ein binäres System zu pressen ist schon „interessant“.

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? 🙂

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.

@Abt/Papst
Der Grund für solche Kodierungen ist mir durchaus klar.
Ich programmiere z.B. TCP/UDP Server zum entfangen von Daten von GPS Boxen.
Dort sind die Daten auch unterschiedlich kodiert und teilweise nicht sauber dokumentiert.

Dort haben wir dann auch mal Varianten ähnlich wie bei diesem Bug.
Bei einigen Boxen scheint es auch ein ähnliches Problem zu geben, hier erhalten wir plötzlich bei zweistelligen Datumsangaben anstelle von 21 dann wieder 00.
Entsprechend mussten wir auch schon Boxen updaten/austauschen da diese auch schon EoL sind.

Ansonsten scheint Microsoft auch schon schnell reagiert zu haben.
Ein Fix ist wohl auch schon da 🙂
Ist also nur ein unglücklicher Fall, der aber relativ fix behoben wurde.

Golem.de: IT-News für Profis

T-Virus

Honda hat wohl ein ähnliches Problem:

Y2K22-Fehler

Das dürfte in nächster Zeit noch häufger auffallen.