Dal 2004 il blog di Antonio Troise

Alle ore 3:31:30 PM dello scorso venerdi 13 febbraio 2009 (in Italia, a causa del fuso orario, erano le 00:31:30 del 14 Febbraio 2009), l’orologio interno dei sistemi Unix (e quindi anche Mac OS X) ha raggiunto il valore, non indifferente, di 1234567890 secondi. Infatti, come è noto, nei sistemi operativi Unix e Unix-like il tempo viene rappresentato come offset in secondi rispetto alla mezzanotte (UTC) del 1º gennaio 1970 (definita epoca o Epoch Time). Quindi, contando il tempo a partire dall’Epoch Time ad oggi sono appunto passati 1.234.567.890 secondi. Questo tipo di rappresentazione ha il vantaggio che, oltre che ad essere compatta, è indipendente dai fusi orari, ed è quindi direttamente confrontabile anche tra calcolatori situati a grandi distanze geografiche tra loro, ed evita di dover effettuare aggiustamenti nel caso ad esempio di dati trasmessi da un fuso orario all’altro. L’unico svantaggio è che, per averne una rappresentazione sotto forma di data e ora locali, è necessario effettuare una conversione (sempre comunque lasciata al sistema operativo).

1234567890 Day

Sebbene, questo evento non abbia nulla di realmente universale (è stato un convenzione comune decidere di iniziare a far scandire arbitrariamente l’orologio interno del cuore dei sistemi operativi Unix dalla data del 1970, ma c’è chi nota come lo scandire dell’Epoch Time sia approssimativamente vicina allo sbarco sulla Luna), l’evento ha suscitato un valore mediatico minimo, ma, al contempo, ha coinvolto i geek più puri di tutto il mondo (dai syadmin ai consulenti IT fino ad arrivare al semplice appassionato di Linux), in una maniera che solo internet può regalare con la versione geek del capodanno dell’anno 2000.

Infatti, questa curiosa ricorrenza ha visto persino dei festeggiamenti “ufficiali” da parte di gruppi di utenza e di programmazione in tutto il mondo. Il sito che ha raccolto tutti questi eventi è stato 1234567890day.com con tanto di countdown in homepage, anche se, per la verità, per molti questa ricorrenza altro non era che una scusa per organizzare una vera e propria rimpatriata di amici amanti del pinguino.

La celebrazione di questo particolare evento è stata pianificata in diverse città di tutto il mondo (San Francisco, Vancouver, Seattle, Los Angeles, Nairobi, Vienna, Copenaghen, Budapest, Croazia, etc … ovviamente è mancata una località italiana).

Per chi, comunque, non era riuscito a festeggiare questa singolarità numerica in compagnia, non è mancato il supporto di Digg (con oltre 5005 diggs) e di Twitter che ha unito centinaia di followers (423 per l’appunto) uniti nei festeggiamenti davanti al proprio monitor, magari supportati dalla Desk clock from ThinkGeek, una sveglia capace di visualizzare la data e l’ora in diversi formati, tra cui, oltre quello standard, anche Esadecimale, Ottale, Binario, a Numeri Romani e, ovviamente, nel formato Unix Epoch Time.

In alternativa, il sito Cool Epoch Countdown ha fornito, e fornisce tuttora, in tempo reale lo scandire del tempo in Unix Time.

Se questi festeggiamenti vi sono sembrati assurdi, allora dovete sapere che le frasi più ricorrenti che giravano sulla blogosfera fino a qualche giorno primo, erano tutte di genere apocalittico, come questa:

It’s The End Of The World As We Know It!
There’s a fairly good chance the world is going to end tomorrow…at least the world of Unix

Ovviamente, quando si tratta di cose strane, anche Google ci mette lo zampino e per festeggiare il 1234567890 Day, Google ha proposto uno dei suoi Doodle riportante la scritta

$ date +%s …
1234567890

Per i non addetti ai lavori, “date +%s” è il comando da lanciare sul vostro terminale linux/unix like/mac os x per vedere visualizzata la data nel formato unix time. Per sapere a che ora e che giorno corrisponde una particolare data in unix time, è sufficiente lanciare questo script in Perl (ma potete anche visitare uno dei tanti siti di conversione data/unix time):

perl -e ‘print scalar localtime(1234567890),”\n”;’
Sat Feb 14 00:31:30 2009

Altre celebrazioni numeriche create ad hoc

E se nel lontano 09 Settembre 2001 (2001-09-09T01:46:40Z) si sono festeggiati a Copenhagen in Danimarca (presso il DKUUG), il primo 1.000.000.000 di secondi, allora vi farà piacere che che nel lontano 18 Maggio 2033 alle ore 03:33:20, ricorrerà la celebrazione del Secondo Billenium: 2000000000!

perl -e ‘print scalar localtime(2000000000),”\n”;’
Wed May 18 05:33:20 2033

La cosa buffa è che, giocando con questo piccolo script in Perl, ho scoperto che il 9 Agosto del 2005, è ricorso il Fibonacci Day dei sistemi Unix (ho sostituito la data in unix time con la Successione di Fibonacci, escluso lo zero iniziale, 1123581321):

perl -e ‘print scalar localtime(1123581321),”\n”;’
Tue Aug 9 11:55:21 2005

ma nessuno ne ha mai parlato (o sbaglio?). Forse era una ricorrenza da geek matematici, una specie ancora più rara dei normali geek!

Continuando, possiamo notare che, il 14 Novembre del 2014, si potrebbe festeggiare il Pi Greco Decimal Day per i sistemi Unix (prendendo in esame la prima parte decimale del pi greco):

perl -e ‘print scalar localtime(1415926535),”\n”;’
Fri Nov 14 01:55:35 2014

Come vedete, i motivi per festeggiare ce ne saranno molti ed è tutto frutto della psicologia della ricorrenza numerica. Un comportamento tutto tipico dell’essere umano, che si è dimostrato in tutta la sua potenza mediatica nell’anno 2000 (amplificato poi anche dal famoso Millennium Bug). Per l’uomo tutte le ricorrenze numeriche sono sempre affascinanti, come quando si prendono le misure della Piramide di Cheope della piana di Giza in Egitto e si scopre che dividendo il perimetro della Piramide per il doppio dell’altezza si ottiene un valore molto simile al pi-greco. O quando Joseph Seiss, un ecclesiastico americano, scrisse che le pietre della Piramide contenevano un sistema di numeri che indicavano misure, pesi, angoli, temperature, gradi, problemi geometrici e rilevamenti cosmici. Seiss fu sorpreso dalla ricorrente presenza nei suoi calcoli del numero 5!

E che dire della sequenza numerica 4 – 8 – 15 – 16 – 23 – 42, nota come Equazione di Valenzetti, che la DHARMA, nel mondo immaginario del serial televisivo Lost, aveva il compito di modificare per evitare la fine dell’umanità. In poco tempo finzione e realtà si sono fusi insieme, girando per internet e assumendo connotazioni di quasi-realtà.

Ovviamente alcune ricorrenze numeriche sono talmente singolari che appaiono dare un significato agli eventi più strani, dando una sorta di potere ai numeri che si trasformano in elementi cabalo-matematici.

Il Bug del 2038

Ma vi è un’altra data che i programmatori di tutto il mondo stanno aspettando, questa volta, con grande paura (come quella del Millennium Bug): è il 19 gennaio 2038 alle ore 03:14:07 AM. Dopo questo momento, il contatore supererebbe il valore massimo, e verrebbe considerato come un numero negativo. I computer leggeranno la data non come 2038 ma come 1901 (precisamente, le 20:45:52 di venerdì 13 dicembre 1901) causando errori di calcolo!

Il problema è noto da tempo a tutti e la causa del bug informatico dell’anno 2038 (“Year 2038” è chiamato anche “Y2038″, “Y2K38″, o “Y2.038K” nel linguaggio specialistico) è da imputarsi all’architettura a 32 bit di molte macchine unix attualmente esistenti che usano, come spiegato prima, la rappresentazione POSIX per calcolare il tempo (partendo dal numero di secondi a partire dal 1 gennaio 1970). Questo tipo di sistema è lo standard per i sistemi Unix, e colpisce anche software per altri sistemi operativi che siano stati sviluppati in C. Sulla maggior parte dei sistemi a 32 bit il valore del dato time_t usato per questo calcolo è un numero intero a 32 bit di tipo signed.

Infatti, se un programmatore crea una variabile di tipologia intero segnato per memorizzare un valore numerico, questo può essere come minimo -2147483648 e come massimo 2147483647. Un numero molto grande, ma che diventa un valore piccolissimo se lo trasformiamo in secondi. In 32 bit, infatti, ci stanno appena 136 anni! Usando questo sistema, la data più avanzata rappresentabile a partire dalle 00:00:00 del 1/1/1970 sono le 03:14:07 di giovedì 19/01/2038!

La cosa interessante è che il mondo POSIX comprende, oltre ai sistemi operativi derivati dal sistema UNIX (GNU/Linux, BSD, Solaris, Mac OS X), anche tutti i protocolli di rete UNIX style (http, ftp, etc). In parole povere, se le previsioni nefaste degli addetti ai lavori si avverassero, sarebbe anche la fine di internet (che funziona grazie a protocolli Unix) e dei principali server del globo (che utilizzano sistemi operativi derivati da Unix). Dopo quel secondo saremo proiettati nel 13 dicembre 1901 alle 20:45. Sicuramente questo sarà un problema da gestire da qui ai prossimi anni e richiederà un cambio epocale nella gestione del tempo e di tutto il resto nei sistemi Unix. In teoria la soluzione è semplice e già disponibile, e consiste nell’usare solo sistemi a 64 bit, come il 99% dei processori in commercio attualmente. Infatti, nei sistemi a 32 bit il limite massimo di un intero è (2^32) – 1, mentre in quelli a 64 bit è (2^64) – 1.

Come denunciato anche dal sito ufficiale, 2038bug.com, però, l’errore comune è quello di credere che il problema verrà risolto con la semplice adozione dei 64 bit, non considerando che i molti strumenti che utilizzano sistemi embedded (forni a microonde, ascensori, orologi da polso, ecc.), sono ancora a 8/16 bit e che molti database utilizzano, per i propri campi data, dei Timestamp a 32 bit.

Un aspetto curioso di questa faccenda è che su questo bug del 2038 è stata costruita la storia di John Titor, un fantomatico uomo del futuro (2036) tornato nel 1975 per recuperare un esemplare di IBM 5100 come sorta di moderna Stele di Rosetta, poiché sarebbe l’unica macchina capace di risolvere il bug che sconvolgerebbe il mondo.

Interessante come, anche in questo caso, Google ci abbia messo lo zampino, perché i più attenti avranno scoperto che la data di scadenza dei cookie di Google è il 17 gennaio 2038, due giorni prima della fine dell’Unix Epoch (solo dopo questa data il browser può procedere all’eliminazione dei dati contenuti nel cookie stesso).

Ovviamente c’è anche chi, per celebrare l’evento, ha iniziato vendere magliette con la fine dell’Unix Epoch, ma anche tazze e mousepad per ricordarvi che, la fine dei sistemi operativi come voi li conoscete, è vicina!

Se invece, volete verificare se il vostro sistema è immune o meno da questo bug, ecco il codice C da compilare:

<br /> #include <stdlib .h><br /> #include <stdio .h><br /> #include <unistd .h><br /> #include <time .h></p> <p>int main (int argc, char **argv)<br /> {<br /> time_t t;<br /> t = (time_t) 1000000000;<br /> printf (“%d, %s”, (int) t, asctime (gmtime (&t)));<br /> t = (time_t) (0x7FFFFFFF);<br /> printf (“%d, %s”, (int) t, asctime (gmtime (&t)));<br /> t++;<br /> printf (“%d, %s”, (int) t, asctime (gmtime (&t)));<br /> return 0;<br /> }<br />

Questo semplice esempio in C mostra come l’aggiunta di un solo secondo al Timestamp ”Tue Jan 19 03:14:07 2038” lo tramuti in un sinistro venerdì 13 dicembre 1901. Quindi, se il vostro sistema è a 32 bit, dovrebbe produrre questo risultato:

1000000000, Sun Sep 9 01:46:40 2001
2147483647, Tue Jan 19 03:14:07 2038
-2147483648, Fri Dec 13 20:45:52 1901

Ecco una simulazione di quello che accadrebbe nel 2038 ai sistemi unix a 32 bit:

UPDATE: Ho appena scoperto che molti geek matematici festeggiano la giornata della radice quadrata che viene celebrata nella data in cui, sia il giorno che il mese, risultano essere la radice delle ultime due cifre dell’anno. L’ultima festività è occorsa il 03 Marzo 2009 (3/3/09 Square Root Day), ma beccare la radice giusta non è facile come sembra (sembra che capiti solo 9 volte in un secolo). Se vogliamo continuare a dare i numeri, l’ultimo giorno papabile prima di questo è stato infatti il due febbraio del 2004, che casualmente coincideva con il ‘giorno della marmotta’ americano. Per festeggiare di nuovo dovremo aspettare ben sette anni, esattamente il quattro aprile del 2016. Il primo a celebrare questo evento è stato, nella lontana radice dell’81, Ron Gordon.

Molti potrebbero notare che, ancora una volta, la Microsoft ha dimostrato che i suoi prodotti spesso risultano poco affidabili: da Windows con le sue schermate blu, alla Xbox 360 con il suo Red Ring of Death, fino ad arrivare ad alcuni modelli degli Zune che non gestiscono l’anno bisestile. Certo, di fronte alla precisione certosina di certi prodotti Apple, si potrebbe avere anche ragione, ma resta il fatto che, almeno una nota positiva c’è: anche in giorni festivi come questi, l’intervento del team Microsoft è stato tempestivo e in poche ore ha saputo dare una risposta a tutti gli utenti infuriati che, a partire dalla mattinata del 31 dicembre, si sono visti bloccati migliaia di lettori Zune da 30 gigabyte prodotti nel 2006: sullo schermo dell’apparecchio musicale appariva solo l’icona che contraddistingue il modello Zune e una barra di caricamento, ma era impossibile accendere e utilizzare l’apparecchio e, quindi, di fatto non hanno potuto ascoltare la propria musica (magari acquistata anche sullo store di musica online Zune Pass). Tanto tempestiva, che, forse, fa pensare che erano già al corrente del problema (tanto che sui modelli venduti più recentemente il problema non si è mai presentato): e, infatti, sembra che la Microsoft, sul suo forum ufficiale, aveva inviato una segnalazione del problema ma, come era facile prevedere, molti utenti non sapevano nulla del bug.

Certo, il problema, che comunque ha causato un non irrilevante imbarazzo per il gigante del software, poteva anche essere più grave del previsto, e la velocità di assistenza è stata dettata sicuramente dalla paura di perdere, in un colpo solo, migliaia di vecchi e nuovi utenti, che potevano migrare improvvisamente sui lettori di casa Apple. Resta, comunque, il fatto che, a poche ore dalla fine dell’anno il dispositivo dell’orologio interno del driver è andato in tilt!

Il dettagli del problema

Quel che è certo è che la Microsoft non ha iniziato bene il 2009 visto che ha scoperto, a cose già fatte, come si legge in un comunicato stampa diffuso sul sito Zune, che tutti i suoi lettori mp3 Zune da 30GB dell’anno 2006, hanno un bug nel driver dell’orologio interno correlato al modo in cui il dispositivo gestisce un anno bisestile, tanto che il passaggio dal 2008 al 2009 ha creato, all’interno dei driver che gestisce l’ora e il calendario del lettore, una sorta di “millenium bug” (sul web non si fa altro che parlare di “Zunebug“). Sarebbe stato, dunque, quel giorno in più, il 366esimo dell’anno, a congelare le funzionalità dell’antagonista più celebre dell’iPod.

Ecco un video che mostra cosa è accaduto allo Zune il 31 Dicembre 2008:

In realtà, la prima, e sinora unica, soluzione consigliata caldamente dalla Microsoft, è stata unica per tutti gli utenti che si sono ritrovati spiazzati di fronte a questa affermazione: non fare nulla e lasciare passare la notte!. Microsoft ha assicurato, infatti, che in sole 24 ore, e precisamente con l’allineamento del driver con il nuovo anno, gli utenti colpiti dalla falla potranno rientrare in possesso della loro musica!
Infatti, secondo il team Zune, gli orologi interni dei lettori si sarebbero dovuti resettare automaticamente entro il 1 Gennaio 2009. Quindi, per rientrare in possesso della propria musica, gli utenti dovranno far scaricare completamente la batteria degli apparecchi, farli riavviare e poi caricarli nuovamente. Gli iscritti allo Zune Pass, il software che consente l’acquisto di musica online, dovranno sincronizzare nuovamente gli apparecchi con i proprio computer per poter aggiornare i diritti del materiale scaricato.

Alla ricerca del bug nel codice sorgente

La soluzione proposta ha lasciato tutti alquanto perplessi in quanto non risolve definitivamente il problema e molti si sono chiesti: “You’re probably wondering, what kind of bug fixes itself?“. Secondo Microsoft, infatti, è necessario attendere che la batteria si scarichi per poi ricaricarla e infine riaccendere lo Zune. Non esisterebbe un altro modo per azzerare la memoria interna dell’apparecchio e scavalcare il bug che causa il blocco e che, in assenza di futuri aggiornamenti software, si ripresenterà puntualmente a mezzanotte del 30 dlcembre 2012.

C’è anche chi è voluto andare più a fondo al problema, ed è riuscito a reperire il codice sorgente del driver del clock dello Zune (disponibile liberamente sul sito del processore Freescale).

In pratica, la data sullo Zune, come su molti dispositivi e computer, viene memorizzata in termini di giorni e di secondi a partire dal 1° Gennaio 1980. Lo scopo del driver del clock è quello di convertire, quando richiesto (e la prima volta avviene dopo la prima sequenza di boot), il numero di giorni nel formato anno/mese/giorno e il numero di secondi in ore/minuti/secondi. Viceversa, quando il clock deve settare l’ora e la data, avviene l’opposto.
Questo è un frammento del codice coinvolto nel bug:

<br /> year = ORIGINYEAR; /* = 1980 */</p> <p>while (days > 365)<br /> {<br /> if (IsLeapYear(year))<br /> {<br /> if (days > 366)<br /> {<br /> days -= 366;<br /> year += 1;<br /> }<br /> }<br /> else<br /> {<br /> days -= 365;<br /> year += 1;<br /> }<br /> }<br />

Come vedete, questa parte di codice, in circostanze normali, funziona egregiamente: la funzione sottrae 365 o 366 finché non si raggiunge l’anno corrente. Il problema si presenta l’ultimo giorno dell’anno bisestile, con 366 giorni, perché la funzione “if (days > 366)” attenderà prima di sottrarre 366 giorni ed entrerà in un loop che si sbloccherà solo il giorno seguente, quando l’anno non sarà più bisestile, dopo 24 ore di ciclo iterativo senza fine!

Qui, si propone una possibile soluzione, peraltro molto semplice:

<br /> while ((days > 365) && (!IsLeapYear(year))) ||<br /> (days > 366))<br /> {<br /> if (IsLeapYear(year))<br /> {<br /> if (days > 366)<br /> {<br /> days -= 366;<br /> year += 1;<br /> }<br /> }<br /> else<br /> {<br /> days -= 365;<br /> year += 1;<br /> }<br /> }<br />

Considerazioni

Purtroppo, per ora Microsoft ha dichiarato che non distribuirà alcuna patch per fixare il problema del driver che gestisce il clock dello Zune e quindi, fra altri 4 anni, a meno di ripensamenti da parte del produttore, si potrà presentare nuovamente il problema, sempre che i proprietari di questo dispositivi non siano passati ad un altro lettore multimediale immune al bug dell’anno bisestile! Si stima che, circa 1 milioni di possessori del primo modello da 30 Gigabyte sui tre milioni venduti in tutto negli Usa, hanno smesso di funzionare.

Secondo un analista, Matt Rosoff, dell’azienda di ricerca dedicata ai prodotti e alla performance della casa di Redmond, cioè “Directions on Microsoft”, “non si era mai sentito parlare in tutta la storia dell’informatica di un apparecchio per l’elettronica di massa che avesse un problema così radiacle su così ampia scala”.

Forse, a questo punto, si potrà comprendere come mai solo una piccola parte delle entrate della Microsoft provengono dalla vendita di apparecchi musicali (con appena il 3% del mercato in cui Apple la fa da padrona con gli iPod con un 70% di presenza, seguita da SanDisk, con la sua serie di lettori Sansa, con un rispettabile 10%). E pensare che il dispositivo Zune, da 30 GB, era stato messo sul mercato (forse troppo precipitosamente da non effettuare sufficienti debug) a Novembre 2006 proprio per contrastare la posizione dominante di Apple Inc sul mercato dei dispositivi portatili per l’ascolto di musica! Con questi presupposti e comportamenti, la sfida contro Apple sembra persa in partenza!

Pensavo di aver visto davvero tutto sulle differenze tra il mondo Windows e quello Mac e sugli incidenti che possono accadere se si prendono troppo alla leggera alcune situazioni e incompatibilità che a prima vista possono sembrare banali. Ma, purtroppo, non era così poiché ieri sera penso di essermi imbattuto in una anomalia davvero particolare. In pratica se si copiavano via rete dei singoli file tra Mac OS X Leopard e una cartella condivisa su Windows XP con partizione NTFS, questi a fine trasferimento venivano cancellati, mentre rimanevano se si copiava una cartella con gli stessi file.

Ma ecco nel dettaglio cosa mi è capitato.

Gli eventi

Avevo deciso di spostare via rete Wi-Fi alcun file dal mio Macbook Pro con Mac OS X 10.5.2 Leopard formattato HFS+ su un PC con Windows XP formattato NTFS. Per l’occasione avevo condiviso una cartella sul mio PC e gli avevo assegnato anche i diritti di scrittura. Premesso che sul mio Macbook Pro non ho installato Paragon o MacFuse per ottenere il supporto per altri file system oltre a quelli standard di Mac OS X, tra cui anche NTFS, non avevo pensato minimamente che forse questa operazione non si potesse fare, dato che nativamente Mac OS X non permette la scrittura sulle partizioni NTFS, a meno che non si voglia scrivere su un PC in rete con Samba (che sarebbe l’unico modo per scrivere su NTFS senza installare software di terze parti).

Ammetto di essere stato sovrappensiero ma anche il sistema non mi ha dato una mano. Ingenuamente ho preso un file di oltre 1 GB e l’ho spostato dal mio Macbook al PC condiviso. Ebbene, l’operazione è durata 4 minuti e nel mentre controllavo che sul PC il file venisse copiato correttamente… e così sembrava accadere: ad ogni refresh della finestre di Gestione Risorse il valore in Kilobyte aumentava col tempo. Purtroppo, con mia grande amarezza, a trasferimento ultimato, ho scoperto che sulla cartella condivisa del mio PC il file era stato cancellato e, avendo spostato il file, invece che copiato, avevo perso anche l’originale sul mio Mac! Inizialmente non ho pensato al problema del partizionamento NTFS, e supponevo che, avendo eseguito un collegamento vi wi-fi, forse c’era stato qualche problema di rete, e quindi ho ritentato il trasferimento di un altro file, avendo cura, questa volta, di fare una semplice copia. Ebbene, lo stesso infausto evento si è ripetuto!

I miei errori

Ovviamente i miei errori sono stati dettati dalla fretta e sono stati principalmente due:

1. Mai spostare un file su una cartella remota, ma farne semplicemente prima una copia e poi, dopo aver verificato l’integrità del file trasferito, cancellare l’originale
2. Non è possibile scrivere nativamente su una partizione NTFS con Mac OS X, sia se presente su una partizione di un hard disk fisicamente collegato al Mac (attraverso un hard disk portatile via USB o partizionando, magari, il proprio disco fisso interno), sia, a questo punto, se condiviso via rete

Analisi del comportamento anomalo di Leopard

Quello che mi ha tratto in inganno, però, è stato principalmente il fatto che Leopard non mi ha segnalato in alcun modo che la partizione era NTFS e, quindi, non era scrivibile dal sistema operativo di Cupertino, come quando normalmente accade se provo a copiare un file su un disco esterno NTFS. Probabilmente il problema risiede nel fatto che, avendo assegnato i diritti di scrittura alla cartella remota, forse Leopard non si è degnato di controllare se era fisicamente possibile scriverci sopra. Oppure può essere che nel protocollo di comunicazione Samba che usa Mac OS X 10.5 Leopard , non esiste un flag o una notifica che mi segnala su che tipo di file system vado a scrivere!

In realtà, però il trasferimento da Mac su PC NTFS sembrava comunque procedere regolarmente perché Mac OS X riusciva a scrivere il file sulla directory remota, anche se forse era corrotto sin dall’inizio. Almeno era quello che pensavo. Siccome, però, sono curioso per natura, ho fatto diverse prove prima di buttare giù questo articolo e ho quindi potuto appurare di una cosa davvero anomala. Ho copiato immagini ISO e DMG, file AVI grandi e piccoli, immagini JPG e piccoli file TXT e PDF. Tutti quanti i file, quando venivano spostati singolarmente, a trasferimento avvenuto, venivano inesorabilmente rimossi. In pochissimi casi, però, se copiavo due file in contemporanea, il primo che terminava veniva preservato sulla directory remota mentre l’ultimo veniva inesorabilmente cancellato!

Una inaspettata scoperta: le directory non si cancellano

E per finire, ecco che casualmente faccio una interessante scoperta: prendo tutti i file e li raggruppo tutti in una cartella e, questa volta, sposto solo la cartella: ebbene, questa volte, i file vengono tutti mantenuti! Da buon galileano, ripeto più volte l’esperimento che, regolarmente, si riproduceva!

Considerazioni finali

Non so se questo problema è da imputarsi a Mac OS X (magari solo a Samba) o a Windows XP ma sta di fatto che, l’unico modo per copiare dei file via rete tra un Mac OS X e Windows, era trasferirli da dentro una directory!

Purtroppo non ho partizioni FAT32 sul mio PC, per cui non ho potuto verificare se il problema si presentava anche con questo tipo di formattazione (anche se dubito fortemente). Comunque, lo scopo di questo mio articolo era semplicemente lanciare un monito a tutti i Macusers e segnalare questa presunta anomalia. Io credo, comunque, che questo sia indice di una non perfetta compatibilità tra Samba su Mac OS X e NTFS. Lo si capisce chiaramente quando si lanciano, a distanza di pochi secondi, due trasferimenti di rete, e il primo che termina, a volte, ma non sempre, viene mantenuto (come se, Mac OS, essendo impegnato in una altra copia, non avesse avuto il tempo di eliminare il file remoto): il bello è che se si ripete 10 volte la prova non si avrà mai un risultato univoco!

Io non credo che questa serie sfortunata di eventi sia prerogativa della mia rete casalinga o di una qualche sparticolare configurazione sul mio Mac. E’ per questo che vi chiedo: a voi è mai capitato qualcosa di simile? Cosa credere sia da imputare questo strano comportamento? Questa anomalia è riproducibile anche sui vostri sistemi?

Ogni computer possiede internamente dei sistemi software per generare numeri pseudocasuali, che sono una parte critica della moderna scienza computazionale, in particolare per la crittografia usata per cifrare file, messaggi di posta elettronica e per l’utilizzo del protocollo SSL (alla base dei sistemi di commercio elettronico su internet) e per la generazione delle password.
Si definiscono pseudocasuali perché la generazione di numeri realmente casuali, non è possibile nella realtà in quanto per generare un numero casuale significa che prima di essere generato, tutti gli elementi di un certo insieme siano egualmente probabili come risultato, cosa che dal punto di vista software ancora non è mai stato realizzato. E’ per questo che si parla di generatore di numeri pseudocasuali (PRNG, dall’inglese Pseudo Random Number Generator), ovvero di algoritmi in grado di generare una successione di numeri, i cui elementi sono approssimativamente indipendenti l’uno dall’altro.

Nonostante questo problema sia noto, fino ad oggi i numeri pseudocasuali, hanno sempre avuto una imprevedibilità sufficiente per l’attività normale. Se così non fosse stato, ciò avrebbe minato tutti gli algoritmi di crittografia, SSL (Secure Socket Layer) in primis, che per funzionare hanno bisogno di un generatore di numeri pseudocasuali. Se questi numeri non sono abbastanza casuali ma possono essere in qualche modo previsti o interpretati, il funzionamento della crittografia è minato dall’interno.

Ed è quello che hanno scoperto, due ricercatori e studenti universitari israeliani, Benny Pinkas e Zvi Gutterman, che sono arrivati alla conclusione che il generatore di Windows 2000 e di Windows XP ha una falla, che crea rischi per la sicurezza. I ricercatori hanno svolto un’azione di “reverse-engineering” sull’algoritmo utilizzato da Windows 2000 per la generazione di numeri pseudo-casuali (PRNG), utilizzati dal sistema operativo per crittografare file e cartelle.

Forzando l’algoritmo PRNG, i due israeliani sostengono di essere riusciti nel predire le chiavi future e quelle create in passato. All’attaccante è sufficiente conoscere il valore di alcune aree di memoria (in user space, tra l’altro) per forzare la vostra comunicazione criptata. Questo vale ovviamente anche per le transazioni fatte con HTTPS con le carte di credito, ma anche agli istituti bancari e altri enti che trattano dati sensibili.

Messa alle strette Microsoft ha ammesso l’esistenza di questa falla sui suoi sistemi Windows e ha promesso che verrà chiusa, solo su Windows XP, con il Service Pack 3, annunciato da Microsoft per il primo semestre del 2008. Su Windows 2000, però, non è prevista alcuna patch questo perché Microsoft si rifiuta di riconoscere questo falla come bug che affligge la sicurezza.

Infatti, sebbene, per poter andare a buon fine, la tipologia d’attacco descritta dai due israeliani sia piuttosto complessa, Microsoft, comunque, continua a ridimensionare la pericolosità del problema recentemente messo a nudo: infatti in tutti i casi descritti, le informazioni sono visibili (e l’attacco nei confronti dell’algoritmo PRNG può avere successo) solo da parte degli utenti autorizzati o di altri utenti collegati al sistema locale con diritti amministrativi; poiché gli amministratori, per definizione, possono accedere a tutti i file ed a tutte le risorse disponibili sul sistema, ciò non rappresenta un problema. Questa condizione, quindi, limiterebbe fortemente la pericolosità del bug anche se un aggiornamento dedicato è assolutamente desiderabile.

Il problema è che se un aggressore riesce a prendere possesso di una macchina come amministratore, sfruttando, per esempio, altre falle di sicurezza non adeguatamente “patchate” (cosa che nel mondo Microsoft accade molto spesso), l’attacco nei confronti dell’algoritmo PRNG può avere successo!

Symantec, da parte sua, assume una posizione intermedia e ha bollato i rischi descritti dai due israeliani come “moderatamente elevati”. Un aggressore, infatti, dovrebbe prima riuscire a guadagnare l’accesso sulla macchina oggetto d’attacco. Successivamente il malintenzionato deve effettuare tutta una serie di attività per riuscire a guadagnare le chiavi generate sul sistema. “Uno scenario alquanto complicato“, ha concluso l’esperto di Symantec ammettendo tuttavia che la nascita di tool automatizzati potrebbe rappresentare un grave problema snellendo di fatto la procedura d’attacco.

Quindi, se le cose resteranno così, è molto probabile che Windows 2000, che è ancora in funzione sul 9 percento dei computer professionali in Europa e Stati Uniti (e per il quale Microsoft sta abbandonando il supporto), non avrà mai risolto questo bug, nonostante siano previsti eventuali aggiornamenti di sicurezza. Infatti, allo stato attuale delle cose, questo sistema operativo si trova infatti nella fase di “extended support“. Ciò significa che Microsoft rilascerà solo gli aggiornamenti di sicurezza considerati come critici mentre chi desidera usufruire degli altri aggiornamenti deve iscriversi ad un programma a pagamento (il cosiddetto “extended support”).

Per quanto riguarda invece Windows Vista, Windows Server 2003 e il non ancora rilasciato Windows Server 2008, sembra che questi sistemi operativi non soffrano del problema, perché impiegherebbero invece una versione modificata dell’algoritmo.

Ieri sera mi ha chiamato Davide un po’ perplesso perché, mentre sistemava i suoi file, si era trovato a dover spostare una directory con il nome “Installazioni” presente sul disco del suo portatile, verso il percorso di un disco esterno dove risiedeva una directory con lo stesso nome “Installazioni” (e in cui risiedevano diversi gigabyte di file). Ebbene, forte della sua decennale esperienza su Windows non ha lontanamente pensato che questo evento potesse essere catastrofico. E così è stato perché dopo aver spostato la cartella sul disco esterno, si è ritrovato la cartella Installazioni completamente svuotata dal suo precedente contenuto (diversi gigabyte di dati, ve lo ricordo) e si è trovato solo quei pochi file che aveva spostato.

Insomma sarà un comportamento normale su un qualunque sistema Unix che usa il comando ‘mv’, ma per tutti i nuovi mac-user che provengono dal mondo Windows, questo comportamento è assolutamente imprevedibile. La soluzione più semplice è quella di entrare nella cartella e fare il drag-and-drop del contenuto: in questo caso il comportamento è identico che in altri sistemi operativi. Ma ora mi chiedo: quanti di voi erano a conoscenza di questo strano comportamento del Mac?

Nella speranza di evitare che qualcun altro commetta lo stesso errore ho deciso, quindi, di segnalare questo presunto bug poiché io, francamente, non ne ero a conoscenza e per farlo ho sperimentato lo spostamento di una directory su Mac OS X 10.5 Leopard e su Windows XP che e ho qui di seguito documentato.

Phoenix di Vite Digitali, mi segnala per mail una vulnerabilità che permette attacchi di tipo XSS (cross-site scripting) riscontrata in tutte le versioni del tema Unnamed One (installato anche sul mio sito).
Infatti, analizzando il codice del tema, si vede che nel file theloop.php è presente la seguente riga di codice:

<br /> printf(__(‘ Risultati della ricerca per \’%s\”, ‘unnamed’), $s);<br />

Questo fa si che se si scrive uno script (per esempio in javascript) nella barra delle ricerche, lo script non verrà bloccato ma verrà eseguito; infatti lo script verrà assegnato alla variabile s e quindi visualizzato nel blog mediante la funzione printf. Non essendo presenti dei controlli sul contenuto della variabile, lo script verrà inserito nella pagina html senza essere filtrato e quindi inevitabilmente, verrà eseguito.

Tale vulnerabilità permette di eseguire qualsiasi codice immesso nella barra delle ricerche e, quindi, permette svariate tipologie di attacco: phishing, cookie grabbing (rubare i cookie dalla macchina che accede al blog con tema Blix), visualizzazione di contenuti testuali e multimediali temporanei nella pagina del blog, ridirezionamento verso un’altra pagina, ecc…

L’autore del tema Unnamed One (ma il bug è stato rilevato anche nel tema Blue Memories, realizzato sempre dallo stesso autore) è stato contattato ed ha subito provveduto a correggere il codice nei temi.

Per chi non volesse riscaricare i temi, è possibile modificare la riga sopra indicata del file theloop.php nella seguente:

<br /> printf(__(‘Risultati della ricerca per \’%s\”,’unnamed’), attribute_escape(stripslashes(get_query_var(‘s’))));<br />

In effetti, a conferma delle veridicità delle affermazioni di Phoenix ho verificato il codice del tema Unnamed One 1.x presente ora sulla homepage dell’autore con quella che avevo installato io ed effettivamente erano state apportate le modifiche suggerite da Phoenix, che non posso non ringraziare per il lavoro svolto e per la puntuale segnalazione via email.

Ieri ho scoperto una malfunzione della funzionalità di Search di WordPress 2.x se abbinato con il plugin Ultimate Tag Warrior: sembra infatti che la ricerca mostra nei risultati solo quei post che hanno associato almeno un tag.

Da qualche giorno, dovendo cercare riferimenti a vecchi articoli, notavo che il form di ricerca presente sul mio sito non funzionava correttamente: per esempio cercando le parole tipo “Dosbox” non trovavo alcun riferimento mentre se cercavo “Gmail” trovavo solo 5 post e l’ultimo risaliva al 2006 (cosa molto strana dato che ho scritto molti altri articoli antecendenti il 2006).
Se però, la stessa ricerca la effettuavo su Google (con una stringa tipo “Dosbox levysoft”) ottenevo subito il link all’articolo desiderato. Va bene che Google è il migliore motore di ricerca in circolazione, ma una funzione di ricerca su WordPress non è molto difficile se si dispone di un bel database indicizzato.
All’inizio pensavo che il problema risiedesse nel template che avevo installato, ma un’occhiata al codice ha subito smentito l’ipotesi, dato che la chiamata alla funzione di ricerca corrispondeva a quella presente nel tema di default di WordPress. Una ulteriore conferma al fatto che fosse un problema generale era che il problema si verificava anche quando, collegandomi con Admin, eseguivo la stessa query dall’area di “Gestione Articoli”.

Dopo qualche tentativo (per fare qualche verifica ho chiamato a consulto anche Davide) ho intuito che la funzione di ricerca eseguiva la query solo per i post più recenti, escludendo quelli più vecchi. Cercando parole presenti in articoli del 2004 o del 2005 la ricerca dava esito negativo.

A questo punto ho iniziato a dare un’occhiata al codice php di WordPress alla ricerca di qualche anomalia nell’esecuzione della query: da un LIMIT male impostato ad una condizione WHERE poco precisa (sospettavo un limite temporale della condizione di ricerca). Ho aperto, quindi, il file wp-includes/query.php e cercando le parole chiave “search” e “where” ho trovato i punti in cui si creava la sintassi della query. Ma tutto sembrava corretto.

Ho così deciso di chiedere informazioni sul forum di supporto di WordPress.org, ma prima ho deciso di fare una ricerca per vedere se il problema si era già ripresentato: con la semplice chiava “search old post” ho trovato la soluzione ai miei problemi.
Qui, infatti, qualcuno ha lo stesso mio problema evidenziando il fatto che aggiornando WordPress dalla release 2.0.6 alla 2.1 la ricerca su vecchi post non funzionava affatto.

Alla fine ecco la soluzione: il problema, segnalato anche sul forum del plugin in questione , risiedeva nell’attivazione del plugin “Ultimate tag warrior” (io ho anche l’ultima release 3.14159265) con WordPress 2.07 o 2.1: sembra infatti che la ricerca mostra nei risultati solo quei post che hanno i tag.
Nel mio caso, siccome, i post più vecchi non hanno i tag, venivano automaticamente esclusi dalla ricerca.
Per sicurezza ho fatto anche una prova: ho preso una parola presente solo in un vecchio post senza tag e ho fatto la ricerca: nessun risultato! Ho poi aggiunto i tag a quell’articolo e dopodicché la ricerca ha dato esito positivo!
Certo che era difficile immaginare una correlazione tra un bug del plugin dei tag con la ricerca di WordPress, anche se in effetti la ricerca per tag è strettamente correlata alla normale ricerca.

Attualmente, però, nonostante il problema sia noto, non è stato rilasciata alcuna nuova release che risolva il problema, ma se non si vogliono disattivare i tag (disattivando definitivamente il plugin Ultimate Tag Warrior) sul proprio sito o non si vuole inserire a mano/automaticamente i tag su tutti gli articoli (infatti se i tag sono presenti su tutti i post la ricerca viene effettuata correttamente) ma comunque non si vuole convivere con questo problema (inserendo magari il funzionale modulo di ricerca di Google), è disponibile un work around per chi è capace a mettere mano al codice php.

E’ sufficiente aprire il file ultimate-tag-warrior-actions.php e commentare le seguenti due righe:

//add_filter('posts_join', array('UltimateTagWarriorActions','ultimate_search_join'));
//add_filter('posts_where', array('UltimateTagWarriorActions','ultimate_search_where'));

Questa soluzione non è definitiva perché, per risolvere il problema si deve disattivare la ricerca dei tag: pare infatti che il problema risieda in una JOIN della query.
Ora sta a voi decidere se, in attesa di una patch ufficiale, è più utile privarsi della ricerca nei tag oppure avere una ricerca generica di WordPress limitata ai soli post con i tag (certo che se poi avete tutti gli articoli con i tag assegnati, il problema per voi non sussiste!).

UPDATE: Grazie a Javano, abbiamo finalmente la soluzione al problema: e lo ha risolto in un modo semplicissimo.
Basta andare nel file ‘ultimate-tag-warrior-actions.php‘ del plugin e nel metodo ‘ultimate_search_join‘ modificare il secondo join da una INNER JOIN in una LEFT JOIN, la ricerca continuerà a funzionare anche per i post ai quali non è associato alcun TAG.

Codice del plugin:

$join .= " LEFT JOIN $tablepost2tag p2t on $wpdb->posts.ID = p2t.post_id INNER JOIN $tabletags on p2t.tag_id = $tabletags.tag_id ";

Codice rimodificato:

$join .= " LEFT JOIN $tablepost2tag p2t on $wpdb->posts.ID = p2t.post_id LEFT JOIN $tabletags on p2t.tag_id = $tabletags.tag_id ";

Molti definiscono Windows Vista un sistema operativo rivoluzionario, innovativo e sicuro. Ma siamo sicuro che costituisca il passo obbligato per chiunque voglia upgradare il proprio PC? E’ stato realizzato veramente con cura, nonostante 5 lunghi anni di beta testing?
Purtroppo non è tutto oro quello che luccica.

1. LE VERSIONI CONTRASTANTI DI VISTA
2. ICONE NASCOSTE VISIBILI SUL DESKTOP
3. L’INDICE DELLE PRESTAZIONI E’ INUTILE
4. LA MANIA DEL CONTROLLO DELLA FIRMA OBBLIGATORIA
5. STATO DELLA RETE POCO ACCESSIBILE
6. CHIUSURA NASCOSTA: L’ICONA SPEGNI NON SPEGNE IL PC

Aspettavo la release successiva alla 2.1 per fare il gran passo, nella speranza che vulnerabilit� e bug di quest’ultima, inevitabili in qualsiasi major release, fossero risolti. All’annuncio dell’uscita della release 2.1.1 di WordPress, mi sono quindi affrettato ad installarla; fin’ora non ho trovato alcun problema grave ed ho solo riscontrato la presenza di un vecchio bug della bacheca della release 2.1 segnalato anche su pseudotecnico, per cui se avete più di 1000 articoli o 1000 commenti (nel mio caso ho fatto bingo, avendo 1.152 articoli e 2.455 commenti), nella bacheca del vostro Pannello di Amministrazione avrete un errore simile al seguente:

Parse error: syntax error, unexpected ‘,’
in /wp-includes/gettext.php(313) :
eval()’d code on line 1

Si pensava che il bug fosse stato risolto nella release 2.1.1 ma in realt� è ancora presente. Infatti, nella lista dei file modificati, non è presente il file wp-admin/index.php, che risulta essere il diretto responsabile del problema.
La soluzione è semplice e consiste nel modificare il file wp-admin/index.php utilizzando questo diff; per i più pigri è possibile scaricare un file index.php gi� modificato da pseudotecnico (rinominare il file indexphp.txt in index.php).

Per il resto continuo a prediligere l’editor a codice: quello visuale mi da un certo fastidio, visto che comunque non offre una anteprima realistica del formato del post come appare nel proprio template, il che, secondo me, è una pecca bella grave. Bisognerebbe integrare l’editor visuale con il tema, in modo da usare lo stesso foglio di stile.

UPDATE: Il bug della bacheca persiste ancora nella release 2.1.2 e 2.1.3 di WordPress: quando si decideranno a risolverlo?

UPDATE 2: Con la release di WordPress 2.2.1 finalmente il bug � stato risolto!