kort na Y2K maakten we grappen over ” next up, Y2038!”maar toen voelde het een eeuwigheid in de toekomst en waarschijnlijk het probleem van iemand anders. Nu we halverwege zijn en we al het punt hebben bereikt waar Y2038-problemen softwarefouten kunnen veroorzaken, is het een goede kans om te beginnen met plannen voor Y2038. Software kan bijvoorbeeld al problemen hebben die werken met een levensduur van 20 jaar certificaten of 20 jaar hypotheken, en de frequentie van deze problemen zal alleen maar toenemen als we dichter bij Y2038 komen. Bij Akamai zijn we al bezig met strategisch gerichte interne planning en testen voor Y2038, en het lijkt waarschijnlijk dat de reikwijdte van dit werk zal blijven groeien in de komende 19 jaar als deze belangrijke inspanning toeneemt in de urgentie.

Er ging weinig mis op 1 januari 2000 voor ons (afgezien van wat Javascript op een Akamai marketing site met “19100” als de huidige datum!), maar een ding dat wordt gemist is dat de beperkte wereldwijde impact die avond was te wijten aan twee factoren: 1) de hoeveelheid geavanceerde voorbereiding die werd gedaan; 2) veel “Y2K-problemen” hebben zich jaren van tevoren voorgedaan in plaats van tijdens de roll-over zelf. Schrikkelseconden zijn in sommige opzichten enger dan datumnotatie problemen in die zin dat ze moeilijker te testen en veel minder van de impact gebeurt op voorhand. Het risico bestaat dat het gebrek aan effecten van Y2K ertoe kan leiden dat organisaties en technologen zich onvoldoende voorbereiden op Y2038. Het is ook moeilijker om “Y2038” uit te leggen aan leken dan Y2K, waardoor het mogelijk moeilijker wordt om geavanceerd werk te prioriteren en te focussen. Het grote aantal embedded internet of Things (IoT) apparaten die alomtegenwoordig worden in onze omgeving maakt het waarschijnlijke risico en de potentiële impact voor Y2038 ook aanzienlijk groter dan voor Y2K.

onze eerste ervaring met y2038 planning (naast het zien van shock van mensen bij het horen van bezorgdheid die op het eerste geluid 19 jaar weg) is dat een incrementele en gerichte aanpak nodig is in dit stadium. Veel meer betrokken en uitgebreide programma ‘ s zal zeker een aantal jaren op de weg nodig zijn. In deze eerste fase, enkele gebieden om zich op te richten omvatten: 1) software omgaan met toekomstige tijden en data; 2)on-the-wire bericht en bestandsformaten; 3) apparaten met een lange levensduur en hun afhankelijkheden. Naarmate we dichterbij komen zal het natuurlijk van cruciaal belang worden om ons te gaan richten op bredere sets van systemen, inclusief ervoor te zorgen dat ze veilig kunnen omgaan met het oversteken van de y2038-overgang.

Software die betrekking heeft op toekomstige datums

misschien is het belangrijkste gebied waarop men zich in eerste instantie moet concentreren software die betrekking heeft op datums in de toekomst, zoals voor het verwerken van X. 509-certificaten of voor financiële planning. Er zijn veel datum-en tijdnotatievoorstellingen, die niet allemaal een Y2038-probleem hebben. Bijvoorbeeld, software nodig om te gaan met tijden in de afgelopen eeuwen (ruim voor 1970) vaak gekozen verschillende datum en tijd voorstellingen. Echter, bij het testen van de gevallen van X. 509 certificaten (zoals gebruikt voor HTTPS) en certificate authorities (Ca ‘s) hebben we tal van software problemen in het lab die beginnen te ontstaan met certificaten en Ca’ S verlopen verleden Y2038.

OpenSSL heeft in het bijzonder meerdere tijdindelingen, waarbij ASN1_UTCTIME een limiet heeft in Y2049 (een apart probleem om voor te plannen vanaf Y2038), dus gebruik de asn1_time functies bieden compatibiliteit met alle tijdbereiken. Het omzetten van time out vanuit een bibliotheek zoals OpenSSL out naar 32-bit time_t is een extra gebied dat waarschijnlijk problemen zal hebben.

in veel van deze gevallen was het mogelijk om de problemen op te lossen door simpelweg oudere software voor 64-bits architecturen te porten en te compileren (bijvoorbeeld om van een 32-bits integer time_t naar een 64-bits time_t over te stappen). In andere gevallen zijn uitgebreidere veranderingen nodig, vooral wanneer tijden in gehele getallen worden gegoten voor wiskunde of wanneer message wire formaten betrokken raken of wanneer waarden worden opgeslagen in databases. Bij het testen en bevestigen van ondersteuning voor 20-jaar CAs, een ding dat bleek is dat downstream afhankelijkheden ook in het spel komen. Bijvoorbeeld, als een datum 20 jaar in de toekomst wordt ingevoerd in een logging systeem of monitoring systeem, en als die in-turn feed in alarmeringssystemen of rapportage databases of provisioning systemen, dan kunnen die ook allemaal fixes nodig.

on-the-wire bericht en bestandsindelingen

zoals hierboven vermeld, kan het effect van 32-bits tijdstempels in berichten, databases of bestandsindelingen veel verder reiken dan een specifiek systeem. Dit zijn ook systemen met externe afhankelijkheden waar meer geavanceerde planning vaak nodig is omdat interacties systeemgrenzen overschrijden. Voor deze collecties van interoperabele systemen moeten wijzigingen mogelijk in een bepaalde volgorde worden vrijgegeven en vaak speelt achterwaartse compatibiliteit een rol. Bovendien, als er formeel of informeel gestandaardiseerde protocollen zijn die 32-bits epoch-tijdstempelwaarden gebruiken in berichten, kan elke migratie of oplossing gebaseerd zijn op de vaststelling van de standaard. Als zodanig, deze worden belangrijk om zich zorgen over te maken als met een afhankelijkheidsketen zoals:

1. protocol / standaarden bijwerken om post-Y2038 tijdstempels te ondersteunen.
2. implementeer ondersteuning voor bijgewerkte standaard in softwarebibliotheken.
3. laat een nieuwe versie van bibliotheken opnemen in softwarepakketten.
4. krijg softwarepakketten in Nieuw verzendproduct.

als elk van deze twee een paar jaar duurt en het verschepende product een lange levensduur heeft, dan kunnen de lange levertijden hier al een probleem zijn.

apparaten met een lange implementatielevensduur, en hun afhankelijkheden

een ander gebied om te beginnen met het focussen op early zijn apparaten met een lange implementatielevensduur. Zoals zojuist vermeld, volgen door de externe afhankelijkheden deze apparaten hebben is ook belangrijk. Embedded apparaten verzending met 32-bit hardware kan ook niet een eenvoudige oplossing van “gewoon compileren voor een 64-bit time_t” via een software-update, of dit te doen kan onaanvaardbare prestaties invloed hebben.

verbonden Auto ‘ s en andere IoT apparaten zijn waarschijnlijk een gebied van specifieke zorg, maar ik ben er zeker van dat er veel andere soortgelijke soorten apparaten en toepassingen. Gezien de huidige trends is het bijvoorbeeld waarschijnlijk dat meer dan 10% van de vandaag verkochte auto ‘ s nog steeds in Y2038 zal rijden, en met de toename van de leeftijd van het voertuig en het aantal voertuigen op de weg kan dit zelfs nog hoger zijn. Als het een paar jaar duurt voor de scheepvaart auto ’s over het algemeen y2038 compliant, met de huidige (en toenemende) distributie van motorvoertuigen leeftijden we kunnen eindigen met een aanzienlijk deel van de auto’ s met het potentieel om ernstige problemen in negentien jaar. Dit zelfde patroon bestaat waarschijnlijk ook in sommige andere industrieën, zoals in consumentenelektronica (zoals thuis gaming consoles en slimme televisies) waar apparaten kunnen worden verzonden met 20+ jaar CA-certificaten vooraf geïnstalleerd.

apparaten met een lange levensduur vereisen mogelijk uitgebreidere tests van zowel het apparaat als de afhankelijkheden ervan, zoals testen of het besturingssysteem en de software goed blijven werken vóór, tijdens en na het y2038-overgangspunt.

Gelukkig Nieuwjaar!

Het Y2038-probleem valt in een vergelijkbare categorie als IPv6: het is een multi-decade uitrol die in het algemeen belangrijk is, maar nog niet dringend (volgens de Eisenhower Matrix). Vanuit dit perspectief is het nu een goed moment om te beginnen met plannen, triaging en testen voordat het dringend wordt (of te laat). Focus eerst op software die te maken heeft met toekomstige data, on-the-wire berichten en bestandsformaten, en apparaten met een lange levensduur. Gebruik vervolgens de ervaring van de initiële focus om de komende jaren een uitgebreider programma op te bouwen. Hoe dan ook, Stel een minimumbalk in en zorg ervoor dat nieuwe software, systemen, protocollen en producten die u bouwt en implementeert geen Y2038-problemen introduceren en zorgen over vlaggen als u 32-bits tijdstempels-sinds-de-unix-epoch ziet die zijn opgenomen in nieuwe ontwerpen.Erik Nygren is een Fellow en Chief Architect in Akamai ‘ s Platform Engineering organization. Hij viert zijn 20ste verjaardag in Akamai in juni.

dank aan meerdere mensen bij Akamai voor hun bijdragen aan dit artikel.hoewel bij de voorbereiding van dit document voorzorgsmaatregelen zijn genomen, heeft Akamai Technologies, Inc. aanvaardt geen verantwoordelijkheid voor fouten, weglatingen of schade als gevolg van het gebruik van de informatie hierin. De informatie in dit document kan zonder voorafgaande kennisgeving worden gewijzigd. Akamai en het Akamai wave logo zijn gedeponeerde handelsmerken of dienstmerken in de Verenigde Staten (Reg. U. S. Pat. & Tm. Van). Gepubliceerd Op 10 Januari 2019.