Oltre il 2038: Debian rafforza le build a 32 bit con patch critiche
Il problema riguarda programmi che usano la rappresentazione POSIX per calcolare il tempo: essa calcola la data e l’ora del sistema sulla base del numero di secondi trascorsi dalla mezzanotte del 1º gennaio 1970 (ignorando i secondi intercalari). Questo tipo di sistema è lo standard per i sistemi Unix ed è presente anche in software per altri sistemi operativi che siano stati sviluppati in C. Sulla maggior parte dei sistemi a 32 bit il dato time.h, usato per questo calcolo, è rappresentato tramite un numero intero a 32 bit di tipo signed, ovvero con il segno.
Usando questo sistema, l’istante temporale più lontano rappresentabile corrisponde alle ore 03:14:07 del 19 gennaio 2038 (UTC). Dopo questo momento il contatore supererebbe il valore massimo ed indicherebbe un numero negativo, quindi i computer restituirebbero una data corrispondente non al 2038 ma al 1901 (precisamente le 20:45:52 UTC di venerdì 13 dicembre 1901), causando errori di calcolo. Il problema è chiamato “Year 2038”, “Y2038”, “Y2K38” o “Y2.038K”.
Il bug si può manifestare anche prima del 2038, se viene richiesto di operare con date corrispondenti o successive all’istante incriminato; ciò accadde, per esempio, nel 2006 al server web AOLserver, che gestiva le richieste senza scadenza al proprio database assegnando alle stesse una data di scadenza pari ad un miliardo di secondi dopo la loro immissione. Alle 21:27:28 del 12 maggio 2006, esattamente un miliardo di secondi prima delle 03:14:07 del 19 gennaio 2038, il sistema di calcolo superò il limite critico, restituendo una data di scadenza nel passato e causando un crash del sistema.
Debian promette che i pacchetti a 32 bit non creeranno più problemi dopo il 2038 poiché il team Debian ha già iniziato a lavorarci.
Per rendere il “sistema operativo universale” e a prova di futuro, il progetto Debian sta attivamente aggiornando il software a 32 bit per gestire le date oltre il famigerato bug temporale del 2038.
L’iniziativa del progetto Debian è parte di una transizione più ampia, con la versione a 64 bit time_t in corso nella versione experimental (nota anche con il suo nome in codice “RC-Buggy”) di Debian.
A differenza dei rilasci Debian unstable e testing, experimental non è una distribuzione completa, può funzionare solo come estensione di unstable. Perciò i pacchetti in experimental possono dipendere da pacchetti in unstable, ma i pacchetti in unstable non possono dipendere da pacchetti in experimental. Experimental è un’area di sosta/di collaborazione/sperimentale per lo sviluppo, quando è noto che un pacchetto ha problemi o potrebbe averne. Alcuni pacchetti o sviluppatori non usano experimental, semplicemente le nuove versioni vengono messe in unstable. La migrazione dei pacchetti da experimental a unstable è interamente a discrezione dei pacchettizzatori. Sebbene ci siano dei requisiti molto meno consistenti per i pacchetti in experimental, questi sono creati automaticamente dall’infrastruttura ufficiale di compilazione automatica dei pacchetti.
L’obiettivo principale del progetto Debian è quello di dotare le architetture a 32 bit in Debian 13 “Trixie” (prossima versione) per gestire senza problemi i timestamp che si riferiscono a tempi oltre il 2038. Questa transizione mira a essere il meno distruttiva possibile per i sistemi a 32 bit esistenti.
Il piano di implementazione, discusso sulla mailing list debian-devel, prevede caricamenti di massa da parte di non manutentori (NMU che sta per Non-Maintainer Uploads ovvero di modifiche ai pacchetti effettuate da persone diverse dai manutentori originali, per risolvere i problemi di compatibilità con le versioni precedenti) di oltre 1200 pacchetti di librerie per accogliere presunti cambiamenti di violazione dell’ABI (Application Binary Interface è un insieme di regole che definiscono come i programmi devono interagire con le librerie a livello binario). All’ultimo aggiornamento sono già state caricate nel ramo experimental circa 500 librerie.
Il piano include inoltre il caricamento di dpkg su unstable con “abi=time64” abilitato per impostazione predefinita. Successivamente, gli NMU si sposteranno su unstable, evidenziando tutti i pacchetti che non è stato possibile caricare inizialmente su experimental a causa di versioni in conflitto. Una volta costruite, verranno attivate delle modifiche ai pacchetti binari effettuate dai NMU per tutte le dipendenze inverse, ovvero per tutti i pacchetti che dipendono da quelli modificati.
Un aspetto degno di nota di questa transizione è l’inclusione di pacchetti di librerie il cui impatto ABI derivante dal passaggio di time_t a 64 bit non è stato definitivamente dimostrato. La decisione di includere questi pacchetti deriva dall’approccio pragmatico di dare priorità all’efficienza rispetto all’analisi esaustiva, dati i costi di ingegneria coinvolti nell’esame accurato di ciascun pacchetto.
I manutentori che ricevono un avviso dai NMU per il loro pacchetto experimental, cosa che ritengono non necessaria, sono incoraggiati a fornire una soluzione. Ciò consente ai manutentori Debian di analizzare approfonditamente gli header del pacchetto, dimostrando che l’ABI della libreria non viene influenzato dallo spostamento di time_t a 64 bit. In altre parole, se un manutentore pensa che il suo pacchetto non abbia bisogno di essere modificato per “abi=time64”, può provare a dimostrarlo con una verifica tecnica. In questo modo, si evitano degli aggiornamenti inutili o dannosi per il pacchetto.
Se sei interessato o valuti l’impatto dei tuoi progetti, visita il thread ufficiale nella mailing list. Puoi anche postare in debian-devel per qualsiasi domanda.
Fonte: https://lists.debian.org/debian-devel-announce/2024/02/msg00000.html
Fonte: https://it.wikipedia.org/wiki/Bug_dell%27anno_2038
Fonte: https://debugpointnews.com/debian-timet-2038/
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
2 risposte
[…] Il file system Ext2 ha un limite nella registrazione dei valori temporali negli “inode” di 32 bit che non gli consente di andare oltre la data del 19 gennaio 2038. Problema noto da tempo e che riguarda molte componenti del kernel Linux. […]
[…] In particolare, dopo aver completato la transizione t64 per proteggere il sistema dal problema Year 2038, gli sviluppatori hanno aggiornato GCC 14, glibc 2.40 e Python […]