Quali sono le implicazioni per la sicurezza di "open-source" e "source-available"?

14

Alla luce del fiasco corrente circostante TrueCrypt , ho ricevuto notevoli critiche da parte di clienti e colleghi attuali nel settore IT per il mio continuo supporto al modello open source . Tali critiche sono solitamente accorpate al dialogo in corso sulle virtù e i fallimenti del modello open source a seguito di episodi come heartbleed . Ho cercato di far notare che nonostante molti articoli che etichettano TrueCrypt come open-source, etichetta disponibile alla fonte trovata su Wikipedia è più corretta.

Insieme a questa distinzione, ho sostenuto che avere il codice sorgente disponibile per la revisione è intrinsecamente più sicuro, ma che non dovrebbe suggerire lo stesso livello di fiducia di un progetto che segue un modello di sviluppo open-source che include permettendo la ridistribuzione del lavoro modificato. Mentre il mio istinto mi dice che questa è una posizione ragionevole da prendere, la differenza è sottile e la mia capacità di comunicarlo in modo convincente è limitata.

Ci sono più valutazioni concrete da fare oltre al mio budello qui? C'è una differenza misurabile nella sicurezza relativa delle applicazioni disponibili alla fonte rispetto alle controparti open source reali? Se è così, è ben stabilito quali fattori contribuiscono esattamente a questo? Per quanto riguarda il modello di sviluppo del sistema operativo in particolare, si ottiene un codice più sicuro rispetto al semplice rilascio del codice per la revisione? O questo si riduce a un'opinione alla fine?

Modifica: fa alcuna differenza se il software specifico in questione è correlato alla crittografia?

    
posta Caleb 29.05.2014 - 13:56
fonte

3 risposte

7

Source-available (SA) si differenzia dal vero open-source (SO) che non esiste il diritto al fork. Ciò significa che quando si nota un difetto di sicurezza in un software SA e gli sviluppatori si rifiutano di risolverlo (che non deve essere dovuto a cattive intenzioni - potrebbe essere solo la mancanza di risorse), gli utenti non hanno la possibilità di biforcare progetto e continua il progetto con un nuovo nome con un nuovo team.

Tuttavia, se un difetto in un progetto SA dovesse essere scoperto e reso pubblico, il rifiuto continuo di riparare danneggerebbe gravemente la reputazione di un progetto SA e allontanerebbe gli utenti da esso.

Alcuni sostenitori del sistema operativo sostengono che la possibilità per tutti di offrire una patch per un progetto OS porti a correzioni di bug più veloci. Tuttavia, questo si applica solo a una parte dei progetti OS: Quelli che seguono il modello di sviluppo di Bazaar e non il modello di Cathedral . Esistono molti progetti OS che non accettano contributi non richiesti di terze parti. È comunque possibile offrire una correzione in modo indipendente, in modo che gli utenti possano applicarla manualmente, ma si tratta di un sovraccarico di manutenzione che molti amministratori e utenti evitano.

E la biforcazione di un progetto a causa di un singolo problema è solitamente più problematica del suo valore. Ho visto diverse forcelle di progetti open source come parte di entrambi i lati della forcella. Il risultato è stato sempre che ha danneggiato il progresso generale di entrambe le forcelle perché le risorse di sviluppo si sono diluite, le infrastrutture e le strutture di gestione dovevano essere duplicate e gli utenti si sono confusi. Provare a tenere insieme un progetto nonostante qualsiasi conflitto di solito ripaga.

    
risposta data 29.05.2014 - 14:28
fonte
2

L'open source e l'origine disponibili, come categorie generali, sono identiche nelle loro implicazioni sulla sicurezza. Il vantaggio principale è la scoperta più rapida di bug / inefficienze / vulnerabilità; più mani rendono il lavoro più leggero. In pratica, il valore di questo vantaggio varierà in base alla dimensione della comunità interessata al progetto e quindi al numero di persone che guardano oltre il codice sorgente.

Riguardo all'esempio fornito: il messaggio da TrueCrypt indica semplicemente che il supporto è stato interrotto. Dare un avviso avanzato sarebbe stato piacevole, per usare un eufemismo, ma tale azione non è limitata alle entità open source (o disponibili alla fonte); le società private interrompono continuamente i prodotti. Se lo fanno meno spesso, ad es. poiché le persone li stanno pagando per fornire un supporto continuo, si dovrebbe riconoscere che assumere o altrimenti pagare commettitori open source per il continuo supporto di un prodotto previsto per essere interrotto è sempre un'alternativa disponibile.

La disponibilità di un supporto continuo è sempre stata, e dovrebbe rimanere, una considerazione chiave per quanto riguarda l'idoneità di un dato prodotto per un particolare compito, open source o altro.

    
risposta data 29.05.2014 - 14:42
fonte
-3

Nella mia esperienza la domanda è così ampia ei pregiudizi così profondamente radicati che potresti perdere tempo a cercare di discutere il caso da entrambe le parti.

I progetti / organizzazioni a codice sorgente chiuso non rilasciano prontamente il proprio codice per l'analisi da parte di una parte indipendente - e anche se di solito lo fanno solo in un NDA, è probabile che qualsiasi analisi di questo tipo abbia un'alta inclinazione del campione. Comunque ecco un paio:

link link

Per ulteriori discussioni vedi anche:

link link link

Dato che i fatti su Truecrypt devono ancora emergere, non è certo un poster-bambino per entrambi i lati dell'argomento (il software open source non era il motivo per cui RSA, Lockheed-Mrtin, Washinton Post e altri venivano violati).

    
risposta data 29.05.2014 - 14:25
fonte

Leggi altre domande sui tag