la scurt timp după Y2K am făcut glume despre „următorul, Y2038!”dar atunci a simțit o eternitate în viitor și probabil că va fi problema altcuiva. Acum că suntem la jumătatea drumului și am ajuns deja la punctul în care problemele Y2038 pot provoca defecțiuni software, este o bună oportunitate de a începe planificarea pentru Y2038. De exemplu, software-ul poate avea deja probleme de lucru cu durata de viață a certificatelor de 20 de ani sau ipoteci de 20 de ani, iar frecvența acestor probleme va crește doar pe măsură ce ne apropiem de Y2038. La Akamai desfășurăm deja o planificare și testare internă orientate strategic pentru Y2038 și se pare că domeniul de aplicare al acestei lucrări va continua să crească în următorii 19 ani, pe măsură ce acest efort important crește în urgență.

foarte puțin a mers prost la 1 ianuarie 2000 pentru noi (scurt de unele Javascript pe un site de marketing Akamai afișarea „19100” ca data curentă!), dar un lucru care este ratat este că impactul global limitat în acea seară s-a datorat a doi factori: 1) Cantitatea de pregătire avansată care a fost făcută; 2) multe „probleme Y2K” au apărut de fapt cu ani în avans, mai degrabă decât în timpul rulării în sine. Secundele de salt sunt în unele moduri mai înfricoșătoare decât problemele de format de dată, deoarece sunt mai greu de testat și mult mai puțin din impact se întâmplă în avans. Există riscul ca lipsa impactului Y2K să determine organizațiile și tehnologii să nu se pregătească pentru Y2038. De asemenea, este mai greu să explici „Y2038” oamenilor laici decât Y2K, ceea ce poate face mai dificilă prioritizarea și concentrarea muncii avansate. Numărul mare de dispozitive integrate Internet of Things (IoT) care devin omniprezente în mediul nostru face, de asemenea, riscul probabil și impactul potențial considerabil mai mare pentru Y2038 decât a fost pentru Y2K.

experiența noastră inițială cu planificarea Y2038 (în afară de a vedea șocul de la oameni la auzul preocupărilor ridicate, care la început sună la 19 ani distanță) este că este necesară o abordare incrementală și concentrată în acest stadiu. Programe mult mai implicate și cuprinzătoare vor fi cu siguranță necesare unele număr de ani pe drum. În această fază inițială, unele domenii să se concentreze asupra includ: 1) software-ul care se ocupă cu orele și datele viitoare; 2) mesaj on-the-wire și formate de fișiere; 3) dispozitive cu durate lungi de viață desfășurate și dependențele acestora. Desigur, pe măsură ce ne apropiem, va deveni esențial să începem să ne concentrăm pe seturi mai largi de sisteme, inclusiv să ne asigurăm că acestea pot gestiona trecerea tranziției Y2038 în siguranță.

Software care se ocupă de datele viitoare

poate că cel mai important domeniu pe care să ne concentrăm inițial este software-ul care se ocupă de datele viitoare, cum ar fi gestionarea certificatelor X. 509 sau planificarea financiară. Există multe reprezentări în format de dată și oră, nu toate vor avea o problemă Y2038. De exemplu, software-ul care a trebuit să se ocupe de vremurile din secolele trecute (cu mult înainte de 1970) a ales adesea reprezentări diferite de dată și oră. Cu toate acestea, în testarea cazurilor de certificate X. 509 (cum ar fi utilizate pentru HTTPS) și autoritățile de certificare (CAs) am găsit numeroase probleme software în laborator care încep să apară cu certificatele și CAs care expiră după Y2038.

OpenSSL are în special mai multe formate de timp, ASN1_UTCTIME având o limită în Y2049 (o problemă distinctă de planificat de la Y2038), deci utilizați funcțiile ASN1_TIME oferă compatibilitate Cu toate intervalele de timp. Conversia timpilor dintr-o bibliotecă, cum ar fi OpenSSL out în time_t pe 32 de biți, este o zonă suplimentară care poate avea probleme.

în multe dintre aceste cazuri a fost posibilă rezolvarea problemelor pur și simplu prin portarea și compilarea software-ului vechi pentru arhitecturi pe 64 de biți (de exemplu, pentru a trece de la un time_t întreg pe 32 de biți la un time_t pe 64 de biți). În alte cazuri, au fost necesare modificări mai extinse, mai ales atunci când timpurile se aruncă în numere întregi pentru matematică sau când se implică formate de sârmă de mesaje sau când valorile sunt stocate în baze de date. În testarea și fixarea suportului pentru CAs de 20 de ani, un lucru care a apărut este că dependențele din aval intră și ele în joc. De exemplu, dacă o dată de 20 de ani în viitor va fi introdusă într-un sistem de logare sau sistem de monitorizare și dacă acestea se alimentează la rândul lor în sisteme de alertare sau baze de date de raportare sau sisteme de aprovizionare, atunci acestea ar putea avea nevoie, de asemenea, de remedieri.

formate de mesaje și fișiere pe fir

după cum s-a menționat mai sus, atunci când marcajele de timp pe 32 de biți sunt introduse în mesaje, baze de date sau formate de fișiere, impactul se poate extinde mult dincolo de un anumit sistem. Acestea sunt, de asemenea, sisteme cu dependențe externe în care este adesea necesară o planificare mai avansată, deoarece interacțiunile depășesc limitele sistemului. Pentru aceste colecții de sisteme de interoperare, este posibil ca modificările să fie lansate într-o anumită ordine, iar compatibilitatea înapoi intră adesea în joc. Mai mult, dacă există protocoale standardizate formal sau informal care utilizează valori ale marcajului de timp epoch pe 32 de biți în mesaje, orice migrare sau remediere ar putea fi bazată pe fixarea standardului. Ca atare, acestea devin importante pentru a vă îngrijora ca și în cazul unui lanț de dependență, cum ar fi:

1. actualizați protocolul / standardele pentru a sprijini marcajele de timp post-Y2038.
2. implementarea suportului pentru standardul actualizat în bibliotecile de software.
3. obțineți o nouă versiune a bibliotecilor încorporate în pachetele software.
4. obțineți pachete software incluse în noul produs de expediere.

apoi, dacă fiecare dintre acestea durează câțiva ani și produsul de expediere are o durată lungă de viață, atunci timpii lungi de plumb aici pot fi deja o problemă.

dispozitive cu durate lungi de viață desfășurate și dependențele lor

Un alt domeniu pentru a începe să vă concentrați mai devreme sunt dispozitivele cu durate lungi de desfășurare. Așa cum am menționat, urmărirea dependențelor externe pe care le au aceste dispozitive este, de asemenea, importantă. Dispozitivele încorporate livrate cu hardware pe 32 de biți pot, de asemenea, să nu aibă o soluție ușoară de „compilați doar pentru un time_t pe 64 de biți” printr-o actualizare de software sau acest lucru ar putea avea un impact inacceptabil asupra performanței.

automobilele conectate și alte dispozitive IoT sunt probabil o zonă de îngrijorare specifică, dar sunt sigur că există multe alte tipuri similare de dispozitive și aplicații. De exemplu, având în vedere tendințele actuale, este probabil ca peste 10% din mașinile vândute astăzi să funcționeze în continuare în Y2038, iar odată cu creșterea vârstei vehiculului și a numărului de vehicule pe șosea, acest lucru poate fi și mai mare. În cazul în care este nevoie de câțiva ani pentru automobile de transport maritim să fie, în general, y2038 conforme, cu curent (și în creștere) distribuția de autovehicule vârstele am putea ajunge cu o fracțiune semnificativă de automobile cu potențialul de a avea probleme serioase în nouăsprezece ani. Același model există probabil și în alte industrii, cum ar fi electronica de consum (cum ar fi consolele de jocuri de acasă și televizoarele inteligente), unde dispozitivele pot fi livrate cu certificate CA de peste 20 de ani preinstalate.

dispozitivele cu o durată de viață lungă pot necesita o testare mai cuprinzătoare atât a dispozitivului, cât și a dependențelor sale, cum ar fi testarea faptului că sistemul de operare și software-ul continuă să funcționeze corect înainte, în timpul și după punctul de tranziție Y2038.

An Nou Fericit!

problema Y2038 este într-o categorie similară cu IPv6: este o lansare de mai multe decenii care, în cazul general, este importantă, dar nu este încă urgentă (conform matricei Eisenhower). Din această perspectivă, acum este un moment la fel de bun ca oricare altul pentru a începe planificarea, triajul și testarea înainte de a deveni urgent (sau prea târziu). Concentrați-vă mai întâi pe software-ul care se ocupă de datele viitoare, formatele de mesaje și fișiere on-the-wire și dispozitivele cu o durată de viață lungă. Apoi, utilizați experiența din accentul inițial pentru a construi un program mai cuprinzător în următorii ani. Indiferent, setați o bară minimă și începeți să vă asigurați că software-ul, sistemele, protocoalele și produsele noi pe care le construiți și le implementați nu introduc probleme Y2038 și semnalați preocupările atunci când vedeți marcajele de timp pe 32 de biți-de la epoca unix inclusă în noile modele.

Erik Nygren este un coleg și arhitect șef în Organizația de Inginerie a platformei Akamai. Va sărbători cea de-a 20-a aniversare la Akamai în iunie.

vă mulțumesc mai multor oameni de la Akamai pentru contribuțiile lor la acest articol.

în timp ce au fost luate măsuri de precauție în pregătirea acestui document, Akamai Technologies, Inc. nu își asumă nicio responsabilitate pentru erori, omisiuni sau pentru daune rezultate din utilizarea informațiilor de aici. Informațiile de aici pot fi modificate fără notificare prealabilă. Akamai și sigla Akamai wave sunt mărci comerciale înregistrate sau mărci de servicii în Statele Unite (Reg. U. S. Pat. & Tm. Oprit). Publicat 10 Ianuarie 2019.