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

[GTKM]

Originariamente inviato da ambaradan74

Io non leggo certo il codice di nulla, ma certamente mi fido di piu ad usare un software aperto che uno chiuso.

Sarebbe un po scemo uno che immette un codice malevolo in un programma di cui poi ne rende pubblico il codice.

E come dice Erotavlas_turbo:
"per verificare la sicurezza di un software occorre avere il codice sorgente. Un software open source ha il sorgente disponibile per tutti, un software closed source ha il sorgente disponibile per pochi"

Non me ne frega niente che TUTTI possano leggere il sorgente, quando comunque sempre gli STESSI POCHI potranno capirlo e analizzarlo.

Questa cosa, a quanto pare, continua a sfuggire.

La sicurezza di un software si basa sulla validità degli algoritmi e sulla loro corretta implementazione, mica dalla licenza con cui vengono distribuiti.

[GTKM]

Originariamente inviato da ambaradan74

Quindi state dicendo che e' piu sicuro il codice chiuso.

ok..

Vi faccio allora la domandona (inerente il thread)

Come posso essere sicuro allora che WA sia sicuro e mi garantisca la privacy?

in teoria se e' vero quello che dite voi WA dovrebbe essere il massimo visto che usa appunto un codice closed.

Falso. Stiamo dicendo che non è la licenza a decidere se un software sia sicuro o meno. E i casi non mancano.

[El Tazar]

ma non vi stancate mai?

[GTKM]

Originariamente inviato da ambaradan74

Se tu mi dici:

La sicurezza di un software si basa sulla validità degli algoritmi e sulla loro corretta implementazione, mica dalla licenza con cui vengono distribuiti.

io ti chiedo:

Come faccio allora ad essere sicuro che WA implementi correttamente gli algoritmi e che siano validi?

Originariamente inviato da Bellaz89

Lungi da me entrare in questa discussione (che viene riproposta circa 1.000.000 di volte all'anno). Secondo me state parlando di due cose differenti.

Un software puo' essere bug-free ma spiarti
Un software puo' essere buggato ma non spiarti

Non mischiamo le cose

PS:

Questo caso di WA e' emblematico in questo senso: Non è che il software sia buggato, ma c'è il rischio che WA abbia inserito codice di tracciamento facendolo passare per una 'feature'.

Il punto è che solo gli esperti sono in grado di trovare cose del genere.

Che, gira e rigira, sono gli stessi, sia nel caso di software closed, che in caso di open.

Se poi parliamo di fiducia, ovvio che non ci si possa fidare più di tanto di WhatsApp per la privacy, visto che ormai appartiene ad un'azienda che campa e prospera proprio facendosi i cavoli altrui.

[matteop3]

https://www.schneier.com/blog/archiv...pp_securi.html

How serious this is depends on your threat model. If you are worried about the US government -- or any other government that can pressure Facebook -- snooping on your messages, then this is a small vulnerability. If not, then it's nothing to worry about.

[Erotavlas_turbo]

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."

Mi sembra la soluzione migliore per whatsapp per riacquistare un minimo di credibilità (telegram ha seguito la stessa strada: app open source e server closed source).
Personalmente dopo l'annuncio di scambio dati con facebook intorno settembre (poi bloccato dopo aver scambiato i dati), ho cancellato il mio contatto whatsapp e raccomando di usare signal, wire o telegram.

[GTKM]

Se Facebook rilasciasse il sorgente dell'app forse si capirebbe quanto si siano impegnati per renderla così pesante.

[cdimauro]

Originariamente inviato da ambaradan74

Scusate ma non capisco il senso di dover dimostrare matematicamente o logicamente questo di cui state parlando.

A me pare di una semplicita' disarmante la faccenda.

Un software chiuso non e' controllabile perche non si ha a disposizione il codice per vedere che cacchio c'e' dentro.

Quindi il problema non e' se sia sicuro o no, ma se io so o non so se sia sicuro o meno.

La faccenda, in effetti, è di una semplicità disarmante come affermi: del software chiuso i sorgenti non li hanno a disposizione tutti, ma soltanto chi ci lavora o chi ne ha accesso, come purtroppo ha cercato (invano, viste le successive repliche) di spiegare GTKM.

Ciò che conta, e lo ribadisco per l'n-esima volta, è che di un software si possa accedere al sorgente per controllarlo. Ovviamente da parte di persone competenti.

La distinzione fra closed e source riguarda, invece, la mera DISTRIBUZIONE dei sorgenti: la prima è limitata, la seconda no.

Il che NON implica nulla in ambito sicurezza. Se, cioè, un software sia "sicuro" o meno. Dunque a prescindere dal modello di distribuzione dei suoi sorgenti.

Infine la percezione personale è un'altra cosa ancora. E vale quanto una discussione da bar dello sport...

Originariamente inviato da ComputArte

LEGENDA

= sono le tue affermazioni che tentano , senza speranza alcuna, di difendere entità di diritto privato che stanno facendo un SOVRA-profitto ( non meritato ) spiando tutto e tutti. La profilazione incrociata raccoglie “metadati” che incrociati con altri “metadati” diventano dati più che sensibili.
La difesa che fai di ufficio potrà trovare plauso per chi ha interesse a negare questa realtà, ma la gente comune ha iniziato a dubitare delle “pubblicità” autoreferenziali di queste aziende e di chi, come te, sta tentando di difenderle....sta iniziando la CONSAPEVOLEZZA

PS. ho scelto la faccina mentre sorseggiavo un thè preparato con la teiera cosmica

Le solite mistificazioni & complottismi con cui ami condire le tue filippiche. Nulla di nuovo...

= idem con patate come per il tuo collega che a spada tratta continua a sostenere che un sw CHIUSO sia sicuro perchè lo afferma chi lo “offre gratuitamente”...

Ancora mistificazioni e falsità.

E non è un mio collega.

Ma ci sarà o no, una differenza fra mala fede e buona fede?!

In effetti è una cosa che, detta da te, può soltanto provocare una mistura di emozioni, che spaziano fra ilarità e disgusto, visto che sei un ossimoro vivente: parli di buona fede quando con le tue mistificazioni e falsità operi sistematicamente in mala fede.

Ci sarà una differenza fra chi può commettere un errore di compilazione su un sw aperto che configura un bug da sfruttare per penetrare illegalmente un sistema, da chi compila codice CHIUSO non trasparente, IMPEDENDO un controllo, perchè "magari" l'aspetto di NON sicurezza emerge dal raccogliere illimitatamente TUTTI i dati trasnsitanti per la piattaforma ?!
Se poi a ciò si aggiunge il FATTO che chi sta offrendo questo codice CHIUSO non lo fa dietro una remunerazione che giustificherebbe il mantenimento del segreto sul codice , ma lo offre GRATUITAMENTE....perchè EVIDENTEMENTE il modello di business è un altro....”forse” la profilazione incorciata allo scopo di brokeraggio dati REMUNERATO?!
...o sul tuo pianeta tutto ciò non esiste?!

Nel mio pianeta queste si chiamano ipotesi. Nel tuo certezze (ma senza prove).

Hai risposto precedentemente con un commento condito soltanto di faccine. Dunque NON hai argomentato.

Ti si fa notare che, a motivo del contenuto NULLO del tuo commento, NON hai argomentato. Sic et simplicter.

E che fai? Rispondi un'altra faccina in tema.

Direi che ti commenti da solo.

...chiaro e lampante...tranne per chi sta tentando di "strumentalizzare" uno strumento formale per giustificare un punto di vista insostenibile...

In tal caso sei liberissimo di smontare la mia dimostrazione: accomodati pure.

Altra faccina per nascondere il nulla, visto che non sei in grado di argomentare.

Questa "tua" dimostrazione pone in luce l'autoreferenzialità delle tue affermazioni basate unicamente sulla procedura della "dimostrazione".... ...la realtà è ASSAI più complessa

La realtà è che un tizio fa un'affermazione X, che ho DIMOSTRATO (senza virgolette) di essere falsa.

Poi che a te non piaccia è ovvio, visto che non appena si parla di dimostrazioni ai complottisti come te viene un travaso di bile e partono per la tangente (o spariscono del tutto).

Ribadisco: se c'è qualcosa che non ti quadra in quella dimostrazione sei liberissimo di smontarla, eh! E prenditi pure tutto il tempo che vuoi.

Nel frattempo, se nessuno la smonta, rimane perfettamente valida, e tentare di sminuirla con vuote parole o balletti arzigogolati dimostrerà soltanto la propria incapacità di poterla attaccare.

senza una rappresentazione REALISTICA della dinamica di mercato le tue equazioncine sono e rimangono irrealistiche...

E che c'entra adesso la "dinamica di mercato" (che vuoi dire con questo? Sii chiaro) con quella DIMOSTRAZIONE? NULLA, appunto.

Stai cercando disperatamente di cambiare discorso, in quanto non sei in grado di smontarla.

Adesso la uso io la faccina a te cara:

...finalmente una affermazione che pone il "problema" per tutto ciò che è CHIUSO...
...o ancora vuoi "intortare" la discussione farneticando di azioni di ingegneria inversa?!?! ( sempre nel mondo reale, considerando le "condizioni al contorno" come lo spazio ed il tempo...

GTKM ha già cercato di spiegare la questione. E dunque no: non si stava parlando di reverse engineering. Ma di pura e semplice ACCESSIBILITA'.

Ingegneria inversa che, peraltro, è possibile, ovviamente. Ma è un ALTRO discorso. Sebbene sia attinente, visto che è un altro modo di accedere alle informazioni di cui parla.

...proprio a questo mi riferivo...il concetto di sicurezza non è inteso "erga omnes"...ma nello specifico caso che lo stesso autore del codice che rimane RIGOROSAMENTE CHIUSO, a fronte del modello di business acclarato, non inserisca VOLUTAMENTE una o più backdoors, per DIFENDERE la sua capacità di generare profitto dalla compra-vendita di informazioni profilate e profilanti....

Queste sono ipotesi, e non certezze. Puro complottismo, senza prove a riguardo.

Quindi rendendo notevolmente più complessa la tua dimostrazione "semplicistica", vedrai che il risultato è opposto a quello che stai tentando, senza riuscirci, di proporre come IL VERBO...

E di nuovo: no! La mia dimostrazione rimane vera a prescindere dai tuoi tentativi di sminuirla con discorso che non c'entrano nulla.

Ma ripeto: sei liberissimo di smontarla. SE ci riesci. Io son qui che aspetto, eh!

Originariamente inviato da Opteranium

Seguendo questa logica, se da x cambio una virgola e lo rendo insicuro, tu che lo copi e generi il closed y avresti un software che sembra sicuro ma non lo è (e di cui non puoi sincerartene dato che è solo un binario) mentre avendo a disposizione i sorgenti di x sarebbe possibile notare l'errore e correggerlo.

E' possibile notare l'errore a prescindere, da parte di chi ha accesso ai sorgenti di Y. Ossia gli sviluppatori di questo software, ma non solo (ad esempio un ente / agenzia / azienda che si occupa di sicurezza).

Fermo restando che se qualcuno trova questo bug per x, lo segnala, e viene corretto con rilascio dei sorgenti, chi ha creato y può tranquillamente aggiornare quest'ultimo e rilasciare dei binari aggiornati.

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?

A me sembra palese che un software debba innanzitutto essere open per poter dare migliori garanzie di sicurezza e trasparenza.

Opinabile. La mia dimostrazione verte proprio nello smontare questo luogo comune.

Senza contare, poi, i casi reali citati da GTKM, verificatisi proprio con software open...

Originariamente inviato da Erotavlas_turbo

Esatto, purtroppo è difficile farlo ammettere agli amanti del software proprietario.

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.

[cdimauro]

Originariamente inviato da Erotavlas_turbo

Ti ha già risposto l'utente Opteranium con un obiezione che dimostra il non senso di voler avere questa dimostrazione.

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

La dimostrazione matematica da te proposta, matematicamente è corretta, ma ha validità teorica.

Anche pratica. Vedi la risposta di cui sopra.

Ha i seguenti problemi reali e pratici:

1. Per poter affermare che y sia sicuro in quanto compilato da x, occorre avere il sorgente di x.
2. Nel caso il sorgente di x non fosse disponibile, chi ti garantisce che y sia il binario derivato dalla compilazione del sorgente di x? Il programmatore? Ente terzo?

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.

In ogni caso non c'è trasparenza come per un codice open source.

Se vogliamo parlare di Teoria della calcolabilità, inutile visto il non senso della dimostrazione,

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.

dobbiamo considerare il teorema di Rice e non il problema dell'arresto: there exists no automatic method that decides with generality non-trivial questions on the behavior of computer programs.

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.

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

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.

Escludendo il fatto che esistono anche congetture che non sono decidibili, non ho mai trovato affermazioni contrarie a quanto riportato in precedenza:
Un software di sicurezza ha come condizione necessaria essere open source.
Riportami anche solo le parole di un solo esperto di sicurezza che afferma il contrario, non sono riuscito a trovarlo.

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.

Non regge.

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.

Non ha senso controllare tutto il codice, ma solo le parti critiche che nella pratica sono circa il 10%-20% dell'intero codice secondo il principio di Pareto (non è dimostrabile nemmeno questo, ma l'evidenza pratica lo rende utilizzabile).

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".

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.

Abbiamo capito che la tua è una lotta contro open source a favore del software proprietario. Almeno ammetti la realtà dei fatti: per verificare la sicurezza di un software occorre avere il codice sorgente. Un software open source ha il sorgente disponibile per tutti, un software closed source ha il sorgente disponibile per pochi.
Tu ti fidi, vista la storia recente e i vari scandali? Bene, contento tu...

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.

Non è necessaria nessuna dimostrazione per affermare quello che affermano tutti gli esperti di sicurezza e non: la via per avere un programma sicuro è open source.

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.

Non è una lotta a chi smonta l'altro.

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.

Una domanda: ti sei mai chiesto perché i ricercatori di sicurezza affermano quanto riportato da me nei vari messaggi precedenti?!

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

Adesso spero sia chiaro che non è un teorema, al massimo una congettura, non è necessario dimostrare l'evidenza pratica.

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.

Se vuoi una prova matematica non l'avrai mai,

Ovvio: so bene che è impossibile averla.

molti software funzionano correttamente senza una prova matematica.

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.

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.

[cdimauro]

Originariamente inviato da ambaradan74

A me pare un contraddizone, ma lo chiedo proprio per ingnoranza mia, senza polemica.
Se un sorgente non viene distribuito (perche closed) come faccio a sapere se dentro c'e' per esempio un malware?
Sara' piu facile tenere sotto controllo un software open?

Più facile solo se hai occhi a controllare E che questi occhi siano esperti. Vedi le risposte di GTKM in merito, che erano già sufficienti a dirimere la questione.

Per il resto avevo comunque risposto nel commento che hai quotato: un software chiuso è comunque accessibile dai suoi creatori (ovviamente) e da enti / aziende che hanno il permesso di analizzarlo.

E questo senza nemmeno tirare in ballo il reverse engineering.

[GTKM]

Originariamente inviato da ambaradan74

Quindi te dici, siccome tanto il software open forse non lo guarda nessuno allora tanto vale usare quello chiuso.

Mi pare proprio una buona strategia che mette al centro liberta e sicurezza..

Continui a non capire.

Il punto è che la sicurezza del software non ha niente a che vedere con la licenza con cui viene distribuito.

Ciò che conta sono le verifiche degli esperti, che sono gli stessi sia nel caso di software closed che open.

Migliaia di persone che non hanno idea di come si analizzi un algoritmo, producono lo stesso risultato di zero persone che analizzano lo stesso: il nulla più assoluto.

[GTKM]

Originariamente inviato da ambaradan74

il problema è che solo chi detiene i diritti sul software closed può analizzarlo e studiarlo.
Mentre in caso di open viene messo a disposizione il codice.

Quindi come fate a dire che la licenza non incida sulla questione sicurezza non lo so.

Ripeto: Linux e OpenSSL.

Ma non solo: come fanno gli esperti (per esempio di Google) a trovare le falle di Windows? Le trovano, e le rendono pubbliche. Eppure il codice è ben protetto da Microsoft.

[GTKM]

Originariamente inviato da Bellaz89

Senza scomodare tutte le questioni riguardanti la NSA, guardiamo per esempio lo scandalo VW.

Qui abbiamo un software che e' stato intenzionalmente programmato per falsare alcuni test.
Se fosse stato di dominio pubblico il sorgente non credo che VW avrebbe messo nero su bianco che stavano commettendo un crimine e probabilmente tutto questo non sarebbe mai successo.

E se questo e' accaduto nel controllatissimo settore auto, viene il sospetto che cose simili avvengano anche in altri settori dove l'utilizzo di un determinato software e' critico.

Certo, si puo' pensare a un organismo di controllo nazionale o sovranazionale per evitare che le aziende facciano questo tipo di giochini ( dal falsare i dati delle emissioni, a lasciare backdoor nel codice) per evitare alle aziende stesse di rilasciare il codice come open source, ma mi sembra francamente una cosa poco pratica da fare in maniera estensiva.



Una falla e' diversa da una backdoor, e anche se qualcosa puo' essere trovato studiando solo il binario certe analisi senza il sorgente sono eccessivamente complicate da fare.

Ma il codice può anche essere reso praticamente illegibile.

Se domani, ad esempio, MS fosse costretta a rilasciare il suo sorgente, potrebbe ripulirlo da commenti e usare qualche script per modificare (è un esempio eh) il nome delle funzioni con sequenze "casuali".

E un sorgente praticamente illegibile ripropone gli stessi problemi.

Ma c'è un'altra cosa: se tu fossi COSTRETTO ad usare, per un tuo programma, una licenza che non ti piace, saresti contento? Non è una cosa molto piacevole.

Sulla questione VW la cosa è anche più complicata.

[GTKM]

Originariamente inviato da Bellaz89

Ovviamente un programma di cui viene rilasciato un sorgente offuscato non e' realmente open-source.
Quello che deve essere dato e' il codice non-offuscato usato in produzione in formato human-readable.



La contentezza o non contentezza dell'azienda e' off-topic (e comunque leggi & tasse vanno rispettate anche se non piacciono, ma non per questo sono -necessariamente- 'ingiuste').

Le aziende fino ad ora (e penso ancora per molto tempo) sono state liberissime di distribuire il loro codice con licenze closed.
Alla stessa maniera io sono liberissimo di non usufruire di questo codice perche' non ho voglia di credere sulla fiducia di un'entita' che ha come scopo principale il profitto.
Il problema e' quando vieni praticamente costretto dalle circostanze sociali..

Non è questione di contentezza. Non puoi obbligare un'azienda a rilasciare il SUO codice con una licenza open-source (e quale? GPL? BSD? Apache?). Così come non puoi obbligarla ad usarne una "closed".
Tu da sviluppatore sei libero di scegliere la licenza che vuoi per il TUO software.

Da utente se libero di scegliere quello che vuoi, ovviamente. Le circostanze sociali non sono causate dalla licenza. Purtroppo la gente usa WhatsApp, quindi o chiedi ai tuoi contatti di usare un software che preferisci, o ti adatti a loro, oppure resti con le telefonate e gli SMS.

I controlli rigidi ci vogliono sui sistemi "mission critical", ma anche lì non è una questione di sorgenti liberi, ma di garantire l'accesso al codice agli esperti.

[cdimauro]

Originariamente inviato da ambaradan74

Quindi te dici, siccome tanto il software open forse non lo guarda nessuno allora tanto vale usare quello chiuso.

Mi pare proprio una buona strategia che mette al centro liberta e sicurezza..

Non mi pare di aver detto questo. Non salire anche tu sul carrozzone dei mistificatori, se ti premere informarti correttamente.

Ancora una volta GTKM ha esposto chiaramente i termini della questione.

Originariamente inviato da Bellaz89

Senza scomodare tutte le questioni riguardanti la NSA, guardiamo per esempio lo scandalo VW.

Qui abbiamo un software che e' stato intenzionalmente programmato per falsare alcuni test.
Se fosse stato di dominio pubblico il sorgente non credo che VW avrebbe messo nero su bianco che stavano commettendo un crimine e probabilmente tutto questo non sarebbe mai successo.

E se questo e' accaduto nel controllatissimo settore auto, viene il sospetto che cose simili avvengano anche in altri settori dove l'utilizzo di un determinato software e' critico.

Certo, si puo' pensare a un organismo di controllo nazionale o sovranazionale per evitare che le aziende facciano questo tipo di giochini ( dal falsare i dati delle emissioni, a lasciare backdoor nel codice) per evitare alle aziende stesse di rilasciare il codice come open source, ma mi sembra francamente una cosa poco pratica da fare in maniera estensiva, oltre che lasciare dubbi sulla buona fede del controllore.

Certamente, ma i casi esposti non implicano che siano la totalità / generalità.

Un bug e' diverso da una backdoor lasciata intenzionalmente, e anche se qualcosa puo' essere trovato studiando solo il binario certe analisi senza il sorgente sono eccessivamente complicate da fare.

Dipende. In genere le backdoor sono più facili da trovare rispetto a falle di sicurezza, perché c'è codice infilato appositamente per alterare alcune funzioni dell'applicazione.

Backdoor complicate da rilevare ce ne possono essere, invece, in sistemi di generazione della chiave per la crittazione, ad esempio, dove puoi alterare i dati che costituiscono la chiave in maniera da ridurre molto i tempi di cracking. E' roba difficile da scovare perché il diavolo si nasconde molto bene nei (complicati) dettagli.

Avere il binario non dara' mai tante informazioni quante ne da il sorgente, questo e' un dato di fatto.(altrimenti le discussioni su open e closed source non avrebbero proprio senso di esistere)

Vero. Ma in compenso guardare il codice composto da istruzioni disassemblate può portarti a vedere le operazioni eseguite con una visione completamente diversa, che a volte ti fa vedere cose che non noti col sorgente originale.

Originariamente inviato da Bellaz89

Ovviamente un programma di cui viene rilasciato un sorgente offuscato non e' realmente open-source.
Quello che deve essere dato e' il codice non-offuscato usato in produzione in formato human-readable.

Su questo ci sarebbe di che discutere. Se ti fornisco un sorgente che, una volta compilato, genera poi il binario che un qualunque utente può usare tranquillamente, ritengo che la definizione accademica / formale di codice sorgente e codice oggetto siano perfettamente soddisfatte.

Tempo fa avevo già tirato in ballo l'offuscamento parlando di cose simili, e avevo cominciato a scrivere uno scriptino Python per generare codice offuscato partendo da codice "normale".

La mia idea è quella di fornire un tool alle aziende che fanno uso (consapevole o meno) di codice affetto da licenze virali, che consenta loro di distribuire le modifiche apportate ma in maniera che queste sia del tutto inintelligibili, rendendo di fatto del tutto vana la suddetta viralità (il codice modificato, sebbene rilasciato, sarebbe inutilizzabile ai fini della visione di ciò che fa). Ovviamente tutto rimarrebbe perfettamente legale.

Devo dire che l'idea di tempo fa si è (perversamente ) evoluta nel tempo, e credo si possa arrivare a livelli di indecifrabilità tipici di un binario disassemblato, pur rimanendo nell'ambito di un sorgente scritto in un linguaggio come C o C++.

Peraltro sfruttando l'operazione di offuscamento si può facilmente tirare fuori un'altra dimostrazione (anch'essa formale) che invalidi ancora una volta l'assunto citato in precedenza sempre dall'utente a cui ho fornito l'altra.

Originariamente inviato da Bellaz89

No, guarda io non voglio obbligare niente e nessuno.

Pero' il fatto che il codice open-source ti metta generalmente piu' al riparo di quello closed dall' avere backdoors intenzionalmente lasciate dal creatore e' un dato di fatto.

E' anche un dato di fatto anche la macroscopica backdoor lasciata aperta dagli sviluppatori di Debian per la loro implementazione di OpenSSH:

Si, ma questo non toglie il fatto che uno debba fare un atto di fiducia nei confronti dell'azienda che puo' modificare il codice come e quando gli pare senza dare conto a nessuno.

Vero. Il che, però, non implica necessariamente che il suo codice non sia "sicuro" o che abbia backdoor.

[cdimauro]

Originariamente inviato da Bellaz89

Beh, accademicamente parlando e' corretto, ma di fatto un codice per essere ritenuto realmente open-source deve rispettare alcuni parametri in fatto di qualita'. Poi ognuno ha i suoi standard per definire cosa e' accettabile o cosa non lo e'. Ma fornire codice offuscato non e' in generale una pratica ben vista.

Questo lo sa, ma a me non interessa di essere ben visto.

Comunque non credo che il tuo progettino di offuscamento sia valido con la GPL(altre licenze non so):

Dal paragrafo 1

E questo proprio per evitare che codice offuscato possa aggirare la licenza.

Sì, questo serve effettivamente per tutelarsi dall'offuscamento del codice, ma credo ci sia una scappatoia, sebbene più complicata.

Dovrebbe essere sufficiente mantenere i sorgenti coperti da GPL in maniera separata da quelli che li andranno a patchare per generare poi i binari finali.

Prima della compilazione utilizzi il tool di cui parlavo per offuscare il codice GPL, poi i file della patch, e infine esegui il merge della patch al codice GPL. A questo punto puoi compilare per tirare fuori l'eseguibile.

Richiede molto più lavoro, ma dovrebbe funzionare.

Che ti devo dire. Sfiga. Anche perche' il bug e' nato da un utilizzo non avveduto di un tool di sanitizzazione.
Purtroppo questi errori sono possibili(e accadono!) indipendentemente dal modello di sviluppo utilizzato, a tutti.
C'e' comunque da riflettere che il team di debian si premura di fare test di sanita' su codice non prodotto da debian stesso. E questo probabilmente accade per le altre maggiori distro.

Senz'altro, ma... capita, per l'appunto. Perché gli sviluppatori sono esseri umani, e gli errori li commettono a prescindere che lavorino su codice open o closed.

Un altro esempio di qualche anno fa: Scoperta vulnerabilità Null Pointer nel kernel Linux

[GTKM]

Originariamente inviato da Bellaz89

Mah, anche cosi, non mi sembra la "preferred form of the work for making modifications to it".
Cosi' ad occhio nessun giudice ti darebbe ragione in un processo.
Comunque se ci credi vai, al massimo verra' fatta la GPL 4 ma dubito che ce ne sara' il bisogno(e magari qualche soldino entra in qualche progetto GPL dalle cause vinte ).

Al momento Stallman è troppo impegnato con Trump e altro, non penso abbia in agenda una nuova licenza.

Fonti: le sue email.

[aqua84]

Originariamente inviato da cdimauro

Backdoor complicate da rilevare ce ne possono essere, invece, in sistemi di generazione della chiave per la crittazione, ad esempio, dove puoi alterare i dati che costituiscono la chiave in maniera da ridurre molto i tempi di cracking. E' roba difficile da scovare perché il diavolo si nasconde molto bene nei (complicati) dettagli.

bè basta pensare alla notizia di non molti giorni fa della coppia fratello-sorella e l'"Occhio Della Piramide" che girava da oltre otto anni e NESSUN antivirus si era mai accorto della sua presenza.

[YetAnotherNewBie]

Secondo me, a monte di tutto, manca una autorità che stabilisca i requisiti di un sistema e le procedure per certificarlo.

Nel caso in oggetto, dalla notte dei tempi ci siamo scambiati messaggi su WhatsApp in chiaro.
Poi il Signor WhatsApp ha deciso, per sua bontà, di farci la grazia delle cifratura end to end; ma si è tenuto una porta aperta sui propri server in modo da accedere in chiaro alle informazioni scambiate fra i clienti per farne uso a lui (WhatsApp) gradito.
Tutto questo è cosa buona e giusta?
Si, fintanto che le regole vengono dettate e realizzate da un soggetto privato (WhatsApp per esempio) che se la canta e se la suona.

Se invece esistesse una autorità terza, avremo:
- regole scritte alle quali un qualsiasi privato si deve attenere per fornire un servizio;
- un ente al quale il privato sottopone il proprio *lavorato* per avere l'autorizzazione a distribuirlo.

In questo caso specifico, avremo definito che cosa è richiesto ad un servizio di messaggistica e le procedure per verificarne la corrispondenza con le specifiche.

Nella fase di verifica, la natura aperta o chiusa del codice è irrilevante.
Se il sorgente fosse chiuso, verrà firmato fra le parti un NDA (non disclosure agreement) che tuteli la non divulgazione del codice.
Quello che è certo, è che, per essere valutato, il sorgente stesso (aperto o chiuso) dovrà essere accompagnato da dettagliata documentazione e rispettare precisi canoni di qualità (altro che offuscamento), verificabili da appositi strumenti di analisi statica automatica, senza i quali l'applicazione non verrà neanche presa in considerazione.

Invece, quello che succede oggi è che, per esempio, il mio falegname si sveglia, decide di aprire un furum su un server offshore, si para il sedere definendo qualche migliaio di paragrafi di termini di servizio, scolpisce sui suoi mobili il testo dei post più interessanti.
Tutto perfettamente in regola.

[aqua84]

Originariamente inviato da YetAnotherNewBie

Secondo me, a monte di tutto, manca una autorità che stabilisca i requisiti di un sistema e le procedure per certificarlo.

Nel caso in oggetto, dalla notte dei tempi ci siamo scambiati messaggi su WhatsApp in chiaro.
Poi il Signor WhatsApp ha deciso, per sua bontà, di farci la grazia delle cifratura end to end; ma si è tenuto una porta aperta sui propri server in modo da accedere in chiaro alle informazioni scambiate fra i clienti per farne uso a lui (WhatsApp) gradito.
Tutto questo è cosa buona e giusta?
Si, fintanto che le regole vengono dettate e realizzate da un soggetto privato (WhatsApp per esempio) che se la canta e se la suona.

Se invece esistesse una autorità terza, avremo:
- regole scritte alle quali un qualsiasi privato si deve attenere per fornire un servizio;
- un ente al quale il privato sottopone il proprio *lavorato* per avere l'autorizzazione a distribuirlo.

In questo caso specifico, avremo definito che cosa è richiesto ad un servizio di messaggistica e le procedure per verificarne la corrispondenza con le specifiche.

Nella fase di verifica, la natura aperta o chiusa del codice è irrilevante.
Se il sorgente fosse chiuso, verrà firmato fra le parti un NDA (non disclosure agreement) che tuteli la non divulgazione del codice.
Quello che è certo, è che, per essere valutato, il sorgente stesso (aperto o chiuso) dovrà essere accompagnato da dettagliata documentazione e rispettare precisi canoni di qualità (altro che offuscamento), verificabili da appositi strumenti di analisi statica automatica, senza i quali l'applicazione non verrà neanche presa in considerazione.

Invece, quello che succede oggi è che, per esempio, il mio falegname si sveglia, decide di aprire un furum su un server offshore, si para il sedere definendo qualche migliaio di paragrafi di termini di servizio, scolpisce sui suoi mobili il testo dei post più interessanti.
Tutto perfettamente in regola.

tutto, o in parte, giusto.
ma per me, e sottolineo PER ME, la credibilità di una "autorità terza" è al pari di quella di WhatsApp (o di qualunque app in questione).

per la mia, ma credo nostra, esperienza sappiamo bene che è già successo e succederà ancora che chi deve vigilare spesso fa il gioco del vigilato, se non peggio.

certo, fossimo in un mondo perfetto in cui ci si può fidare il Vigilante farebbe SOLO il suo lavoro, anche se a quel punto, sempre in un mondo perfetto in cui ci si può fidare, non ci sarebbe bisogno di un vigilante in quanto il vigilato si comporterebbe già bene di suo.