[Discussioni] Il modello open source produce ancora il software migliore?

[loredana]

On Sun, 2014-04-13 at 12:34 +0200, Antonio wrote:
> > Degli altri, di bachi, quelli per il software proprietario, non sappiamo
> > dopo quanti anni siano corretti e neppure se lo siano.
> Il modello del software proprietario è proprio quello, la segretezza,
> di bachi ce ne possono essere uno ogni due righe di codice ma siccome
> pochi conoscono il codice sorgente allora può andare avanti per anni.
> 
> Ma il modello del software libero è completamente diverso, si basa sul 
> fatto che
> il codice è visibile a tutti e che "tanti occhi" sono in grado di 
> trovare e risolvere
> il problema.
> 
> Ora, sul fatto di risolvere va bene, un bug una volta trovato si risolve 
> in pochi
> minuti, sul trovarlo invece, è un po' più complicato.

Certo, ma questo e' complicato per tutti e per tutto, software libero e
software proprietario. 

Occorre concentrarsi sulle differenze tra i due modelli, se si vuol
valutare quale sia piu' efficace (nessuno dei due lo e' in assoluto).

> Prendiamo il caso del momento, OpenSSL.
> 
> La funzionalità TLS/DTLS heartbeats è stata introdotta a fine 2011 (
> qui uno dei commit 
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4817504 )
> 
> L'ha scritta un programmatore e controllata un altro, fine.

Questo non dipende dal modello, ma dall'uso che se ne fa. In teoria, la
possibilita' di controllare la nuova funzionalita' c'era per tutti. Per
tutto il software libero che io conosco, ci sono i log delle differenze
tra una versione e l'altra, per esempio. Una possibilita' non vuol dire
che succeda, vuol solo dire che e' possibile.

Se non succede, l'analisi si deve spostare sul perche' non succeda,
lasciando in pace il modello sottostante.

Insisto su questo punto perche' a me pare che davvero non sia chiaro, in
generale. Se proprio si vuol discutere di modelli, allora la domanda da
porsi e', nel caso del baco di openssl, se sia meglio nascondere o
mettere a disposizione di tutti specifiche, algoritmo, codice. E a
questo ha risposto sia la teoria (credo nessuno ormai sostenga che la
sicurezza dipenda dal nascondere l'algoritmo o la sua implementazione,
si nasconde la chiave e, ovviamente, non si ha mai la certezza assoluta
di averla davvero resa ianccessibile solo a chi ne ha diritto) e la
pratica, continuamente.

Tra la teoria e la pratica c'e' prima di tutto la mancanza (in teoria)
di ogni certezza assoluta) poi c'e' l'implementazione, ci sono infiniti
altri aspetti, c'e' chi fornisce un servizio e c'e' l'utente finale. Ci
sono tutti quelli che ne parlano, a vari livelli, sapendo piu' o meno,
piu' o meno condizionati da interessi di parte o ideologici. Etc etc. 

Posizionare correttamente uno specifico problema aiuta a cercarne la
soluzione. 

> Per due anni nessun altro ha verificato quel codice riga per riga. 
> Perchè alla
> fine le righe senza controllo erano solo due, capite, su decine di 
> migliaia di linee.
> Tanto è vero che la patch è stata (semplicemente):
> 
> if (1 + 2 + 16 > s->s3->rrec.length)
>          return 0; /* silently discard */
> if (1 + 2 + payload + 16 > s->s3->rrec.length)
>          return 0; /* silently discard per RFC 6520 sec. 4 */

La velocita' di produrre una patch e' un altro parametro importante nel
confronto tra i due modelli, anche se non l'unico. Cosi' come lo e' la
velocita' con cui si comunica il problema a coloro che sono vittime
potenziali di un baco. 

Debian fa scuola, io, come semplice utente, ricevo quotidianamente
segnalazioni di problemi di sicurezza (praticamente ogni giorno o quasi)
con l'indicazione dei pacchetti che sono stati coinvolti per le varie
release (main, testing e sid) con l'indicazione precisa dei pacchetti e
delle versioni coinvolte, nonche' l'indicazione della versione del
pacchetto per cui posso stare tranquilla da quel momento in poi perche'
"quel" baco e' stato corretto (e domani ce ne sar'a un altro). Giusto
per la cronaca, il baco in questione e' stato introdotto solo con debian
wheezy, debian squeeze non e' mai stata coinvolta. Una dimostrazione che
non sempre correre ad aggiornare (a parte gli aggiornamenti di
sicurezza) sia poi una buona idea.

Il vero problema pratico, ora, e' come si propaga la patch (fatta
immediatamente all'origine) ai vari sistemi che usando la versione
bacata di openSSL per due anni sono stati esposti ad un rischio non
rilevabile e come questi si comportano di conseguenza. Qui si inserisce
un altro livello di possibile giudizio, A me sembra ovvio che occorra
essere conservativi, quando non si sa il danno che si e' subito, e che
sarebbe opportuno correre ai ripari come se il danno fosse il peggiore
possibile, soprattutto per quei server che hanno funzioni chiave (tutti
quelli che usano la "s" di https, per intenderci). In ogni caso,
l'utente coinvolto dovrebbe essere informato di quali siano le misure
adottate, per esempio dal proprio ISP provider.

La velocita' di aggiornamento a cascata e' un altro parametro
fondamentale e mi pare che anche su questo non ci sia nessuno che batta
facilmente il software libero (progetto GNU e derivati) rispetto a
quello semplicemente open, mischiato al proprietario su cui non c'e'
controllo alcuno, nonche' a quello proprietario e basta.

Loredana