Kurz nach Y2K machten wir Witze über „als nächstes Y2038!“ aber damals fühlte es sich eine Ewigkeit in der Zukunft an und war wahrscheinlich das Problem eines anderen. Jetzt, da wir auf halbem Weg sind und bereits den Punkt erreicht haben, an dem Y2038-Probleme Softwarefehler verursachen können, ist dies eine gute Gelegenheit, mit der Planung für Y2038 zu beginnen. Beispielsweise hat Software möglicherweise bereits Probleme bei der Arbeit mit 20-jährigen Zertifikatslebensdauern oder 20-jährigen Hypotheken, und die Häufigkeit dieser Probleme wird nur zunehmen, wenn wir uns Y2038 nähern. Bei Akamai führen wir bereits strategisch ausgerichtete interne Planungen und Tests für Y2038 durch, und es ist wahrscheinlich, dass der Umfang dieser Arbeit in den nächsten 19 Jahren weiter zunehmen wird, da diese wichtigen Bemühungen immer dringlicher werden.

Am 1. Januar 2000 ging für uns sehr wenig schief (abgesehen von etwas Javascript auf einer Akamai-Marketing-Website, auf der „19100“ als aktuelles Datum angezeigt wird!), aber eine Sache, die übersehen wird, ist, dass die begrenzte globale Wirkung an diesem Abend auf zwei Faktoren zurückzuführen war: 1) die Menge an fortgeschrittener Vorbereitung, die durchgeführt wurde; 2) viele „Y2K-Probleme“ traten tatsächlich Jahre im Voraus auf und nicht während des Roll-Overs. Schaltsekunden sind in gewisser Weise beängstigender als Datumsformatprobleme, da sie schwieriger zu testen sind und viel weniger Auswirkungen im Voraus auftreten. Es besteht das Risiko, dass der Mangel an Auswirkungen von Y2K dazu führen kann, dass sich Organisationen und Technologen zu wenig auf Y2038 vorbereiten. Es ist auch schwieriger, Laien „Y2038“ zu erklären als Y2K, was es möglicherweise schwieriger macht, Prioritäten zu setzen und sich auf die Arbeit zu konzentrieren. Die große Anzahl eingebetteter IoT-Geräte (Internet of Things), die in unserer Umgebung allgegenwärtig werden, macht auch das wahrscheinliche Risiko und die potenziellen Auswirkungen für Y2038 erheblich höher als für Y2K.

Unsere ersten Erfahrungen mit der Y2038-Planung (abgesehen davon, dass die Leute schockiert waren, als sie Bedenken hörten, die zunächst 19 Jahre entfernt klangen) ist, dass in dieser Phase ein inkrementeller und fokussierter Ansatz erforderlich ist. Viel umfassendere und umfassendere Programme werden sicherlich einige Jahre später erforderlich sein. In dieser Anfangsphase sollten Sie sich auf folgende Bereiche konzentrieren: 1) Software, die sich mit zukünftigen Zeiten und Daten befasst; 2) On-the-Wire-Nachrichten- und Dateiformate; 3) geräte mit langer Lebensdauer und deren Abhängigkeiten. Je näher wir uns nähern, desto wichtiger wird es natürlich, sich auf breitere Systeme zu konzentrieren, einschließlich der Gewährleistung, dass sie den Übergang von Y2038 sicher bewältigen können.

Software, die sich mit zukünftigen Daten befasst

Der vielleicht wichtigste Bereich, auf den Sie sich zunächst konzentrieren sollten, ist Software, die sich mit Daten in der Zukunft befasst, z. B. für den Umgang mit X.509-Zertifikaten oder für die Finanzplanung. Es gibt viele Datums- und Zeitformatdarstellungen, von denen nicht alle ein Y2038-Problem haben. Beispielsweise verwendete Software, die sich mit Zeiten vergangener Jahrhunderte (weit vor 1970) befassen musste, häufig unterschiedliche Datums- und Uhrzeitdarstellungen. Beim Testen der Fälle von X.509-Zertifikaten (z. B. für HTTPS) und Zertifizierungsstellen (CAs) haben wir jedoch zahlreiche Softwareprobleme im Labor festgestellt, die bei Zertifikaten und CAs auftreten, die nach Y2038 ablaufen.OpenSSL hat insbesondere mehrere Zeitformate, wobei ASN1_UTCTIME ein Limit in Y2049 hat (ein anderes Problem als Y2038), also verwenden Sie die ASN1_TIME Funktionen bieten Kompatibilität mit allen Zeitbereichen. Das Konvertieren von Timeouts aus einer Bibliothek wie OpenSSL out in 32-Bit time_t ist ein zusätzlicher Bereich, in dem wahrscheinlich Probleme auftreten.

In vielen dieser Fälle war es möglich, die Probleme einfach durch Portieren und Kompilieren von Legacy-Software für 64-Bit-Architekturen zu lösen (z. B. um von einer 32-Bit-Ganzzahl time_t zu einer 64-Bit-time_t zu wechseln). In anderen Fällen waren umfangreichere Änderungen erforderlich, insbesondere wenn Zeiten für mathematische Zwecke in Ganzzahlen umgewandelt werden oder wenn Nachrichtendrahtformate beteiligt sind oder wenn Werte in Datenbanken gespeichert werden. Beim Testen und Beheben der Unterstützung für 20-jährige CAs zeigte sich, dass auch Downstream-Abhängigkeiten ins Spiel kommen. Wenn beispielsweise ein Datum 20 Jahre in der Zukunft in ein Protokollierungs- oder Überwachungssystem eingespeist wird und diese wiederum in Warnsysteme oder Berichtsdatenbanken oder Bereitstellungssysteme eingespeist werden, müssen diese möglicherweise alle behoben werden.

On-the-Wire-Nachrichten- und Dateiformate

Wie oben erwähnt, können die Auswirkungen von 32-Bit-Zeitstempeln in Nachrichten, Datenbanken oder Dateiformaten weit über ein bestimmtes System hinausgehen. Dies sind auch Systeme mit externen Abhängigkeiten, bei denen häufig eine erweiterte Planung erforderlich ist, da Interaktionen Systemgrenzen überschreiten. Für diese Sammlungen interoperabler Systeme müssen Änderungen möglicherweise in einer bestimmten Reihenfolge veröffentlicht werden, und häufig kommt die Abwärtskompatibilität ins Spiel. Wenn es formal oder informell standardisierte Protokolle gibt, die 32-Bit-Epochen-Zeitstempelwerte in Nachrichten verwenden, könnte jede Migration oder Korrektur auf der Festlegung des Standards beruhen. Daher werden diese wichtig, um sich Sorgen zu machen, wie bei einer Abhängigkeitskette wie:

1. Protokoll/Standards aktualisieren, um Zeitstempel nach Y2038 zu unterstützen.
2. Unterstützung für aktualisierten Standard in Softwarebibliotheken implementieren.
3. Holen Sie sich eine neue Version von Bibliotheken, die in Softwarepakete integriert sind.
4. Holen Sie sich Softwarepakete, die im neuen Versandprodukt enthalten sind.

Wenn dann jeder von diesen ein paar Jahre dauert und das Versandprodukt eine lange Lebensdauer hat, dann können die langen Vorlaufzeiten hier schon ein Problem sein.

Geräte mit langer Bereitstellungslebensdauer und deren Abhängigkeiten

Ein weiterer Bereich, auf den Sie sich frühzeitig konzentrieren sollten, sind Geräte mit langer Bereitstellungslebensdauer. Wie bereits erwähnt, ist es auch wichtig, die externen Abhängigkeiten dieser Geräte zu verfolgen. Eingebettete Geräte, die mit 32-Bit-Hardware ausgeliefert werden, haben möglicherweise auch keine einfache Lösung für „Kompilieren Sie einfach für ein 64-Bit-time_t“ über ein Softwareupdate, oder dies könnte inakzeptable Auswirkungen auf die Leistung haben.

Vernetzte Automobile und andere IoT-Geräte sind wahrscheinlich ein Bereich von besonderem Interesse, aber ich bin mir sicher, dass es viele andere ähnliche Arten von Geräten und Anwendungen gibt. Zum Beispiel ist es angesichts der aktuellen Trends wahrscheinlich, dass über 10% der heute verkauften Autos im Jahr 2038 noch in Betrieb sein werden, und mit zunehmendem Fahrzeugalter und der Anzahl der Fahrzeuge auf der Straße kann dies sogar noch höher sein. Wenn es einige Jahre dauert, bis Versandfahrzeuge im Allgemeinen Y2038-konform sind, können wir mit der aktuellen (und zunehmenden) Verteilung des Kraftfahrzeugalters einen erheblichen Teil der Kraftfahrzeuge mit dem Potenzial haben, in neunzehn Jahren ernsthafte Probleme zu haben. Das gleiche Muster gibt es wahrscheinlich auch in einigen anderen Branchen, z. B. in der Unterhaltungselektronik (z. B. Heimspielkonsolen und Smart-TVs), in denen Geräte mit vorinstallierten CA-Zertifikaten für mehr als 20 Jahre ausgeliefert werden.

Geräte mit langer Lebensdauer erfordern möglicherweise umfassendere Tests sowohl des Geräts als auch seiner Abhängigkeiten, z. B. das Testen, ob das Betriebssystem und die Software vor, während und nach dem Y2038-Übergangspunkt weiterhin ordnungsgemäß funktionieren.

Frohes neues Jahr!

Das Y2038-Problem ist in einer ähnlichen Kategorie wie IPv6: es handelt sich um eine mehrjährige Einführung, die im allgemeinen Fall wichtig, aber noch nicht dringend ist (gemäß der Eisenhower-Matrix). Aus dieser Perspektive ist jetzt ein guter Zeitpunkt, um mit der Planung, Erprobung und dem Testen zu beginnen, bevor es dringend (oder zu spät) wird. Konzentrieren Sie sich zunächst auf Software, die sich mit zukünftigen Daten, On-the-Wire-Nachrichten- und Dateiformaten sowie Geräten mit langer Akkulaufzeit befasst. Nutzen Sie als Nächstes die Erfahrungen aus dem anfänglichen Fokus, um in den kommenden Jahren ein umfassenderes Programm aufzubauen. Legen Sie unabhängig davon eine Mindestlatte fest und stellen Sie sicher, dass neue Software, Systeme, Protokolle und Produkte, die Sie erstellen und bereitstellen, keine Y2038-Probleme verursachen und Bedenken melden, wenn 32-Bit-Zeitstempel seit der Unix-Epoche in neuen Designs enthalten sind.

Erik Nygren ist Fellow und Chief Architect in der Platform Engineering Organization von Akamai. Im Juni feiert er sein 20-jähriges Bestehen bei Akamai.

Vielen Dank an mehrere Mitarbeiter von Akamai für ihre Beiträge zu diesem Artikel.

Obwohl bei der Erstellung dieses Dokuments Vorsichtsmaßnahmen getroffen wurden, hat Akamai Technologies, Inc. übernimmt keine Verantwortung für Fehler, Auslassungen oder Schäden, die sich aus der Verwendung der hierin enthaltenen Informationen ergeben. Die hierin enthaltenen Informationen können ohne vorherige Ankündigung geändert werden. Akamai und das Akamai Wave-Logo sind eingetragene Marken oder Dienstleistungsmarken in den USA (Reg. U.S. Pat. & Tm. Off). Veröffentlicht Januar 10, 2019.