Grave falla scoperta su WhatsApp: a rischio la privacy delle chat [Aggiornato]

[ComputArte]

Originariamente inviato da GTKM

Quindi, secondo me, il discorso va affrontato su due piani diversi: ideologicamente parlando, le tecniche di offuscamento sono una carognata, perché vanno contro lo spirito alla base della GPL, e qui subentra il supportare o meno determinate idee.

Dal punto di vista pratico, invece, se il suo strumento è perfettamente legale (e qui solo un esperto potrà dirglielo) non si può dire molto altro. Al massimo, si cercherà di fare una nuova licenza che preveda anche casi simili (sperando che poi venga adottata, però, perché, ad esempio, Linux non passerà mai alla GPLv3).

....offuscare il codice fa rima con CHIUDERE
quindi oltre ad essere, come la definisci tu : "UNA CAROGNATA", è una azione di manipolazione ( non etica e probabilmente non legale ...alla sola prova di sentenze passate in giudicato! ) di chi furbastramente ( che non ha nualla che vedere con chi è furbo ) vuole sfruttare codice scritto da altri con lo spiro di condivisione TOTALE, ma mentenere l'orticello privato, egoisticamente protetto.

Insomma sfruttare il lavoro degli altri ( che lo concedono con termini e condizioni chiare !) ma farsi pagare il proprio ( aggirando i termini e le condizioni con cui gli altri hanno condiviso il proprio lavoro )... ma come è facile pensare male

Ricordo a tutti che il topic è racchiuso nel titolo: Facebook/Whatapp che si lodano e si sbrodano nel dire che non ficcano il naso nei dati dei loro clienti GRATUITI, che invece ....lo fanno come e più di prima, senza che ci sia un piccolo passo di BUONA FEDE: concedere a chi ha le conoscenze, di leggere TUTTO il codice per VERIFICARE se i dati degli utenti siano veramente rispettati in termini di privacy e sicurezza!

Originariamente inviato da cdimauro

@ComputArte: risponderò quando avrò tempo, anche se ti anticipo che c'è ben poco da dire, viste i tuoi continui cambiamenti di discorsi, mistificazioni (incluse offese che t'inventi di sana pianta, visto che non ne esistono i presupposti), e asserzioni che spacci per vedere senza alcuna dimostrazione, e ovviamente i tuoi miseri tentativi di smontare (girandoci attorno con altri discorsi) la mia dimostrazione formale che è e rimane del tutto inattaccabile, come peraltro tu stesso hai ammesso alla fine (e dunque perché continui?)

Prenditi tutto il tempo che vuoi: e se ti serve per ribadiere i tuoi teoremi da mondo iperuranico...puoi anche risparmiarlo dedicandolo all' "offuscamento della realtà "

Anche questa è una dimostrazione formale inattaccabile
Se A>B e C<B , A>C
....forte, eh!?

Ipotesi e tesi si basano su assunzioni REALISTICHE...sbagliate le quali, le conclusioni non possono che essere incorrette
Quindi la tua dimostrazione Teorica, in cosa DESCRIVE LA REALTA' ( quella oggetto di questo articolo...e non "una" realtà semplificata e teorica di un mondo onirico...ok ?!
Take your time...but as already written....you can save it

...ah!...ah! ...ah! ancora che mi ri-perdi le staffe farfugliando offese... sii rispettoso e non bollare "miseri" quelli che ti sforzi di far passare come tentativi di smontare un tuo terorema che "pare" siano in molti a non condividere.
...e tra l'altro non sembra tu abbia argomenti solidi da contrapporre ai diversi "spunti" sul mondo REALE che ti ho proposto ...
ti rammento il regolamento del forum ( e due !)

[cdimauro]

Originariamente inviato da ambaradan74

Ti rispondo solo perche mi fai il solito attacco ad Hominem, ora sono bugiardo e mistificatore, ieri ero fanatico integralista dell'open source (come se fosse un male poi LOL)

Scusami se t'ho etichettato in quel modo, ma mi pare che questo:

"Andare contro questi principi è da imbroglioni. Punto."

me l'abbia appioppato TU. O me lo sono sognato?

Non entro nei tuoi labirinti e rigiri di discorsi che si concretizzano coi soliti multiquote a pezzi
Ripeto solo il concetto.

La filosfia della licenza GPL (copyleft) sono ben precise e chiare.
Senza dubbi. Senza interpretazioni.
Lo scopo e' il miglioramento , la ridistribuzione e l'aiuto al prossimo.
Tutto quello di cui discutevate prima e' contro tutto questo e fa parte della logica dell'inganno e del sotterfugio.

Chissenefrega di un giudice cosa direbbe e delle leggi, e' una mentalita' da persone scorrette. Fine.

E dimostri ancora una volta di non aver capito proprio nulla, visto che non mi sono mai sognato di dire nulla del genere.

Meno male che GTKM ha saputo cogliere alla perfezione il tutto, sintetizzando e riepilogando. Vedi sotto.

Originariamente inviato da GTKM

Ma la stessa cosa vale per uno sviluppatore.

cdimauro non sta parlando di violare i termini della licenza (o almeno lo spero, perché su quello sono contrario pure io) ma di trovare un modo per non rilasciare il proprio codice pur rispettando il documento legale. Lui non tiene alla questione ideologica di base, quindi guarda esclusivamente l'aspetto pragmatico.

Il metodo cavilloso lo cerca per non essere costretto a sottostare ad un'ideologia che lui personalmente non accetta. Facciamo un esempio: è scorretto non pagare le tasse, perché questo ricade sui servizi e sulla società, ma quando c'è un modo LEGALE per evitarle o ottenere agevolazioni, viene immediatamente sfruttato.

Quindi, secondo me, il discorso va affrontato su due piani diversi: ideologicamente parlando, le tecniche di offuscamento sono una carognata, perché vanno contro lo spirito alla base della GPL, e qui subentra il supportare o meno determinate idee.

Dal punto di vista pratico, invece, se il suo strumento è perfettamente legale (e qui solo un esperto potrà dirglielo) non si può dire molto altro. Al massimo, si cercherà di fare una nuova licenza che preveda anche casi simili (sperando che poi venga adottata, però, perché, ad esempio, Linux non passerà mai alla GPLv3).

Quoto questo, perché hai centrato tutto, come dicevo.

Ma preciso un paio di cose.

Primo, il tool di cui ho parlato non sarebbe certo illegale. Tutt'altro. Semmai un'eventuale contestazione legale potrebbe avvenire sul PRODOTTO risultante dalla sua applicazione, e dunque sul codice offuscato che venisse distribuito a causa della distribuzione dei binari da esso compilati.

Secondo, l'idea non è di fornire patch con codice offuscato da integrare poi in Linux o qualunque altro progetto di cui s'è fatto uso. L'idea è semplicemente di mettere a disposizione i sorgenti offuscati perché ciò deriva dall'obbligo di licenze virali come la GPL, per l'appunto. Ma senza nessun'altra pretesa.

Mi obblighi a fornire i sorgenti dei binari che ho rilasciato? E io te li fornisco. Punto. Poi se vuoi cercare di aggiungerli al ramo principale del prodotto originale, fork, o altro, non sono più affari di chi ha usato il tool per l'offuscamento.

E quanto alla contribuzione a progetti diversamente liberi ci sarebbe di che dire, tra l'altro, visto che la FSF obbliga a rimuovere ogni copyright dalle patch, visto che pretende che il codice abbia esclusivamente il suo. Questo se vuoi che le tue patch vengano integrate nel ramo principale dell'applicazione.

Per non parlare poi del coding style, che dev'essere rispettato alla lettera. E quello che ha GDB, ad esempio, è semplicemente ORRIBILE (come il progetto, peraltro)!

Ora immaginate cosa possa succedere se lo stesso codice dev'essere utilizzato sia in GDB sia in LLDB: questi ultimi devono sorbirsi pezzi di codice che sono un pugno nell'occhio. Oppure devono essere fornite DUE patch per la STESSA, IDENTICA, cosa...

Bah

@ComputArte: al solito, per rispondere a te c'è sempre tempo. D'altra parte il contenuto lascia, puntualmente, a desiderare, e dunque non c'è alcuna fretta.

[cdimauro]

Originariamente inviato da Bellaz89

Ma scusa, e quindi la soluzione al fatto che GDB ha un coding style subottimale sarebbe ridistribuire i sorgenti offuscati?????? Ma che ragionamento e' ?!?!?!?!?!?!

Infatti era / è un discorso completamente a sé stante, che non c'entra niente con l'offuscamento, che peraltro non ho nemmeno citato!!!

Ma poi te dei progetti GPL che modifichi puoi redistribuire il sorgente con il coding style che ti pare(basta che sia la tua forma di modifica preferenziale) , quindi questo discorso non sta proprio in piedi.

Questo lo dici perché non hai idea di cosa significhi mantenere i propri sorgenti allineati al repository principale.

Che poi è il motivo per cui si fa upstream: fare in modo che le proprie patch siano integrate nel ramo principale, in modo da eliminare gli n-mila problemi di sincronizzazione.

Hai detto tu stesso che non te ne frega niente della community del free software. Non trovare giustificazioni ulteriori.

Qui stai mistificando: non ho parlato della comunità. Le mie rimostranze sono nei confronti di GPL et similia, che sono virali.

Il mese scorso, giusto poco prima di andare via da Intel, ho contribuito con due mastodontiche patch al progetto fMBT, che hanno rivoluzionato il modo (e la velocità) di fare GUI automation su Windows. La licenza di questo progetto la puoi vedere tu stesso.
Peraltro in precedenza la versione per Linux non aveva certe funzionalità disponibili su Android e Windows, e grazie al lavoro di ricerca che ho fatto e passato al mantainer, finalmente ha raggiunto lo stesso livello (ma non quello delle mie modifiche al ramo Windows).

L'unico cruccio rimane, per l'appunto la licenza di tutto il lavoro che ho fatto, che è virale.

EDIT: che poi la questione del coding style c'entra con i cavoli a merenda.

Non e' che se un progetto e' BSD o MIT i gestori del repo principale mi permettono di integrare codice con il coding style che piu' mi piace. Idem per qualsiasi altra licenza.

Certamente. Ma il coding style di GBD è veramente orribile. Agli altri ci si può adattare, ma questo è un pugno nello stomaco.

Meno male che ho evitato di contribuire, ma comunque ho effettuato parecchie code review di patch, ed è roba da far saltare i nervi.

Bon. Al momento è finita. Ma col nuovo lavoro adesso ho a che fare con Linux, per cui non è escluso in futuro che debba ritrovarmi con roba del genere...

[GTKM]

Originariamente inviato da ambaradan74

Ribadsco, il problema e' di carattere etico, non legale, come piu volte detto.
L'ideologia delle licenze copyleft e' di aiuto e condivisione, una sorta di crescita collettiva applicata al software.
Se uno non condivide questa filosofia, semplicemente non usa licenze GPL, non e' che trova un modo cavilloso per usarle ma per non sottostare ai loro principi.

L'esempio delle tasse e' perfetto, se uno elude le tasse legalmente ok, puo farlo, lo fa a fine li. Legalmente pulito, legalemente bravo ma eticamente imbroglione resta.
Ed esempi su questo ce ne a iosa , dai capitali all'estero fatti rientrare semiesentasse , ai paradisi fiscali ecc.
tutto spesso anche legale ma eticamente da condannare, ne viene danneggiata la collettivita'.

Però, pure nel caso delle tasse facciamo dei distinguo: eludere (o addirittura evadere) una tassa ritenuta ingiusta dalla collettività non viene giudicato come il sottrarre denaro ai bisognosi. E pure l'etica, dunque, non è universale, de facto.

Nel caso specifico, chi offusca codice GPL verrà "condannato eticamente" solo da chi apprezza la licenza e la filosofia che ne sta alla base.

Esattamente come il reverse engineering non viene proprio esaltato da chi punta sulla distribuzione di software closed.

[Erotavlas_turbo]

Originariamente inviato da cdimauro

Perché è una cosa semplicemente inammissibile, come già dimostrato formalmente.

La differenza fra open e closed risiede soltanto nell'audience. E NULLA dice riguardo alla "sicurezza" intrinseca di un determinato prodotto.

Ovviamente se sei in grado di dimostrare il contrario sei liberissimo di farlo, eh! Ma le chiacchiere, di per sé, stanno a zero.

Che poi, parli di software proprietario, quando questo può benissimo essere open e, dunque, ricadere nei tuoi canoni e, quindi, sarebbe condizione sufficiente a potersi fregiare del titolo di sicuro...

Il che dimostra soltanto una cosa: la tua aprioristica avversione ideologica nei confronti di aziende che ti stanno sullo stomaco. Sono il male a prescindere: anche quando rilasciano il sorgente per dei loro prodotti.

Puoi pensarla come vuoi.
I fatti sono contrari a quello che dici.
Un esperto di sicurezza, con conoscenze superiore a chiunque in questo forum in questa materia, ha già risposto a tutto:

La risposta del ricercatore che ha scoperto la falla di sicurezza direttamente sul guardian.
Spiega dettagliatamente tutti i problemi e risponde al creatore di signal mostrando che ha commesso un errore nel difendere whatsapp nel suo blog.

Creatore protocollo Signal: “The choice to make these notifications ‘blocking’ would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn’t, effectively telling the server who it could man-in-the-middle transparently and who it couldn’t; something that WhatsApp considered very carefully.”

Scopritore falla: "This claim is false. Those “blocking” clients could instead retransmit a message of the same length that just contains garbage and this message would just not be displayed by the receiver’s phone. Encryption guarantees the garbage or real messages are indistinguishable in the encrypted form. Hence, this technique would make identifying users with the additional security enabled on a large scale impossible."
Inoltre, saggiamente, afferma:
"What Facebook should do is fix the issue, and release the source code of its apps so that the public can verify the integrity of its messaging apps. Facebook’s business asset is not the source code of the app; the source code of many apps with many of the same features is freely available already to competitors. Its real business asset is its massive, almost 2 billion-person user base. The source code of its highly scalable server infrastructure is also a true business asset but that part doesn’t need to be open sourced."

[cdimauro]

Originariamente inviato da Bellaz89

Ti lamenti del coding style dei progetti free ma vuoi distribuire un programma per permettere l'iniezione di codice offuscato negli stessi. Io ci vedo un controsenso.

Sono due cose completamente diverse, e non sto nemmeno qui a spiegartelo, perché dovresti saperlo.

Al di la del fatto che non te lo ordina il dottore di fare upstream sul ramo principale (e che ci sono metodi per sincronizzare il tuo repo con quello del repo principale senza integrare codice nel primo)

Mai sentito parlare di problemi di merge, a quanto pare, che tante volte richiedono di rimettere mani ai sorgenti per "armonizzare" le differenze di codice.

E capitano già soltanto per effettuare l'upstream di singole patch, per cui puoi immaginare cosa possa succedere nel dover mantenere una base di codice che ha parecchie differenze.

Che cavolo ci incastra con la GPL questo ???? E' lo stesso per MIT BSD etc.

Prova a inviare una patch con il coding style che ti pare nel trunk principale di OpenBSD. Vediamo cosa ti rispondono i manutentori.

Mai detto nulla di diverso, mi pare.

Calma: ho parlato anche di ALTRE cose.

Non sto mistificando proprio niente. Hai scritto tu stesso in un post precedente che non ti interessa di essere ben visto da chi crede nella GPL.
O hai scritto male il tuo post precedente, oppure traspare abbastanza chiaramente come la pensi. E questo indipendentemente dai contributi che hai dato in passato a progetti GPL (non che, per quel che conta, io non lo apprezzi, sia chiaro!)

TU: "Ma fornire codice offuscato non e' in generale una pratica ben vista."
IO: "Questo lo sa, ma a me non interessa di essere ben visto. "

Se la comunità di cui parli fosse costituita interamente da fanatici intolleranti che non accettano il fatto che qualcuno posso offuscare il codice, allora hai perfettamente ragione.

@ambaradan74: al solito, GTKM mi ha anticipato.

Originariamente inviato da Erotavlas_turbo

Puoi pensarla come vuoi.
I fatti sono contrari a quello che dici.

La mia dimostrazione è lì che aspetta te e qualunque altro luminare in ambito della "sicurezza" (con le virgolette per quanto già detto prima).

Un esperto di sicurezza, con conoscenze superiore a chiunque in questo forum in questa materia, ha già risposto a tutto:

La risposta del ricercatore che ha scoperto la falla di sicurezza direttamente sul guardian.
Spiega dettagliatamente tutti i problemi e risponde al creatore di signal mostrando che ha commesso un errore nel difendere whatsapp nel suo blog.

Creatore protocollo Signal: “The choice to make these notifications ‘blocking’ would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn’t, effectively telling the server who it could man-in-the-middle transparently and who it couldn’t; something that WhatsApp considered very carefully.”

Scopritore falla: "This claim is false. Those “blocking” clients could instead retransmit a message of the same length that just contains garbage and this message would just not be displayed by the receiver’s phone. Encryption guarantees the garbage or real messages are indistinguishable in the encrypted form. Hence, this technique would make identifying users with the additional security enabled on a large scale impossible."

E questo non c'entra nulla sulla diatriba in corso.

Inoltre, saggiamente, afferma:
"What Facebook should do is fix the issue,

Corretto nonché ovvio.

and release the source code of its apps so that the public can verify the integrity of its messaging apps.

Questo NON è necessario allo scopo. Il difetto è e rimane un difetto a prescindere che il codice sia chiuso o aperto. E in ogni caso va fissato.

Facebook’s business asset is not the source code of the app; the source code of many apps with many of the same features is freely available already to competitors. Its real business asset is its massive, almost 2 billion-person user base. The source code of its highly scalable server infrastructure is also a true business asset but that part doesn’t need to be open sourced."

Verissimo, ma ciò non toglie quanto scritto sopra: non c'è motivo per cui il pubblico (chi, poi?) debba verificare il codice del client di Facebook.

[Erotavlas_turbo]

Originariamente inviato da cdimauro

La mia dimostrazione è lì che aspetta te e qualunque altro luminare in ambito della "sicurezza" (con le virgolette per quanto già detto prima).

Ti rispondo in un messaggio successivo.

Originariamente inviato da cdimauro

E questo non c'entra nulla sulla diatriba in corso.

Certo che è importante è il punto focale della discussione (whatsapp consente di leggere a terzi i messaggi cifrati) che poi ha preso una certa divergenza.

Originariamente inviato da cdimauro

Questo NON è necessario allo scopo. Il difetto è e rimane un difetto a prescindere che il codice sia chiuso o aperto. E in ogni caso va fissato.

Secondo te. Secondo la quasi totalità dei ricercatori di sicurezza è il contrario.
A partire da questo che ha scoperto la falla.
Continui a voler affermare una cosa andando contro chi ha più conoscenze di te e dimostra con i fatti l'evidenza.
Contento tu...

Originariamente inviato da cdimauro

Verissimo, ma ciò non toglie quanto scritto sopra: non c'è motivo per cui il pubblico (chi, poi?) debba verificare il codice del client di Facebook.

Si è una questione di trasparenza.

Originariamente inviato da cdimauro

Ad esempio si sa da anni che Google ha forkato Linux adattandolo per le sue esigenze, e che dunque i suoi server fanno girare binari ben diversi da quelli compilabili da chiunque altro prendendo i sorgenti (originali) di Linux. Ma Google non se ne sta con le mani in mano: segue le modifiche a Linux, e preleva / applica le patch che le interessano, per mantenere aggiornati i suoi server. Il tutto senza che Google abbia rilasciato le modifiche che ha fatto, e tenendosele rigorosamente per se (dunque software chiuso).

Secondo te i server di Google sono intrinsecamente meno sicuri di quelli del sorgente originale / pubblico di Linux, solo per il fatto che il loro codice rimane ben chiuso nel loro cassetto?

Il kernel linux è rilasciato sotto licenza GPL2 la quale consente a google di usare internamente le modifiche del codice.
Comunque è applicabile un altro punto della licenza. Dato che il codice modificato è usato in server pubblici, è legittimo richiedere una copia del codice sorgente.

[Erotavlas_turbo]

Originariamente inviato da cdimauro

La mia dimostrazione è lì che aspetta te e qualunque altro luminare in ambito della "sicurezza" (con le virgolette per quanto già detto prima).

Ti rispondo in un messaggio successivo.

Originariamente inviato da cdimauro

E questo non c'entra nulla sulla diatriba in corso.

Certo che è importante è il punto focale della discussione (whatsapp consente di leggere a terzi i messaggi cifrati) che poi ha preso una certa divergenza.

Originariamente inviato da cdimauro

Questo NON è necessario allo scopo. Il difetto è e rimane un difetto a prescindere che il codice sia chiuso o aperto. E in ogni caso va fissato.

Secondo te. Secondo la quasi totalità dei ricercatori di sicurezza è il contrario.
A partire da questo che ha scoperto la falla.
Continui a voler affermare una cosa andando contro chi ha più conoscenze di te e dimostra con i fatti l'evidenza.

Originariamente inviato da cdimauro

Verissimo, ma ciò non toglie quanto scritto sopra: non c'è motivo per cui il pubblico (chi, poi?) debba verificare il codice del client di Facebook.

Si è una questione di trasparenza.

Originariamente inviato da cdimauro

Ad esempio si sa da anni che Google ha forkato Linux adattandolo per le sue esigenze, e che dunque i suoi server fanno girare binari ben diversi da quelli compilabili da chiunque altro prendendo i sorgenti (originali) di Linux. Ma Google non se ne sta con le mani in mano: segue le modifiche a Linux, e preleva / applica le patch che le interessano, per mantenere aggiornati i suoi server. Il tutto senza che Google abbia rilasciato le modifiche che ha fatto, e tenendosele rigorosamente per se (dunque software chiuso).

Secondo te i server di Google sono intrinsecamente meno sicuri di quelli del sorgente originale / pubblico di Linux, solo per il fatto che il loro codice rimane ben chiuso nel loro cassetto?

Il kernel linux è rilasciato sotto licenza GPL2 la quale consente a google di usare internamente le modifiche del codice.
Comunque è applicabile un altro punto della licenza. Dato che il codice modificato è usato in server pubblici, è legittimo richiedere una copia del codice sorgente.

[Erotavlas_turbo]

Originariamente inviato da cdimauro

Gli ho già risposto, ma so che già non ti piacerà quello che ho scritto.

Anche pratica. Vedi la risposta di cui sopra.

E con ciò è chiaro che NON hai capito in cosa si fondi la dimostrazione.

I termini sono chiari, pratici e reali, e ciò che hai scritto NON si applica (perché risulta già nelle ipotesi) o non ha senso (stessa obiezione).

Rileggiti e analizza per bene la dimostrazione, cortesemente.

La dimostrazione è e rimane perfettamente valida, checché tu ne dica. E siccome non la puoi smontare, anche perché non l'hai capita (vedi sopra), vedo che non ti resta altro che cercare (inutilmente) di sminuirla.

Forse sei tu che non riesci a capire l'evidenza dei fatti.
Secondo la tua dimostrazione x open source considerato sicuro e y closed source derivato da x dove è cambiata solo la grafica, è ugualmente sicuro.
Questo formalmente non fa una piega.
Praticamente non ha alcun senso in quanto per poter affermare che y sia derivato da x devi avere accesso al codice sorgente per verificare che sia effettivamente cosi oppure deve esserci qualcuno che ti dia questa garanzia. Nel primo caso ricadiamo in y=x mentre nel secondo andiamo a fiducia che vale poco visti i vari scandali...

Originariamente inviato da cdimauro

Che si riconduce proprio al teorema dell'arresto. Stessa pagina, poco più avanti: Proof by reduction to the halting problem.

Il che dimostra due cose: che quella pagina non hai l'hai nemmeno letta tutta. E che, soprattutto, continui a parlare di cose di cui non hai conoscenza.

Si vede che tu non hai letto il mio messaggio.
Per valutare se un programma ha una certa proprietà occorre applicare il teorema di Rice.
Il teorema di Rice generalizza il problema dell'arresto a qualunque proprietà di un programma o funzione parziale. Il problema dell'arresto è un caso particolare fondamentale e usato per dimostrare la validità dell'altro. Inoltre, la dimostrazione di Turing al problema dell'arresto e l'applicazione del teorema di Cantor alle macchine di Turing.

Originariamente inviato da cdimauro

Cose per le quali io ho, invece, sputato sangue all'università, e che come vedi non soltanto comprendo, ma applico correttamente.

Veramente? Conosco molte persone che hanno fatto l'università con ottimo profitto (io compreso) e non ho mai visto nessuno sputare sangue.
Ho visto invece farlo a persone che lavorano in fabbrica, lavorano la terra e in generale che fanno lavori veramente duri non come studiare.
Forse ti conviene moderare i termini per rispetto di queste persone.

Originariamente inviato da cdimauro

Difatti se tu avessi abbozzato una definizione di software "sicuro" (che non è certo un caso che abbia condito di virgolette, visto che non ne esiste una oggettiva), t'avrei dimostrato che si sarebbe ridotta anch'essa al problema dell'arresto. Com'è ovvio (almeno per me) che sia.

Per quanto già detto, non ne ho affatto bisogno. Stai soltanto nonché malamente cercando di ribaltare la frittata spostando l'onere della dimostrazione a me, che ne ho già fornito una inattaccabile.

Anche se il 100% degli esperti di sicurezza fosse d'accordo con te, rimarrebbero opinioni personali. Perché NESSUNO di loro è in grado di smontare la mia dimostrazione. Come, peraltro, di fornire una definizione OGGETTIVA e INCONTROVERTIBILE di sistema / software "sicuro".

Ed è bene che tu ne cominci a prenderne atto.

Ti ho detto più volte che non sono interessato a una dimostrazione delle mie affermazioni anche perché non è matematicamente possibile sei tu che vuoi una dimostrazione.
Ti ripeto (ultima volta) il mio punto di vista basato sull'analisi dei dati a disposizione:
Essere open source (avere il codice sorgente a disposizione di tutti) è una condizione necessaria affinché un programma sia sicuro (possa essere valutata la sua sicurezza). Non è una condizione sufficiente come dimostrano alcune falle su openSSL e linux.

Dato che la matematica non può dimostrare questa affermazione in modo formale occorre utilizzare il metodo sperimentale usato nella scienza.
Quante teorie scientifiche esistono che non sono dimostrabili matematicamente, ma che si applicano ai dati e alla realtà dei fatti?! Praticamente tutte.
Prendiamo la fisica, quando una teoria considerata valida (meccanica classica) non riesce a spiegare il motivo di un nuovo fenomeno (corpi che viaggiano alla velocità della luce), occorre rivederla, eventualmente estenderla (meccanica relativistica) o formularne una nuova.
Torniamo al nostro caso: esiste un solo esempio reale che invalidi l'affermazione precedente e quindi lo renda non valido?!
Ovvero che essere open source (avere il codice sorgente a disposizione di tutti) non è una condizione necessaria affinché un programma sia sicuro.

Inoltre, non ho mai visto nessuno ricercatore di sicurezza affermare il contrario.
La quasi totalità afferma che essere open source è una condizione necessaria, qualche eccezione afferma che questo è un fatto secondario e che la licenza non conta.

Originariamente inviato da cdimauro

How many lines of code are in the Linux kernel?:

"9,868,933 lines of code, 12,020,528 lines with comments included, spread over 36,595 unique files.

Breakdown by language

C - 7,896,318 lines, 16,397 files
C/C++ Header files - 1,629,064 lines, 13,542 files
Assembly - 250,097 lines, 1,231 files"

Mi son fermato ai primi 3 che sono i più rilevanti. Lascio a te il calcolo del 10-20% di cui sopra, e se sei in grado di fornire una dimostrazione formale della sicurezza di Linux su questa base.

Anticipo una possibile nonché realistica risposta, a beneficio di chi legge il thread e che risulta digiuno in materia: su quella enorme base di codice, puoi soltanto fare un atto di fede nell'affermare che Linux sia "sicuro".

Vuoi dimostrare anche il principio di Pareto?! Non esiste una dimostrazione formale nemmeno per questo.
Questo principio è un punto di partenza valido e applicato nella realtà, non solo in informatica.
Vorresti fare un audit del codice di linux adesso quando il codice sorgente è una creazione di oltre 25 anni?
L'operazione è fattibile, ha un costo in termini di tempo e denaro. Il principio di Pareto afferma che è sufficiente controllare il 10-20% del codice per avere la sicurezza che il 90-80% del codice sia esente da bug. Se vuoi raggiungere il 100% di sicurezza, lo devi analizzare tutto.
Stesso ragionamento vale nell'ottimizzazione del codice per renderlo più efficiente.

Originariamente inviato da cdimauro

Ma anche prendendo software di gran lunga più semplice e piccolo come TrueCrypt, che in passato è stato citato come software che è stato dimostrato essere formalmente sicuro, ho già avuto modo di evidenziare notevole pecche / lacune dell'audit, e che infine gli stessi autori caldeggiassero una verifica formale.

Questo per ribadire l'ovvietà: il 10-20% di codice di cui parli rimane comunque TROPPO.

Non ho ben capito: prima dici che TrueCrypt è stato citato come software dimostrato formalmente sicuro e poi che gli autori volessero una dimostrazione formale?
Il 10-20% è troppo?! Conviene fare una verifica formale o analizzare il 10-20% del codice critico in termini di tempo e soldi?

Originariamente inviato da cdimauro

A parte il fatto che adesso sei scaduto nella mistificazione cercando di mettermi in bocca cose che non mi sono mai sognato di dire/negare, la questione primaria è e rimane l'ACCESSIBILITA' dei sorgenti.

Mentre tu continui a farne una battaglia ideologica open vs closed, che non c'entra nulla nei riguardi dei termini della questione, oltre al fatto che ho DIMOSTRATO essere falsa.

Misitificazione?!
Come ti ho detto N volte con N molto grande , essere open source (qualunque licenza) per definizione rende disponibili il codice sorgente a tutti cosa impossibile con closed source. Per questo essere open source ovvero avere il codice sorgente è una condizione necessaria.

Originariamente inviato da cdimauro

Su questo mi sono già espresso: SE fosse come riporti (e ho i miei dubbi, visto che ti è molto facile mettere in bocca alla gente cose che non si sono sognate di dire. E che peraltro non sarebbero qui a correggerti), sarebbero in ogni caso in torto, visto che ho DIMOSTRATO che tale asserzione sia falsa.

Per vedere cosa riporto in bocca, basta leggere quello scritto nei messaggi precedenti.

Originariamente inviato da cdimauro

E invece sì, visto che le asserzioni sono passibilissime di essere smontate. Non stiamo parlando di frutta e verdura, o roba da bar dello sport, ma di questioni squisitamente tecniche. Anzi: matematiche.

Vedi sopra riguardo ai miei dubbi su ciò che riporti, e rimane in ogni caso la mia DIMOSTRAZIONE.

Certo, infatti tutte le teorie scientifiche reali, invenzioni e in generale tutto cià che funziona e si applica alla realtà è dimostrabile...

Originariamente inviato da cdimauro

Non è nemmeno una congettura, veramente. Le congetture, come già detto, si basano su (NUMEROSI) FATTI che lasciano ipotizzare/costruire induttivamente una certa via.

Qui finora sono soltanto spese parole, al massimo del tutto autoreferenziali: tizio ha detto questo e quest'altro. Chiacchiere.

Ovvio: so bene che è impossibile averla.

Il che non significa nulla riguardo ai termini della questione.

Oltre al fatto che, prendendo in prestito queste tue parole, le potrei benissimo e tranquillamente applicare a qualunque software, anche closed.

Una congettura è una affermazione o un giudizio fondato sull'intuito, ritenuto probabilmente vero, ma non dimostrato. Cioè un'ipotesi.
In matematica il termine trova un'applicazione quantomai appropriata: una congettura matematica è infatti un enunciato formulato da uno o più matematici che lo ritenevano probabilmente vero, per il quale non è tuttora conosciuta una dimostrazione.

L'informatica è piena di congetture ed euristiche...

Dove sarebbe il problema? Riportami dove ho detto di voler dimostrare qualcosa? Tu sei fissato con dimostrazioni non dimostrabili.
L'evidenza dei fatti fa dedurre quanto affermato da me in precedenza anche in questo messaggio, poi puoi benissimo credere a quello che vuoi.

Originariamente inviato da cdimauro

Detto in altri termini: ti stai smentendo con le tue stesse mani.

Vediamo adesso cosa t'inventerai per sostenere le tue asserzioni. Perché non ti rimane altro che inventare, considerato che risulta piuttosto evidente che tu non abbia le competenze / conoscenze per affrontare argomenti come questi.

Risulta evidente una cosa: tu ti ostini a chiedere una dimostrazione formale di una cosa che non può essere dimostrata come hai fatto notare anche più volte.
Io sto cercando di farti vedere la realtà oggettiva dei fatti, supportata da quasi la totalità dei ricercatori di sicurezza (non ne ho trovati con pareri contrari, riportali se ne conosci), ovvero che avere un software open source è necessario affinché il software sia sicuro.
Solo avendo il codice sorgente è possibile verificare la validità del programma. Questo non è possibile con un codice closed source.

[Erotavlas_turbo]

Originariamente inviato da ambaradan74

C'e' poco da farsi infiniti labirinti conditi di matematica e dimostrazioni booleane.

Per descrivere la realta' la logica "if than else" non e' sufficiente, manca totalmente la premessa, ovvero l'accessibilita' al codice, fortemente limitata nel caso di licenza chiusa.

Open Source e' un vantaggio per la trasparenza e quindi, di riflesso, anche per la sicurezza.

Esattamente. Considerate questo link dove vengono riportate le idee di alcuni esperti di sicurezza informatica.
Sono tutti concordi nell'affermare che l'accesso al codice sorgente è necessario per valutare la sicurezza. Quindi essere open source è necessario, ma non sufficiente (come dimostra Heartbleed anche se qualcuno lo conosceva già da subito, NSA conosceva usava già la falla da due anni prima che divenisse pubblico, forse lo avevano aggiunto loro...).
Inoltre, più persone, aziende, entità possono accedere al codice sorgente e più alta è la possibilità di trovare difetti rispetto a un codice chiuso disponibile al produttore e a poche persone, aziende per una verifica.
Questi sono fatti evidenti e innegabili è la realtà (non occorrono dimostrazioni impossibili o altro). Nessuna persona ragionevole può negarlo.

[Erotavlas_turbo]

Originariamente inviato da ambaradan74

E aggiungo una cosa.
Non che non si faccia o che non sia stato fatto, ma un codice open scoraggia ad inserirvi un codice malevolo proprio perche' piu facilmente ci si espone alla possibilita' di un analisi.

Inoltre il codice closed spesso e' accompagnato da ben precisi business model molto borderline circa la gestione della privacy, come nel caso di WA.

Esatto.

[GTKM]

Comunque, il movimento "originale" è il Free Software. L'Open Source è la versione "epurata dalla parte politica", che però è stata fondamentale per la nascita di GNU (anzi, HA creato GNU).

Quindi non fate arrabbiare Stallman, e supportate il Free Software.

[GTKM]

Originariamente inviato da Bellaz89

Oddio, e' un po come dire che l'ebraismo ha creato il cattolicesimo...

https://www.gnu.org/philosophy/open-...-point.en.html

[GTKM]

Originariamente inviato da Bellaz89

Mi riferivo (ovviamente) a questa parte della tua frase.

Mi è uscita male la frase mi sa: intendevo che GNU è nato esclusivamente per la questione ideologica. L'open source, invece, si limita a pubblicizzarsi come modello di sviluppo, volendo far credere che, tecnicamente, un software open è sicuramente meglio di un software closed, cosa non necessariamente vera.
Il movimento open source, ripeto, è solo una brutta copia del free software, che piace di più in ambito business perché elimina tutta la parte ideologica.

[matteop3]

Ad essere onesti ho letto le motivazioni che spingevano gli sviluppatori di determinati software (ad esempio Open Whisper Systems, ma ce ne sono altre) ad adottare la licenza GPLv3 che ho trovato comprensibili e non ideologiche, ovvero il controllo qualità.

Per esempio OWS ritiene la GPLv3 il modo più semplice e pratico per poter verificare loro stessi come il proprio protocollo crittografico venga integrato all'interno di software terzi e allo stesso tempo permetterne l'utilizzo.

In questo caso può essere comprensibile per due ragioni:
- per compromettere il funzionamento del protocollo non è necessario modificare il codice del protocollo stesso, ma sono sufficienti bug o backdoor all'interno del codice in cui lo si integra, quindi l'appurare semplicemente che il codice del protocollo non sia cambiato non significa necessariamente che funzioni;
- per tutela della propria immagine; in caso di scandali relativi a software che utilizzano male il loro protocollo anche loro ne risentirebbero (vedi la presunta backdoor di WA).

Lecito sarebbe chiedersi perché allora software come WhatsApp, Facebook Messenger e Google Allo non siano a loro volta open source, visto che utilizzano Signal Protocol. Buon senso e pragmatismo. Dato l'enorme bacino che hanno questi tre servizi, danno maggior priorità al fatto che il loro buon protocollo si diffonda il più possibile piuttosto che all'ideologia di base. In questi casi immagino che OWS abbia potuto personalmente controllare come il codice sia stato integrato nelle tre app, non potendo ovviamente pretendere che venissero rilasciate a loro volta con licenza GPL.