strax efter Y2K gjorde vi skämt om ” nästa upp, Y2038!”men då kände det en evighet i framtiden och sannolikt att vara någon annans problem. Nu när vi är halvvägs där, och vi redan har nått den punkt där y2038-problem kan orsaka programvarufel, är det ett bra tillfälle att börja planera för Y2038. Till exempel kan programvara redan ha problem med att arbeta med 20-åriga certifikatlivstider eller 20-åriga inteckningar, och frekvensen av dessa problem kommer bara att öka när vi kommer närmare Y2038. På Akamai kör vi redan strategiskt riktad intern planering och testning för Y2038, och det verkar troligt att omfattningen av detta arbete kommer att fortsätta växa under de närmaste 19 åren, eftersom denna viktiga insats ökar i brådska.

mycket lite gick fel den 1 januari 2000 för oss (kort av lite Javascript på en Akamai-marknadsföringssida som visar ”19100” som aktuellt datum!), men en sak som saknas är att den begränsade globala effekten den kvällen berodde på två faktorer: 1) mängden avancerad förberedelse som gjordes; 2) Många ”Y2K-problem” inträffade faktiskt år i förväg snarare än under själva överrullningen. Leap sekunder är på vissa sätt skrämmande än datumformat problem genom att de är svårare att testa för och mycket mindre av effekterna händer i förväg. Det finns en risk att bristen på effekter av Y2K kan få organisationer och tekniker att förbereda sig för Y2038. Det är också svårare att förklara ”Y2038” för lekmän än Y2K, vilket kan göra det svårare att prioritera och fokusera avancerat arbete. Det stora antalet inbyggda Internet of Things (IoT) – enheter som blir allestädes närvarande i vår miljö gör också den troliga risken och potentiella effekten betydligt högre för Y2038 än för Y2K.

vår första erfarenhet av y2038-planering (förutom att man ser chock från människor när man hör oro som först låter 19 år bort) är att en inkrementell och fokuserad strategi behövs i detta skede. Mycket mer engagerade och omfattande program kommer säkert att behövas några år på vägen. I den här inledande fasen inkluderar vissa områden att fokusera på: 1) programvara som hanterar framtida tider och datum; 2) meddelande och filformat på ledningen; 3) enheter med långa distribuerade livstider och deras beroenden. Naturligtvis när vi kommer närmare blir det viktigt att börja fokusera på bredare uppsättningar system, inklusive att se till att de kan hantera övergången till y2038 på ett säkert sätt.

programvara som hanterar framtida datum

kanske är det viktigaste området att fokusera på initialt programvara som behandlar datum i framtiden, till exempel för hantering av X. 509-certifikat eller för ekonomisk planering. Det finns många datum-och tidsformatrepresentationer, inte alla kommer att ha ETT Y2038-problem. Till exempel valde programvara som behövde hantera tider under de senaste århundradena (långt före 1970) ofta olika datum-och tidsrepresentationer. Men när vi testade fallen med X. 509-certifikat (som används för HTTPS) och certifikatutfärdare (CAS) har vi hittat många programvaruproblem i labbet som börjar uppstå med certifikat och CAs som löper ut förbi Y2038.

OpenSSL har i synnerhet flera tidsformat, med ASN1_UTCTIME som har en gräns i Y2049 (ett distinkt problem att planera för från Y2038), så använd asn1_time-funktionerna ger kompatibilitet med alla tidsintervall. Att konvertera time out från ett bibliotek som OpenSSL out till 32-bitars time_t är ett ytterligare område som sannolikt kommer att få problem.

i många av dessa fall har det varit möjligt att lösa problemen helt enkelt genom att portera och sammanställa äldre programvara för 64-bitars arkitekturer (t.ex. att flytta från ett 32-bitars heltal time_t till en 64-bitars time_t). I andra fall har mer omfattande förändringar behövts, särskilt när tiderna kastas i heltal för matematik eller när meddelandetrådsformat involveras eller när värden lagras i databaser. Vid testning och fixering av stöd för 20-åriga CAs är en sak som visade sig att nedströms beroenden också spelar in. Till exempel, om ett datum 20 år i framtiden matas in i ett loggningssystem eller övervakningssystem, och om de i sin tur matas in i larmsystem eller rapporteringsdatabaser eller provisioneringssystem, då kan de också alla behöva korrigeringar.

on-the-wire meddelande och filformat

Som nämnts ovan, när 32-bitars tidsstämplar sätts i meddelanden, databaser eller filformat effekten kan sträcka sig långt bortom ett specifikt system. Dessa är också system med externa beroenden där mer avancerad planering ofta behövs som interaktioner över systemgränser. För dessa samlingar av interoperationssystem kan ändringar behöva släppas i en viss ordning och bakåtkompatibilitet spelar ofta in. Dessutom, om det finns antingen formellt eller informellt standardiserade protokoll som använder 32-bitars epoch tidsstämpel värden i meddelanden, någon migration eller fix kan baseras på fastställande av standarden. Som sådan blir dessa viktiga att oroa sig för som med en beroendekedja som:

1. uppdatera protokoll / standarder för att stödja tidsstämplar efter y2038.
2. implementera stöd för uppdaterad standard i programbibliotek.
3. få en ny version av bibliotek som ingår i programvarupaket.
4. få programvarupaket som ingår i den nya fraktprodukten.

om var och en av dessa tar några år och fraktprodukten har en lång livstid kan de långa ledtiderna här redan vara ett problem.

enheter med långa distribuerade livstider och deras beroenden

ett annat område att börja fokusera på tidigt är enheter med långa driftsättningslivstider. Som just nämnts är det också viktigt att följa de externa beroenden som dessa enheter har. Inbäddade enheter som levereras med 32-bitars hårdvara kanske inte heller har en enkel fix av ”bara kompilera för en 64-bitars time_t” via en programuppdatering, eller så kan det ha oacceptabel prestandapåverkan.

anslutna bilar och andra IoT-enheter är sannolikt ett område med särskild oro, men jag är säker på att det finns många andra liknande typer av enheter och applikationer. Med tanke på nuvarande trender är det troligt att över 10% av de bilar som säljs idag fortfarande kommer att fungera i Y2038, och med ökad fordonsålder och antal fordon på vägen kan detta vara ännu högre. Om det tar några år för fraktbilar att vara generellt y2038-kompatibla, med den nuvarande (och ökande) fördelningen av motorfordonåldrar kan vi sluta med en betydande del av bilar med potential att få allvarliga problem på nitton år. Samma mönster Finns sannolikt också i vissa andra branscher, till exempel inom konsumentelektronik (som hemspelkonsoler och smarta TV-apparater) där enheter kan levereras med 20+ års CA-certifikat förinstallerade.

enheter med lång driftstid kan kräva mer omfattande tester av både enheten och dess beroenden, till exempel testning av att operativsystemet och programvaran fortsätter att fungera korrekt före, under och efter Y2038-övergångspunkten.

Gott Nytt År!

y2038-problemet finns i en liknande kategori som IPv6: det är en utbyggnad med flera decennier som i det allmänna fallet är viktigt men ännu inte brådskande (per Eisenhower-matrisen). Ur detta perspektiv är det nu lika bra som någon att börja planera, triaging och testa innan det blir brådskande (eller för sent). Fokusera först på programvara som hanterar framtida datum, meddelande-och filformat på ledningen och enheter med långa distribuerade livstider. Använd sedan erfarenheten från det ursprungliga fokuset för att bygga ett mer omfattande program under de kommande åren. Oavsett, ange en minsta stapel och börja se till att ny programvara, system, protokoll och produkter du bygger och distribuerar inte introducerar y2038-problem och flaggproblem när du ser 32-bitars tidsstämplar-sedan-unix-epoken ingår i nya mönster.

Erik Nygren är Fellow och chefarkitekt i Akamais Plattformstekniska organisation. Han kommer att fira sitt 20-årsjubileum på Akamai i juni.

Tack till flera personer på Akamai för deras bidrag till den här artikeln.

medan försiktighetsåtgärder har vidtagits vid utarbetandet av detta dokument, Akamai Technologies, Inc. tar inget ansvar för fel, utelämnanden eller för skador som härrör från användningen av informationen häri. Informationen häri kan ändras utan föregående meddelande. Akamai och Akamai Wave-logotypen är registrerade varumärken eller servicemärken i USA (Reg. U. S. Pat. & Tm. Utanför). Publicerad 10 Januari 2019.