Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Exchange 2022 Bug
Caveman
myCSharp.de - Member

Avatar #avatar-3854.jpg


Dabei seit:
Beiträge: 148

Themenstarter:

Exchange 2022 Bug

beantworten | zitieren | melden

Also das MS Exchange scheint ein einziger großer Bug zu sein. Was da alles hochkommt.
Das neueste: 2022-Bug
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1.908
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von T-Virus am .
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers
Papst
myCSharp.de - Experte



Dabei seit:
Beiträge: 413
Herkunft: Kassel

beantworten | zitieren | melden

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“.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.504

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1.908
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

@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
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers
Coder007
myCSharp.de - Member



Dabei seit:
Beiträge: 1.213

beantworten | zitieren | melden

Honda hat wohl ein ähnliches Problem:

Y2K22-Fehler

Das dürfte in nächster Zeit noch häufger auffallen.
private Nachricht | Beiträge des Benutzers