Dittatore benevolo: modello open source in crisi?

Temi politici Agenda digitale
#1

Continua la discussione da Degooglizziamoci! - software per un’alternativa libera, decentralizzata, etica e solidale:

http://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/

Decide lui se nel mondo si usa un Linux sicuro o meno. Il fatto che GNU/Linux sia composto da molti contributi benintenzionati non ha mai comportato molta democrazia nel modo come poi sono stati assemblati. Esistono altre distribuzioni “democratiche” oltre a debian? Non che la democrazia interna di debian comporti una migliore sicurezza informatica purtroppo…

#2

Nella divulgazione popolare di Linux, viene presentato questo sistema operativo come il piú sicuro, talvolta immune ai virus. In realtà, la sicurezza non riguarda solo i virus, ma ingegnosi sfruttamenti di bug, spyware o in generale malware (categoria che include tutto).

È probabile che l’utente comune è già sufficientemente protetto dalle nuove versioni di Windows o di Linux (salvo comportamenti negligenti dovuti allo stesso utente).

Quello che mi chiedo è come si fa a gestire un codice lungo milioni di righe di codice. Una singola persona non può controllare (nemmeno semplicemente leggere) tutto. Quindi è necessario un esteso team di programmatori di cui devi aver fiducia: selezionare le abilità e anche lo stile (o quanto meno insegnarlo). Ognuno si occuperà di pochi moduli di questo grande progetto, quindi deve essere estremamente modulare.

Compilato tutto il programma, la sicurezza è data, non solo dalle abilità dei programmatori scelti, ma dall’utilizzo degli utenti e dalla segnalazione di bug. È solo empiricamente che si può maturare l’affidabilità di un “codice gigante”. Naturalmente non basta che il s.o. sia molto diffuso e molto utilizzato, per essere considerato sicuro, serve anche la qualità del team e la prontezza di intervento nel risolvere i bug.

Non credo che contorti sistemi di sicurezza (es. operazioni random sugli indirizzi di memoria per prevenire certe categorie di attacchi) sia auspicabile. Dipende anche qual è il livello di sicurezza che serve, ma raramente c’è un bisogno cosí elevato. L’approccio empirico, sarà relativamente lento, sfruttabile nel frattempo, ma alla fine porta alla sicurezza mantenendo comprensibilità e pulizia delle operazioni.

Ritengo che non è in crisi il modello open source, al massimo non è adatto in contesti dove serve la massima sicurezza e non puoi basarti sulla fiducia in un codice molto grande e complesso. In tali casi, servono semplici dispositivi basati su complesse password o possibilmente non connettersi affato su Internet (magari si passano i dati con una chiavetta (fisicamente) dai PC connessi a quelli che vanno super protetti). Insomma, dove la sicurezza deve essere massima servono strategie diverse, non tentare imprese impossibili sul codice dei sistemi operativi.

Zero privacy se usi un sistema Microsoft Windows
#3

Riguardo a Microsoft ho risposto in Zero privacy se usi un sistema Microsoft Windows

Da un po’ sto promuovendo l’idea di abbinare git a Liquid Feedback, cioè di fare in modo che la patch da inserire in un software libero passino per una democrazia liquida piuttosto che attraverso un dittatore benevolo.

Oh si che è auspicabile. C ha la tendenza ad avere questi punti deboli, intercettarli in via generica è un bene.

Quando un problema di sicurezza è generalmente noto e miliardi di PC sono affetti, non ti disturba l’idea che chiunque può da un momento all’altro soggiogarli in un gigante botnet? L’idea che gli update automatici siano più veloci non è più molto all’altezza dei tempi.

I disagree. Quando i sistemi sono stati compromessi gli attaccanti lo faranno con sufficiente acribia che futuri update faranno fatica a “liberarli” dal rootkit. Con le possibilità odierne di infettare ogni chiavetta, ogni disco rigido, ogni BIOS non escludo che l’utente non sia più in grado di difendersi nemmeno attraverso una nuova installazione del sistema…

Le estensioni per un hardened kernel sono note, stabili e la stragrande maggioranza degli utenti non percepirebbe neanche la differenza nella performance. Non vedo alcuna ragione comprensibile per la quale si stia ancora a distribuire sistemi insicuri alla popolazione.

#4

Io non me ne intendo, se implementare piú sicurezza non crea problema alle prestazioni, ben venga. Diffusi problemi di sicurezza con danno ai propri dati o banner invadenti, di cui sono venuto e vengo ogni tanto a conoscenza, sono dipesi da gravi trascuratezze da parte degli utenti (toolbar malevoli installati, allegati di posta da non aprire ma aperti, ecc.). Mi sembra un po’ incredibile uno scenario di infezione su larga scala che passa ovunque.

Ad ogni modo, non me ne intendo e non ho un interesse cosí accesso da iniziare ad approfondire nel modo dovuto. Inoltre, o Linux o Windows qualcosa devo pur installare… non so come va con il Mac… i cellulari abbiamo quelli che abbiamo…

Avvalersi di LQFB per portare avanti un progetto open source potrebbe essere un ottimo salto di qualità (talvolta so che la documentazione del codice nei progetti open source è lacunosa, altre volte molto buona, e altri aspetti validi o problematici). Chissà quali sviluppi futuri seguiranno…

#5

Debian porta avanti qualcosa di simile a liquidfeedback in termini di matematica della votazione oligarchica ma è ancora lontana da qualsiasi intenzione di democrazia aumentata come la intendiamo noi A Devuan avevo inizialmente proposto di usare immediatamente lqfb per evitare gli errori di Debian, c’è stata una debole reazione positiva ma poi non so piu (la natura egocentristica dei root-men e programmatori rende ovviamente tutto molto piu difficile ma assolutamente comunque sia proponibile che fattibile)

#6

Sto parlando di scenari tipo StuxNet, dove l’attaccante (la NSA) conosce punti deboli non documentati in tutti i sistemi e li usa per un obiettivo molto specifico. Sto parlando di cyber warfare. Roba dove non importano gli errori degli utenti… by the way, in Linux è più difficile inventarsi un allegato che possa esplodere o di installare malware scaricata a cavolo dalla rete se esiste il software center… i problemi “utenti” per me sono problemi Microsoft.

Il problema più grave nella sicurezza degli open source secondo me sta nell’invalangamento di modifiche e aggiornamenti. Ogni giorno la Google butta patch dentro Chrome e Firefox – diventa talmente tanta roba che una persona non può stare a leggersi tutto. A volte sarebbe il caso di dire stop: concentratevi sulle cose importanti e non inserite minchiate come “Heartbeat” dentro openssl.

LQFB permetterebbe di dire no alle valanghe, LQFB permetterebbe anche di modellare la rete di fiducia tra gli sviluppatori. Se tutti si delegano a vicenda bastano uno o due persone che abbiano le palle di leggersi la patch del giorno e si tirano appresso la fiducia del branco attraverso le deleghe. In questo modo si distribuisce anche il lavoro: se Roberto ha dato il supporto a questa patch io mi concentro a studiarmi l’altra che ancora non ha supporto da parte di nessuno… in questo modo una dozzina di mantenitori potrebbe anche smistare le valanghe di submit provenienti dai grandi colossi – e smetterla con la stupida pratica di fidarsi delle persone con le quali ha bevuto una birra. Non significa nulla. I migliori traditori sono quelli simpatici che ti offrono da bere perchè i colossi pagano bene i tradimenti contro l’umanità digitalizzata.