Tapiro d'oro Maggio 2008

La legge di Linus recita che given enough eyeballs, all bugs are shallow.

Il corollario di Paperino aggiunge che se gli eyeballs non sono correttamente "addestrati" a riconoscere certi peccati il numero è semplicemente irrilevante.

E così succede che un baco come questo possa resistere tranquillamente un paio d'anni: in poche parole è stata maldestramente e accidentalmente rimossa tutta l'entropia dal generatore di numeri casuali in tutti i sistemi operativi derivati da Debian Etch in poi. I risultati sono disastrosi:

The result of this is that for the last two years (from Debian’s “Etch” release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys. (fonte)

A questo punto mi vengono in mente i dietrologhi sedicenti esperti che affermano quanto sia nociva qualsiasi forma di crittografia made in Redmond e che hanno gridato «allo scandalo!» «alla backdoor!» solo pochi giorni fa. Concludendo laconicamente: Just one more reason not to run Windows on your computer.

Oh yeah!

Technorati Tags:

Potrebbero interessarti anche:
Commenti (30):
1. gino
mercoledì 14 maggio 2008 alle 2:21 PM - unknown unknown unknown
   

più che pigliare per il didietro il team di debian(quanti bugs GIGANTESCHI hanno lasciati aperti per anni i tuoi colleghi?) guarda la velocità dalla scoperta della falla agli aggiornamenti rilasciati in debian e derivate...

   
2. vik
mercoledì 14 maggio 2008 alle 3:19 PM - unknown unknown unknown
   

@gino

Sei poco sportivo, gino!

@Paperino

Posso aggiungere Oh my God!?

   
3. gino
mercoledì 14 maggio 2008 alle 3:28 PM - unknown unknown unknown
   

perchè poco sportivo? sono solo realista

   
4. Scrooge McDuck
mercoledì 14 maggio 2008 alle 4:19 PM - unknown unknown unknown
   

@gino

Ma che stai dicendo?

Il bug in questione dipende dal fatto che i geni della debian hanno commentato una parte del codice senza evidentemente interrogarsi sulle conseguenze.

http://www.links.org/?p=327

Leggi bene, alla fine ci sono anche i link ai diff.

Sfido che l'hanno risolto subito, è bastato levare i commenti...

Se poi per te questa è una prova dell'efficienza dell'open source non so che dirti.

   
5. gino
mercoledì 14 maggio 2008 alle 4:23 PM - unknown unknown unknown
   

è una prova che quelli di debian:

1 sono umani e sbagliano

2 se si accorgono di un bug di sicurezza lo risolvono in poco tempo

niente altro

   
6. Scrooge McDuck
mercoledì 14 maggio 2008 alle 5:27 PM - unknown unknown unknown
   

E' una prova che quelli di debian:

1 sono dei polli perché dopo aver tolto una linea di codice non ne hanno discusso con quelli di OpenSSL per risolvere un problema, e il grave non sta nel fatto che la soluzione non fosse ottimale ma nel fatto che la soluzione è stata frettolosa, non discussa con chi mantiene il progetto e mai messa in discussione da tutti questi "occhi" che dovrebbero controllare l'opensource.

2 se si accorgono che non dovevano togliere una riga di codice riescono a rimuovere la porcata in poco tempo

In ogni caso non mi pare che ne escano bene.

   
7. Paperino
mercoledì 14 maggio 2008 alle 5:59 PM - unknown unknown unknown
   

Mi permetto di fare qualche ulteriore precisazione/provocazione sperando in "sana" polemica (esiste? In un luogo di perdizione credo di sì).

1. La sicurezza - secondo me - non è questione di bachi; è un approccio che con l'avvento di connessioni veloci, Sasser, Nimda, Codered si è dimostrato fallimentare; domanda: perché? Io ho una mia teoria.

2. La legge di Linus è una stronzata. I cimiteri sono pieni di buone intenzioni: tutti guardano il codice, il codice almeno è lì, è "libero" ecc. Libero anche di "marcire" a quanto pare. In base a quale teoria scientifica la legge di Linus può essere ancora considerata valida?

3. Risolto il problema contingente (il baco) cosa è stato fatto affinché la cosa non si ripeta? Qualcuno si è per caso rivisto tutte le migliaia di righe di codice che riguardano componenti criptografici? Sono stati introdotti nuove misure per impedire che qualche altro "tabaccaio" (*) sistemi altri bachi? Sono domande legittime

(*) tabaccaio = termine affettuoso dato ai "programmatori della domenica" all'interno di una DL "locale"

   
8. Ale
mercoledì 14 maggio 2008 alle 6:49 PM - unknown unknown unknown
   

Sono a secco di inglese...cosa vuol dire esattamente "given enough eyeballs, all bugs are shallow" ?

Il dubbio che anche l'open source potesse nascondere errori simili già mi era venuto. La sicurezza si ha solo a pc spento (ma con spina staccata ;D )

   
9. EnricoG
mercoledì 14 maggio 2008 alle 7:16 PM - unknown unknown unknown
   

@gino,

se sei un troll che vuol fare sembrare i "tifosi" di Debian dei perfetti cialtroni ci stai riuscendo alla perfezione!

@paperino,

il "tabaccaio" mi suona familiare!

   
10. Paperino
mercoledì 14 maggio 2008 alle 9:00 PM - unknown unknown unknown
   

@EnricoG:

non credo che gino sia un troll; credo che certi concetti che possano sembrare ovvi (lo sono davvero poi?) siano comunque altamente discutibili.

Sul "tabaccaio" occorre che scriva un post: fa le sue apparizioni negli esempi della lista piuttosto spesso; come Alice e Bob negli esempi di crittografia, sempre per restare in tema.

@Ale:

la frase di Linus significa che "allo scrutinio attento di tante persone tutti i bachi sono facilmente individuabili". La mia obiezione è che la quantità non conta. Sarebbe bastato un singolo criptologo (?) per individuare la cappella

   
11. Enrico
mercoledì 14 maggio 2008 alle 9:01 PM - unknown unknown unknown
   

@Gino

"quanti bugs GIGANTESCHI hanno lasciati aperti per anni i tuoi colleghi?)"

....

"...è una prova che quelli di debian:

1 sono umani e sbagliano

2 se si accorgono di un bug di sicurezza lo risolvono in poco tempo

niente altro

A parte il resto, hhm...scusa...solo per coerenza perchè il discorso vale per "quelli" di Debian ma non per "quelli" di Microsoft?

Poi, perchè di fronte a cose lampanti come questa persone come te si ostinano a difendere posizioni indifendibili, quasi che ammissioni del genere sarebbero come togliere una carta alla base di un castello di carte, anzichè fare critiche costruttive?

Non si potrebbe, per una volta, una sola, ammettere il problema senza tirare fuori dietrologie del passato?

Per ultimo: non noti che si sta iniziando a controbattere un po' troppo spesso i problemi attuali di alcune piattaforme (Debian in questo caso) con problemi che ormai sono più che altro ricordi del passato di Microsoft?

   
12. gino
mercoledì 14 maggio 2008 alle 11:20 PM - unknown unknown unknown
   

io troll? ahah se volessi trollare andri su punto informatico, almeno lì ci si fanno due sane risate

@enrico

il discorso vale per tutti

paperino ha scritto una presa per i fondelli della gente di debian, bene, la mia era una provocazione costruttiva altrimenti non sarei ancora qui a scrivere non credete?

il discorso vale per tutti:

quelli di debian sono rinomati per controllare e ricontrollare il codice(aka stabilità, e non dite che non è vero)

potranno per caso fare un errore, sono umani no?

quello che a me non va giù è il conoscere i bug e non fare niente per anni, quello sì che è diverso!

   
13. EnricoG
mercoledì 14 maggio 2008 alle 11:30 PM - unknown unknown unknown
   

Facevi piu' bella figura a dire che eri un troll!!!

   
14. Paperino
mercoledì 14 maggio 2008 alle 11:38 PM - unknown unknown unknown
   

@gino:

non è mia intenzione prendere per i fondelli per "il gusto di". Il tapiro lo avrei assegnato a Linus e alla sua teoria sbilenca. Tutti possono sbagliare, l'errore io lo vedo più nella teoria che nel baco stesso. Secondo la teoria il baco semplicemente non potrebbe esistere, meno che mai un fossile di 25 anni fa ( www.scmagazine.com/.../developer-revea ). In 25 anni ci sarà passato almeno qualche milione di occhi sopra o no?

   
15. Shance
mercoledì 14 maggio 2008 alle 11:41 PM - unknown unknown unknown
   

*non sente parlare di Mac*

In questi giorni non hanno per caso sistemato un baco in BSD dopo 25 anni?

it.slashdot.org/.../article.pl

Saranno tabaccai pure loro?

   
16. Paperino
mercoledì 14 maggio 2008 alle 11:59 PM - unknown unknown unknown
   

@paperino:

Urge la definizione di tabaccaio altimenti i monopoli di stato mi tasseranno.

   
17. Shance
giovedì 15 maggio 2008 alle 12:13 AM - unknown unknown unknown
   

[OT]

Mi sono sempre chiesto se i tabaccai facciano le scorte di sigarette per guadagnarci un botto con gli aumenti del tabacco...

   
18. Marco
giovedì 15 maggio 2008 alle 5:38 AM - unknown unknown unknown
   

> La mia obiezione è che la quantità non conta.

> Sarebbe bastato un singolo criptologo (?) per

> individuare la cappella

Non è sufficiente il solo "criptologo". E' necessario anche che il criptologo in questione capiti su quelle linee di codice.

Definiamo "criptologo": persona competente e motivata nella risoluzione di un baco che coinvolge elementi crittografici

Ipotizzando di avere a disposizione n criptologi ed m bachi, e che il tempo di risoluzione degli m bachi diminuisca al crescere di n, bisognerebbe capire quali elementi influenzano n, e se il contesto chiuso o aperto sia o meno determinante.

A me viene da pensare che con il sorgente aperto il numero di criptologi incidentali sia comunque maggiore rispetto ad un contesto chiuso (da qui la legge di Linus). Il problema mi pare però che qui sia un altro: la modifica *non* è stata fatta da un criptologo.

   
19. Blackstorm
giovedì 15 maggio 2008 alle 7:50 AM - unknown unknown unknown
   

@Shance: alla faccia della velocità di correzione...

@Marco:

A me viene da pensare che con il sorgente aperto il numero di criptologi incidentali sia comunque maggiore rispetto ad un contesto chiuso (da qui la legge di Linus).

Ma tu preferisci che il uto pezzo di codice ofsse controllato da 5 crittologi competenti o da 50 appassionati di crittografia di cui solo 1 o 2 competenti?

Il problema mi pare però che qui sia un altro: la modifica *non* è stata fatta da un criptologo.

Ma potrebbe anche essere molto peggio: la modifica potrebbe essere stata fatta da un crittologo (o sedicente tale).

   
20. Shance
giovedì 15 maggio 2008 alle 8:52 AM - unknown unknown unknown
   

Non sono esperto di programmazione, vorrei farvi 2 domandine in merito sul codice aperto e chiuso:

1. Es. Microsoft, codice chiuso. Ci sarà un tizio che decide cosa programmare e dice a n gruppi di fare un qualche cosa. In questi gruppi ci saranno n programmatori che sviluppano il tutto. Poi questo bel pò di codice va unito e fatto funzionare. Dovrebbe essere tutto sotto controllo (dai tizi ai piani alti).

2. Codice aperto. Tutti ci possono lavorare? E una volta che ho lavorato su una cosa e nello stesso momento ci ha lavorato un tizio... che con la sua modifica non mi funziona la mia?

Mi sono sempre chiesto questa cosa...

Però, perchè anche in casi come Microsoft una modifica ad una cosa implica "problemi" ad un'altra? Mi viene in mente il Sp2 di Windows Server 2003 vs. Isa e Sbs.

Attendo illuminazione.

   
21. EnricoG
giovedì 15 maggio 2008 alle 1:58 PM - unknown unknown unknown
   

Shance,

lo sviluppo del software e' una delle attivita' ingegneristiche piu' complesse al mondo, a parte le piramidi, le opere umane col maggior numero di ore uomo di lavoro sono i sistemi operativi (non conto la muraglia cinese che e' di una complessita' decisamente inferiore ;))

I linguaggi di programmazione sono nati pensando a problematiche molto piu' semplici e in tempi nei quali il numero di persone che lavorava ad un progetto era cosi' limitato da poter essere tenuto sotto controllo con una certa facilita'.

Oggi le cose sono completamente cambiate, ma gli strumenti a disposizione sono ancora piuttosto grezzi.

Pensa ad esempio cosa si deve fare se si vuole cambiare il nome di una funzione.

Un linguaggio/ambiente di sviluppo ideale dovrebbe poter permettere questa cosa in modo "sicuro" e "automatico", ma non e' cosi'.

Figurati qualunque altro tipo di cambiamento funzionale e non solo dichiarativo come nell'esempio appena fatto.

Quindi ci si ritrova a dover imporre un modello di gestione dello sviluppo che provveda a garantire che ogni modifica passi attraverso una revisione certificata.

Il modello Microsoft e' molto strutturato e non e' lagato al singolo individuo (non c'e' un signor Linus responsabile ultimo di ogni check-in del kernel per dire).

Piu' il progetto e' complesso piu' il modello Microsoft e' "vincente".

Quello sul quale il modello open ha forse ancora qualche margine di vantaggio e' sul numero di tester, ma anche in questo caso la cosa si basa molto sul moto browniano, per cui se da un lato e' vero che puo' portare da individuare un gran numero di bachi in poco tempo puo' anche lasciare alcune parti del codice completamente inesplorato per lungo tempo.

   
22. Scrooge McDuck
giovedì 15 maggio 2008 alle 2:21 PM - unknown unknown unknown
   

A me viene da pensare che con il sorgente aperto il numero di criptologi incidentali sia comunque maggiore rispetto ad un contesto chiuso (da qui la legge di Linus). Il problema mi pare però che qui sia un altro: la modifica *non* è stata fatta da un criptologo.

Appunto, ciò che realmente conta nella sicurezza non è il numero di persone che possono leggere il codice (a maggior ragione se il controllo non è sistematico ma casuale ed effettuato da "hobbisti"), la sicurezza si ottiene prima di tutto con linee guida precise.

Secondo te in Microsoft quelli che si occupano, chessò, dell'interfaccia grafica possono mettersi a modificare una riga di codice della parte riferita alla crittografia?

Io credo di no, e se quella modifica in debian avesse dovuto obbligatoriamente subire il vaglio del team di OpenSSL il bug non si sarebbe mai avuto.

   
23. Paperino
giovedì 15 maggio 2008 alle 9:50 PM - unknown unknown unknown
   

@Shance:

A parte il ragionamento di Enrico sull'organizzazione, quello che mi preme sottolineare è che la differenza tra chiuso e aperto non ha nessuna rilevanza statistica su fattori come sicurezza e qualità inglobando in questa anche la quantità di interdipendenze. L'unico fattore su cui la disponibilità del codice incide è quello del modello di business. La GPL permette solo un certo tipo di modello.

@Enrico:

Se prendi il testing nella sua interità (functional, stress, perf, etc.) il modello basato prettamente sul volontariato non è sufficiente.

@Marco:

riscrivo la mia frase: "sarebbe bastato che a valutare il risultato del tool e decidere in ultima sede se fare o meno la modifica che ha introdotto il baco fosse stato un criptologo". Quindi concordo: per essere sicuri che questo accada ci vuole un modello "gerarchico" di competenze. Per criptologo intendo ovviamente esperto di algoritmi crittografici e non di cripte; certi termini li so meglio in inglese, a svariati Km di distranza come osserva Amok si perde l'Italiano e si guadagna solo poco inglese.

   
24. sirus
sabato 17 maggio 2008 alle 9:48 AM - unknown unknown unknown
   

Secondo me la cosa "scandalosa" (passatemi il termine) non è tanto la presenza di un baco nel codice, sappiamo tutti che è quasi normale che ve ne siano, la cosa sconcertante è il come questo baco sia stato introdotto!

Se dovessi gestire un qualsiasi pacchetto o insieme di pacchetti per una distribuzione Linux e dovessi trovare delle linee di codice non congruenti o comunque sospette non mi verrebbe mai in mente di commentarle o eliminarle senza consultare chi ha scritto il software, uno dei possibili vantaggi dell'open source è proprio questo ma con un comportamento simile viene meno, quindi ci si chiede se realmente l'open source comporta dei vantaggi.

   
25. FDG
sabato 17 maggio 2008 alle 11:37 AM - unknown unknown unknown
   

@Shance

1. Es. Microsoft, codice chiuso. Ci sarà un tizio che decide cosa programmare...

2. Codice aperto. Tutti ci possono lavorare? E una volta che ho lavorato su una cosa...

Quelle che hai citato tu sono due modi per lavorare, uno disorganizzato, uno organizzato. Il fatto che il progetto sia open o closed non è rilevante. Il codice è aperto, lo puoi scaricare, usare, modificare e ridistribuire. Ma i committer di un progetto open non sono tutti quelli a cui va di fare commit. Se decidi di fare tue modifiche senza dover chiedere nulla a nessuno, devi preoccuparti tu di distribuire queste modifiche.

La differenza tra il software open e quello closed è che il codice closed è noto solo ai membri del gruppo di sviluppo e pochi altri, il open codice comunque lo possono guardare tutti. A parità di organizzazione, dimensione e qualità del team, questa è una differenza che può influire sulla qualità del codice, o quantomeno sulla possibilità di valutarne la qualità da parte di altri (una cosa che m'è capitata di poter fare proprio grazie alla disponibilità dei sorgenti). In che misura, non so dirlo. Magari è nulla o quasi, magari è enorme.

Però bisogna sfatare il mito secondo cui lo sviluppo del software open source, qualsiasi esso sia, è roba da dilettanti condotta in modo disorganizzato da gente che lo fa solo per diletto. Si attribuisce automaticamente a tutti i team che si occupano di software open le stesse qualità negative nell'organizzazione. Non si capisce in base a quale motivazione dovrebbe esser così visto che è comunque un team di sviluppo che produce codice come gli altri. Forse la ragione è nella facilità con cui si può aprire un progetto su sourceforge? Se io apro un progetto open posso essere dilettante, posso farlo a tempo perso senza organizzare il lavoro, spinto unicamente dalla voglia di condividere il mio lavoro con altri. Ma questo non vuol dire che il mio software acquisisca automaticamente tutte le qualità di software ben fatto. Ma perché il giudizio che si può dare su questo modo di procedere deve trasferirsi automaticamente a tutto il software open? E poi, questo approccio non è un'esclusiva dei progetti open. Anzi, ci sono aziende pur non producendo software open mostrano un analogo approccio dilettantistico nello sviluppare software, con qualche possibilità in più per nasconderlo.

   
26. Paperino
sabato 17 maggio 2008 alle 5:44 PM - unknown unknown unknown
   

@FDG:

non credo di aver detto neanche subdolamente che la qualità di un progetto sia inferiore se è open source o che tutti quelli che lavorano in un team open source siano automaticamente tabaccai.

Tabaccaio è chi ha commentato una riga di codice senza sapere cosa stava effettivamente combinando. Tabaccaio è stato l'approccio di chi, nella mailing list di Debian, gli ha detto che se "aiutava a debuggare" la modifica era approvata. Che sia umano sbagliare non ci sono dubbi.

Semmai la mia critica è sempre la stessa: i "fan" dell'open-source portano spesso la teoria dei "many eye balls" come argomento a favore di quella grande teoria che l'open-source è più sicuro perché tutti "possono" guardarlo. Se un pezzo di codice che almeno qualcuno "DOVEVA" guardare è stato trattato con inadeguata superficialità, dove sono le suddette garanzie? Sbaglio a dire che non ci sono?

   
27. FDG
giovedì 22 maggio 2008 alle 12:47 PM - unknown unknown unknown
   

Semmai la mia critica è sempre la stessa: i "fan" dell'open-source...

Ah si...

   
28. wdr
lunedì 26 maggio 2008 alle 11:30 AM - unknown unknown unknown
   

accanito sostenitore dell'open-source! utilizzo debian-ubuntu-slaky da anni

la pu*****nata è stata fatta, inutile nasconderlo, inutile difendersi, accettare l'errore e fare un mea culpa non mi sembra una cosa tanto "imbarazzante" ed era abbastanza doveroso... capisco che ammettere l'errore avrebbe scatenato la gioia di chi da anni ha remato contro il codice libero e avrebbe poi deciso di scrivere un post come questo attribuendo addirittura un "tapiro d'oro", anni di invidia portano a questo essenzialmente, è un pò come dire "avevamo ragione noi", ma era normale e soprattutto prevedile... la superiorità delle comunità OpSo è sotto gli occhi di tutti come la superiorità,la qualità la stabilità e la funzionalità dei sistemi OpSou non è neanche minimamente paragonabile a quella di M$.

senza parlare poi della filosofia intrinseca del progeto: una libera diffusione dei saperi, una scienza aperta e libera a tutti (a chi è in grado chiaramente) senza padroni e senza riserve.

Il fatto che chi lo fa di lavoro (o meglio viene pagato) sia più bravo di uno che non lo fa di lavoro ( o meglio nn viene pagato) è una relazione che nn trova fondamento, anzi forse perchè è un hobby gli si dedica più attenzione e dedizione di una cosa fatta "per forza", e infatti mi sembra palese la questione...l'errore commesso dalla comunità mi sembra sia stato più che altro di stile: ammettere di aver sbagliato (ed è una gran bella gaff ;)) sarebbe stata la miglior cosa!

I buchi esistono sono sintomatici e sempre ci saranno il compito è: per chi viene pagato di lasciarli perchè sarebbe rifare il lavoro 2 volte (o al limite aspettare il service pack (e siamo a 3 signori!!!!)) per chi nn viene pagato risolverlo per avanzare con tutto!!!

   
29. Paperino
lunedì 26 maggio 2008 alle 5:23 PM - unknown unknown unknown
   

capisco che ammettere l'errore avrebbe scatenato la gioia di chi da anni ha remato contro il codice libero

Non remo contro il codice libero per sé: la cosa non mi tocca. Remo contro chi dice che il codice prodotto "liberamente" ha qualità intrinseche superiori, quasi non avesse bisogno di essere testato o revisionato. E quando una mancata revisione fa scoppiare un casino (non è un bug) mi porto un punto a casa. Perché immagino sia ben chiaro quali sono le conseguenze di questo baco, ma nel caso sono riassunte brillantemente qui: blogs.ugidotnet.org/.../92714.aspx

senza parlare poi della filosofia intrinseca del progeto: una libera diffusione dei saperi, una scienza aperta e libera a tutti (a chi è in grado chiaramente) senza padroni e senza riserve.

Tutto bello, sì certo. Peccato che tale filosofia non sia mai stata estesa al resto delle arti e delle professioni. Per cui se scrivessi codice gratuitamente non saprei come pagare l'idraulico che se ne frega altamente della diffusione gratuita del sapere idraulico.

I buchi esistono sono sintomatici e sempre ci saranno

Dovremmo cominciare a distinguere tra buchi e voragini. L'ultima voragine simile risale ai tempi di Sasser.

   
30. Scrooge McDuck
lunedì 26 maggio 2008 alle 7:50 PM - unknown unknown unknown
   

Il fatto che chi lo fa di lavoro (o meglio viene pagato) sia più bravo di uno che non lo fa di lavoro ( o meglio nn viene pagato) è una relazione che nn trova fondamento

A me risulta che buona parte delle sviluppatori che partecipano ai progetti open source più famosi (e finanziati) siano pagati eccome.

Altro che maggiore attenzione e dedizione da parte degli hobbysti, per far navigare bene i progetti gli sviluppatori vengono pagati.

   
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)