jump to navigation

Linux Myth #3: code verification, bug fixing and code reuse March 15, 2006

Posted by laspinanelfianco in Linux.
trackback

Da un punto di vista teorico, la disponibilità dei sorgenti di Linux e del software open source dovrebbe consentire le seguenti tre importantissime azioni.

  1. Verificare che il codice non faccia cose spiacevoli
  2. Correggere velocemente eventuali errori o problemi
  3. Riutilizzare il codice

Ma tutto questo avviene veramente?

Si e no.

I realtà, i programmatori e gli utenti non passano il loro tempo a rileggere il codice scritto da altri. Questa è una preoccupazione che affligge solo alcuni team leader di ogni progetto e qualche studente interessato a studiare qualche programma reale.

L’unico sistema operativo che viene effettivamente “passato al setaccio” in questo modo è OpenBSD, non Linux. Nessun programma applicativo conosciuto subisce quest’opera sistematica di revisione (auditing). Nemmeno OpenOffice o Mozilla Firefox.

I bug, quando vengono scoperti, vengono scoperti perchè qualcuno ci sbatte il naso. Cioè vengono scoperti per caso. Più utenti ci sono, prima vengono scoperti. Più usi diversi vengono fatti di un programma, più bug vengono scoperti.

In ogni caso, per correggere i bug ci vogliono programmatori competenti (in pratica, solo chi ha scritto il programma è in grado di correggerlo) e tempo. Tantissimo, maledettissimo tempo.

Questo è il motivo per cui, anche su Linux, i bug continuano ad esistere e vengono sempre corretti molto tempo dopo che sono stati scoperti. Nel mondo FLOSS (Free and Libre Open Source Software), la situazione è migliore di quanto avviene nel mondo commerciale, ma non è certo esente da critiche e lamentele più che giustificate.

Si tenga presente che le software house commerciali non dormono sui bug. Molte delle aziende per cui ho lavorato avevano banchi di “tester” che mettevano alla prova, 24 su 24 e 7 giorni su 7, il software alla ricerca di bug, sia con strumenti automatici che a mano. I programmatori venivano quasi costretti a risolvere i bug più importanti. Se volete avere un’idea di come venga sviluppato il codice commerciale, provate a leggere “Showstopper! The breakneck race to create windows NT and the next generation at microsoft” (vedi: http://www.amazon.com/ oppure la versione italiana qui: http://www.bol.it/libri/scheda/ea978887750390.html ).

Anche cercare eventuali backdoor ed eventuali spyware nel software esistente non è semplice come potrebbe sembrare. Se vi trovaste in mano un programma formato da, diciamo, 600 diversi file di codice C, da dove comincereste a cercare una backdoor? Come la cerchereste? Probabilmente vi mettereste a cercare alcune parole chiave nel sorgente, ad esempio le chiamate a certe syscall che servono ad aprire una comunicazione su un socket TCP/IP. Forse vi mettereste ad esaminare il flusso di dati da e verso questa applicazione. In ogni caso, avreste bisogno di tempo, strumentazione e competenze. Chi pagherebbe tutto questo? Potete permettervi di farlo, gratis, per tutto il codice che usate, allo stesso ritmo con cui appaiono le nuove versioni?

Sono sicuro che capite che questo non è possibile.

Quando viene trovata una backdoor, è per caso, come per i bug. Potrebbero essercene altre 10.000 senza che nessuno se ne sia ancora accorto.

Riutilizzare il codice sorgente, infine, è una pratica molto, molto rara. L’unico caso in cui si verifica un riuso del software è quello delle librerie C e C++ (o scritte in altri linguaggi) o dei componenti (D/COM, .NET e Mono). In questo caso, tuttavia, sarebbe più corretto parlare di “adozione” o di “incapsulazione” della libreria o del componente, intesi come “scatole chiuse”, perchè il codice sorgente, come tale, solitamente non viene nè letto, nè controllato nè modificato. Si riusa direttamente il prodotto della compilazione, direttamente nel suo formato binario. Per riutilizzare il codice in questo modo, infatti, non c’è bisogno di avere i sorgenti, tanto è vero che molte librerie commerciali non li mettono a disposizione (MFC e .NET, per fare un esempio).

Sono molto, molto rari i casi in cui un programmatore si mette a trafficare con i sorgenti scritti da qualcun’altro. Il tempo e la fatica necessari per padroneggiare un sorgente sconosciuto possono essere proibitivi e spesso si fa prima a riscrivere ciò che serve da zero.

Se decidete di usare Linux, o qualunque altro programma FLOSS, perchè pensate che il suo codice sia stato controllato e collaudato da altri, e che quindi sia più sicuro e più affidabile, tenete presente questi aspetti. Anche se tecnicamente tutto questo è possibile, non è affatto detto che avvenga nella realtà.
Se state cercando un sistema operativo “verificato a livello dei sorgenti”, rivolgete la vostra attenzione a OpenBSD, non a Linux. In ogni caso, sappiate che anche in un sorgente verificato a tappeto è normale trovare dei bug superstiti e persino delle backdoor.

Comments»

1. vuoi il mio nome? - March 16, 2006

e come ti spieghi che il sistema l’OSS vada avanti??
e come ti spieghi che sia sempre più usato in missioni critiche??

vabbè come al solito hai detto tutto e nulla…

>

porta dei dati, statistiche, esempi
dai che ce la puoi fare, è la prima differenza tra a chiacchera da bar ed il “giornalismo” se mai esiste ancora ‘sta parola

perlomeno finisci l’articolo con la parola:

ecco!

sarai più credibile

2. monossido - March 17, 2006

quoto “vuoi il mio nome”

3. dieEasy - March 20, 2006

concordo praticamente in toto con i concetti esposti, solo mi trovo a riflettere su un paio di punti:

1) non sono convinto che software house come piccolissimoemorbido passino la vita sui bug; intendo che chiaramente spendono diverso tempo sui problemi, ma credo siano tutti i bug che impedirebbero la commercializzazione del software, non quelli segnalati dagli utenti o comunque non critici (secondo loro, vedi falla WMF)

2) sono convinto anche io che i bug vengano per lo più scoperti per caso, attraverso l’utilizzo quotidiano del software ed è per questo che utilizzo Debian “stable”, perché so che prima di essere “stable” un pacchetto .deb è passato per le mani di moltissimi utenti e ne è stato fatto un utilizzo molto divetrsificato; a ogni modo secondo me un punto che non hai considerato è il feedback: già il fatto che più utenti utilizzano un software più è alta la probabilità che un bug venga scoperto, ma solo se questi possono mandare una segnalazione dei bug scoperti ai manutentori del software esiste il miglioramento e io dubito (visti i risultati oggettivi) che piccolissimoemorbido legga i bug-report

4. pj - March 28, 2006

Debian si impegna a correggere i bug di sicurezza nel più breve tempo possibile.
Microsoft ad esempio ha lasciato passare “troppo” tempo quando si trattava di fixare la falla dei wmf, e, se non erro, un tizio ha rilasciato una patch prima.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: