Poco dopo Y2K abbiamo fatto battute su ” next up, Y2038!”ma allora si sentiva un’eternità nel futuro e probabilmente sarebbe stato il problema di qualcun altro. Ora che siamo a metà strada e abbiamo già raggiunto il punto in cui i problemi Y2038 possono causare errori software, è una buona opportunità per iniziare a pianificare Y2038. Ad esempio, il software potrebbe già avere problemi a lavorare con le durate dei certificati di 20 anni o i mutui di 20 anni e la frequenza di questi problemi aumenterà solo man mano che ci avviciniamo a Y2038. In Akamai stiamo già eseguendo pianificazione e test interni mirati strategicamente per Y2038 e sembra probabile che l’ambito di questo lavoro continuerà a crescere nei prossimi 19 anni man mano che questo importante sforzo aumenta di urgenza.

Molto poco è andato storto il 1 gennaio 2000 per noi (a parte alcuni Javascript su un sito di marketing di Akamai che mostrano “19100” come data corrente!), ma una cosa che viene persa è che l’impatto globale limitato quella sera era dovuto a due fattori: 1) la quantità di preparazione avanzata che è stata fatta; 2) molti “problemi Y2K” si sono effettivamente verificati con anni di anticipo piuttosto che durante il roll-over stesso. I secondi bisestili sono in qualche modo più spaventosi dei problemi di formato della data in quanto sono più difficili da testare e molto meno l’impatto avviene in anticipo. C’è il rischio che la mancanza di impatti di Y2K possa indurre le organizzazioni e i tecnologi a sottoprepararsi per Y2038. È anche più difficile spiegare “Y2038” ai laici rispetto a Y2K, rendendo potenzialmente più difficile dare priorità e concentrare il lavoro avanzato. Il gran numero di dispositivi Internet of Things (IoT) incorporati che diventano onnipresenti nel nostro ambiente rende anche il rischio probabile e l’impatto potenziale notevolmente più alti per Y2038 rispetto a Y2K.

La nostra esperienza iniziale con la pianificazione Y2038 (oltre a vedere shock da parte delle persone dopo aver sentito le preoccupazioni sollevate che al primo suono 19 anni di distanza) è che un approccio incrementale e mirato è necessario in questa fase. Programmi molto più coinvolti e completi saranno certamente necessari un certo numero di anni lungo la strada. In questa fase iniziale, alcune aree su cui concentrarsi includono: 1) software che si occupa di tempi e date futuri; 2) formati di messaggi e file on-the-wire; 3) dispositivi con una lunga durata di vita distribuita e le loro dipendenze. Naturalmente, man mano che ci avviciniamo, diventerà fondamentale iniziare a concentrarsi su set più ampi di sistemi, tra cui garantire che possano gestire la transizione Y2038 in modo sicuro.

Software che si occupa di date future

Forse l’area più importante su cui concentrarsi inizialmente è il software che si occupa di date future, come per la gestione dei certificati X. 509 o per la pianificazione finanziaria. Ci sono molte rappresentazioni di formato di data e ora, non tutte avranno un problema Y2038. Ad esempio, il software che ha bisogno di affrontare i tempi nei secoli passati (ben prima del 1970) spesso ha scelto rappresentazioni di data e ora diverse. Tuttavia, nel testare i casi di certificati X. 509 (ad esempio utilizzati per HTTPS) e autorità di certificazione (CAs), abbiamo riscontrato numerosi problemi software in laboratorio che iniziano a sorgere con certificati e CAS in scadenza dopo Y2038.

OpenSSL in particolare ha più formati temporali, con ASN1_UTCTIME che ha un limite in Y2049 (un problema distinto da pianificare da Y2038), quindi utilizzare le funzioni ASN1_TIME per fornire compatibilità con tutti gli intervalli di tempo. La conversione del time_t da una libreria come OpenSSL out in time_t a 32 bit è un’area aggiuntiva che potrebbe avere problemi.

In molti di questi casi è stato possibile risolvere i problemi semplicemente eseguendo il porting e la compilazione di software legacy per architetture a 64 bit (ad esempio, per passare da un time_t intero a 32 bit a un time_t a 64 bit). In altri casi sono state necessarie modifiche più estese, specialmente quando i tempi vengono espressi in numeri interi per la matematica o quando vengono coinvolti i formati dei messaggi o quando i valori sono memorizzati nei database. Nel testare e correggere il supporto per CAS di 20 anni, una cosa che è emersa è che entrano in gioco anche le dipendenze a valle. Ad esempio, se una data di 20 anni in futuro viene immessa in un sistema di registrazione o sistema di monitoraggio e se questi a loro volta si alimentano in sistemi di avviso o database di reporting o sistemi di provisioning, allora questi potrebbero anche aver bisogno di correzioni.

Formati di messaggi e file on-the-wire

Come accennato in precedenza, quando i timestamp a 32 bit vengono inseriti in messaggi, database o formati di file, l’impatto può estendersi ben oltre un sistema specifico. Questi sono anche sistemi con dipendenze esterne in cui è spesso necessaria una pianificazione più avanzata poiché le interazioni attraversano i confini del sistema. Per queste raccolte di sistemi interoperanti, potrebbe essere necessario rilasciare le modifiche in un ordine specifico e spesso entra in gioco la retrocompatibilità. Inoltre, se esistono protocolli formalmente o informalmente standardizzati che utilizzano valori di timestamp epoch a 32 bit nei messaggi, qualsiasi migrazione o correzione potrebbe essere basata sulla correzione dello standard. In quanto tali, questi diventano importanti di cui preoccuparsi come con una catena di dipendenze come:

1. Aggiorna protocollo / standard per supportare i timestamp post-Y2038.
2. Implementa il supporto per lo standard aggiornato nelle librerie software.
3. Ottieni una nuova versione delle librerie incorporate nei pacchetti software.
4. Ottenere pacchetti software inclusi nel nuovo prodotto di trasporto.

Quindi se ognuno di questi richiede alcuni anni e il prodotto di spedizione ha una lunga durata, i lunghi tempi di consegna qui potrebbero già essere un problema.

Dispositivi con una lunga durata di distribuzione e le loro dipendenze

Un’altra area su cui iniziare a concentrarsi in anticipo sono i dispositivi con una lunga durata di distribuzione. Come appena accennato, anche seguire le dipendenze esterne di questi dispositivi è importante. I dispositivi embedded che spediscono con hardware a 32 bit potrebbero anche non avere una facile correzione di “basta compilare per un time_t a 64 bit” tramite un aggiornamento software, o farlo potrebbe avere un impatto sulle prestazioni inaccettabile.

Le automobili connesse e altri dispositivi IoT sono probabilmente un’area di preoccupazione specifica, ma sono sicuro che ci sono molti altri tipi simili di dispositivi e applicazioni. Ad esempio, date le tendenze attuali è probabile che oltre il 10% delle auto vendute oggi sarà ancora operativo in Y2038, e con l’aumento dell’età del veicolo e del numero di veicoli sulla strada questo potrebbe essere ancora più alto. Se ci vogliono alcuni anni perché le automobili di spedizione siano generalmente conformi a Y2038, con l’attuale (e crescente) distribuzione delle età dei veicoli a motore potremmo finire con una frazione significativa di automobili con il potenziale di avere seri problemi in diciannove anni. Questo stesso modello probabilmente esiste anche in alcuni altri settori, come l’elettronica di consumo (come le console di gioco domestiche e i televisori intelligenti) in cui i dispositivi possono essere spediti con certificati CA 20+ year preinstallati.

I dispositivi con una lunga durata di utilizzo possono richiedere test più completi sia del dispositivo che delle sue dipendenze, ad esempio verificare che il sistema operativo e il software continuino a funzionare correttamente prima, durante e dopo il punto di transizione Y2038.

Felice Anno Nuovo!

Il problema Y2038 è in una categoria simile a IPv6: si tratta di un roll-out multi-decennio che nel caso generale è importante ma non ancora urgente (per la matrice di Eisenhower). Da questa prospettiva, ora è un buon momento come un altro per iniziare a pianificare, triaging e test prima che diventi urgente (o troppo tardi). Concentrati prima sul software che si occupa di date future, formati di messaggi e file on-the-wire e dispositivi con una lunga durata implementata. Successivamente, utilizzare l’esperienza dal focus iniziale per costruire un programma più completo nei prossimi anni. Indipendentemente da ciò, imposta una barra minima e inizia a assicurarti che i nuovi software, sistemi, protocolli e prodotti che stai creando e distribuendo non introducano problemi Y2038 e segnalino i problemi quando vedi timestamp a 32 bit-since-the-unix-epoch inclusi nei nuovi progetti.

Erik Nygren è Fellow e Chief Architect nell’organizzazione di Platform Engineering di Akamai. Festeggerà il suo 20 ° anniversario ad Akamai questo giugno.

Grazie a molte persone di Akamai per i loro contributi a questo articolo.

Mentre sono state prese precauzioni nella preparazione di questo documento, Akamai Technologies, Inc. non si assume alcuna responsabilità per errori, omissioni o danni derivanti dall’uso delle informazioni qui contenute. Le informazioni qui contenute sono soggette a modifiche senza preavviso. Akamai e il logo Akamai wave sono marchi registrati o marchi di servizio negli Stati Uniti (Reg. U. S. Pat. & Tm. Fuori). Pubblicato il 10 gennaio 2019.