Link alla notizia: http://www.hwupgrade.it/news/telefonia/grave-falla-scoperta-su-whatsapp-a-rischio-la-privacy-delle-chat-aggiornato_66628.html

Segnalata come "un'enorme violazione nella libertà d'espressione", una nuova vulnerabilità è stata scoperta sul sistema di crittografia end-to-end utilizzato da WhatsApp

Click sul link per visualizzare la notizia.

Mi sembra si sia arrivati a conclusioni drammatiche troppo in fretta: https://imgur.com/a/dehKb

In pratica sembra trattarsi di un'infelice scelta di design che hanno fatto i progettisti di WhatsApp per l'invio dei messaggi offline, che semplifica leggermente la vita all'utente, ma introduce una potenziale vulnerabilità; non si tratta di una backdoor. Quindi non c'è nessun reale complotto dietro e la vulnerabilità introdotta è relativamente ridotta, speriamo solo se ne rendano conto e revochino la modifica prima che qualcuno la sfrutti. In pratica sembra che WhatsApp abbia dato troppa importanza all'esperienza utente a scapito della sicurezza del protocollo.

Edit: qualche altro dettaglio riguardo al bug introdotto direttamente dal suo scopritore: https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/

ne sei così sicuro? secondo me è una scusa bella e buona

è notizia di qualche giorno fa che sul loro servizio si scambiano circa 80 miliardi di messaggi al giorno, hai idea di che infrastruttura serva per mantenere un sistema di questo tipo?
inoltre come mai facebook ha acquisito quest'app per la modica cifra di 19 miliardi di dollari se poi agli utenti non chiede neanche un cent?
sono impazziti? sono filantropi?

io non credo proprio, trovo molto piu credibile che così come fanno altre realtà, siano dietro il business dei dati, in cui vendono dati, abitudini e quant'altro a società di vario tipo e forse anche a governi

ogni società piccola o grande che sia ha un solo e legittimo scopo, fare profitto, e regalare un servizio che costa mantenerlo senza appunto chiedere compenso è una cosa che dovrebbe far riflettere

Bah che sia o no una backdoor, mai fidarsi di un software closed source.
Sarebbe anche ora che la gente lo capisse...

Mi sembra si sia arrivati a conclusioni drammatiche troppo in fretta: https://imgur.com/a/dehKb

In pratica sembra trattarsi di un'infelice scelta di design che hanno fatto i progettisti di WhatsApp per l'invio dei messaggi offline, che semplifica leggermente la vita all'utente, ma introduce una potenziale vulnerabilità; non si tratta di una backdoor. Quindi non c'è nessun reale complotto dietro e la vulnerabilità introdotta è relativamente ridotta, speriamo solo se ne rendano conto e revochino la modifica prima che qualcuno la sfrutti. In pratica sembra che WhatsApp abbia dato troppa importanza all'esperienza utente a scapito della sicurezza del protocollo.

Edit: qualche altro dettaglio riguardo al bug introdotto direttamente dal suo scopritore: https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/


Leggendo sul blog del ricercatore (https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/) che ha scoperto la falla.
Proprietary closed-source crypto software is the wrong path. After all this - potentially mallicious code - handles all our decrypted messages. Next time the FBI will not ask Apple but WhatsApp to ship a version of their code that will send all decrypted messages directly to the FBI.
Lo stesso qui (https://slashcrypto.org/2017/01/13/WhatsApp_backdoor/), non è una backdoor, ma un attacco MiM.
Non utilizzate whatsapp se ci tenete alla privacy, usate signal, wire o le chat segrete di telegram ovvero tutti software open source.

Bah che sia o no una backdoor, mai fidarsi di un software closed source.
Sarebbe anche ora che la gente lo capisse...

come se i software open fossere immuni a queste pretiche, se ti volgio mettere un backdoor voglio vedere se tu controlli milioni di righe di codice ogni giorno.
Sai quante volte hanno iniettato codice malevole in software open (adirittura nel reposotory del kernel di linux). Tu lo scarichi e lo usi mica controlli ogni volta che il sorgente sia stato modificato.

come se i software open fossere immuni a queste pretiche, se ti volgio mettere un backdoor voglio vedere se tu controlli milioni di righe di codice ogni giorno.
Sai quante volte hanno iniettato codice malevole in software open (adirittura nel reposotori del kernel di linux). Tu lo scarichi e lo usi mica controlli ogni volta che il sorgente sia stato modificato.

Certo. Per un software di sicurezza, essere open source è una condizione necessaria, ma non sufficiente.
Un software closed source è non trasparente e quindi insicuro per definizione.

come se i software open fossere immuni a queste pretiche, se ti volgio mettere un backdoor voglio vedere se tu controlli milioni di righe di codice ogni giorno.
Sai quante volte hanno iniettato codice malevole in software open (adirittura nel reposotory del kernel di linux). Tu lo scarichi e lo usi mica controlli ogni volta che il sorgente sia stato modificato.

Con un software open source hai un grado di sicurezza decisamente maggiore di uno closed source.
Certo, la sicurezza assoluta non esiste e non esisterà mai.

semplicemente smettete di usarlo se pensate non sia sicuro.
Oppure non comunicate fatti importanti e personali ma incontratevi di persona in una stanza con le pareti ed il tetto di piombo

Ma dopo aver saputo di PRISM e di tutti i sistemi di sorveglianza autorizzati senza difficoltà dall'NSA e dalle altre agenzie americane, davvero pensate di poter essere al sicuro su una chat di Whatsapp?? Sapete benissimo che google, facebook, microsoft, e tutti i principali provider di servizi di messaging, ricerca o di connettività hanno sottoscritto accordi con agenzie del governo americano, e anche di altri paesi, e passano regolarmente tutti i dati richiesti. Anzi, Snowden ha dimostrato che si andava ben oltre...

Lo scandalo per la scoperta di una backdoor o di una lacuna di sicurezza, oggi, è una cosa ridicola. Nessuno di questi sistemi garantisce la vostra privacy, è una cosa scontata. Se davvero la volete dovete adottare sistemi di crittografia su canali più sicuri.

Bah che sia o no una backdoor, mai fidarsi di un software closed source.
Sarebbe anche ora che la gente lo capisse...

forse una decina di anni fa il tuo discorso era vera adesso puoi inserire backdoor nei programmi open ( un esempio semplice è un'implementazione matematicamente imperfetta ) e sono quasi impossibili da trovare anche se hai il codice sorgente
secondo me l'unica soluzione sono gli audit continui con full disclosure ( ormai quasi esistinti ) non gli audit mirati a prendere le ricompense
l'open source ormai è solo un modo di fare bussiness non è più sinonimo di qualità e sicurezza

Certo. Per un software di sicurezza, essere open source è una condizione necessaria, ma non sufficiente.
Falso: un software closed può benissimo essere sicuro tanto quanto uno open.

La dimostrazione, peraltro, è banale.
Un software closed source è non trasparente e quindi insicuro per definizione.
Per quanto scritto sopra, è del tutto falso.

Vediamo se da oggi i soliti noti (o per meglio dire solito) continuera a promuovere Whatsapp e spalare merda sulla concorrenza, per ora inviolata, non ostante i dati alla mano.
Io per quanto mi riguarda evito whatsmerd ovunque possibile, e quando mi scrivono li rispondo su telegram :asd:

Leggendo sul blog del ricercatore (https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/) che ha scoperto la falla.
Proprietary closed-source crypto software is the wrong path. After all this - potentially mallicious code - handles all our decrypted messages. Next time the FBI will not ask Apple but WhatsApp to ship a version of their code that will send all decrypted messages directly to the FBI.
Lo stesso qui (https://slashcrypto.org/2017/01/13/WhatsApp_backdoor/), non è una backdoor, ma un attacco MiM.
Non utilizzate whatsapp se ci tenete alla privacy, usate signal, wire o le chat segrete di telegram ovvero tutti software open source.
Aggiungo la presa di posizione ufficiale di Open Whisper Systems: https://whispersystems.org/blog/there-is-no-whatsapp-backdoor/

Anche io sono completamente favorevole alla completa trasparenza, soprattutto sui software di sicurezza, comunque ti faccio notare che WA è closed source eppure questa vulnerabilità è venuta fuori lo stesso.

Vediamo se da oggi i soliti noti (o per meglio dire solito) continuera a promuovere Whatsapp e spalare merda sulla concorrenza, per ora inviolata, non ostante i dati alla mano.
Io per quanto mi riguarda evito whatsmerd ovunque possibile, e quando mi scrivono li rispondo su telegram :asd:
Effettivamente Telegram non ha di questi problemi, la crittografia end-to-end non ce l'ha (ok, ce l'ha, ma non la usa nessuno perché non è attiva di default) e i messaggi stanno tutti in chiaro direttamente sui loro server. :P

Il solito noto, comunque, non fa altro che illustrare i fatti anche in questa situazione. ;)

ma il bello e che ci si fa tante pippe mentali per whatsapp, poi magari le stesse persone mettono su facebook vita morte e miracoli della propria vita, diciamo che oggi secondo me non esagero se almeno un 70% delle persone che vive in paesi sviluppati la privacy se la sputtana da sola con i social!

Premesso che "open source" ormai e' solo una bella parola usata come politica di liberta' e "speranza", ma di fatto nessuno proibisce a nessun team di sviluppo di generare dei compilati provenienti da sorgenti completamente diversi. Cerchiamo di non essere ingenui, ma ANCHE SE, un compilato venisse fuori da un sorgente completamente trasparente, mi vengono in mente almeno una decina di sistemi diversi da implementare sui server, per bypassare o decrittare, contenuti protetti.

semplicemente smettete di usarlo se pensate non sia sicuro.
Oppure non comunicate fatti importanti e personali ma incontratevi di persona in una stanza con le pareti ed il tetto di piombo

solo dopo essersi accertati che i co-cospiratori non abbiano un registratore addosso, però...
:D

come se i software open fossere immuni a queste pretiche, se ti volgio mettere un backdoor voglio vedere se tu controlli milioni di righe di codice ogni giorno.
Sai quante volte hanno iniettato codice malevole in software open (adirittura nel reposotory del kernel di linux). Tu lo scarichi e lo usi mica controlli ogni volta che il sorgente sia stato modificato.

sono interessato al codice iniettato nei repository di linux, hai qualche link? grazie


Lo scandalo per la scoperta di una backdoor o di una lacuna di sicurezza, oggi, è una cosa ridicola. Nessuno di questi sistemi garantisce la vostra privacy, è una cosa scontata. Se davvero la volete dovete adottare sistemi di crittografia su canali più sicuri.

quali sono questi canali più sicuri?

In pratica sembra trattarsi di un'infelice scelta di design che hanno fatto i progettisti di WhatsApp per l'invio dei messaggi offline, che semplifica leggermente la vita all'utente, ma introduce una potenziale vulnerabilità; non si tratta di una backdoor.
mi sembra una visione troppo felice. È il caso di dire defective by design. Questi hanno volutamente scelto di creare una falla..

sono interessato al codice iniettato nei repository di linux, hai qualche link? grazie


Ne dubito, visto che non è mai successo.

Aggiornamento: Un portavoce di WhatsApp ha commentato la novità sostenendo che quanto affermato dalla testata statunitense sia "falso".

The Guardian statunitense? :confused:

Hermes

Mi sembra si sia arrivati a conclusioni drammatiche troppo in fretta: https://imgur.com/a/dehKb

In pratica sembra trattarsi di un'infelice scelta di design che hanno fatto i progettisti di WhatsApp per l'invio dei messaggi offline, che semplifica leggermente la vita all'utente, ma introduce una potenziale vulnerabilità; non si tratta di una backdoor. Quindi non c'è nessun reale complotto dietro e la vulnerabilità introdotta è relativamente ridotta, speriamo solo se ne rendano conto e revochino la modifica prima che qualcuno la sfrutti. In pratica sembra che WhatsApp abbia dato troppa importanza all'esperienza utente a scapito della sicurezza del protocollo.

Edit: qualche altro dettaglio riguardo al bug introdotto direttamente dal suo scopritore: https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/

:mc:

ne sei così sicuro? secondo me è una scusa bella e buona

è notizia di qualche giorno fa che sul loro servizio si scambiano circa 80 miliardi di messaggi al giorno, hai idea di che infrastruttura serva per mantenere un sistema di questo tipo?
inoltre come mai facebook ha acquisito quest'app per la modica cifra di 19 miliardi di dollari se poi agli utenti non chiede neanche un cent?
sono impazziti? sono filantropi?

io non credo proprio, trovo molto piu credibile che così come fanno altre realtà, siano dietro il business dei dati, in cui vendono dati, abitudini e quant'altro a società di vario tipo e forse anche a governi

ogni società piccola o grande che sia ha un solo e legittimo scopo, fare profitto, e regalare un servizio che costa mantenerlo senza appunto chiedere compenso è una cosa che dovrebbe far riflettere

:mano:

Bah che sia o no una backdoor, mai fidarsi di un software closed source.
Sarebbe anche ora che la gente lo capisse...

:cincin:

Leggendo sul blog del ricercatore (https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/) che ha scoperto la falla.
Proprietary closed-source crypto software is the wrong path. After all this - potentially mallicious code - handles all our decrypted messages. Next time the FBI will not ask Apple but WhatsApp to ship a version of their code that will send all decrypted messages directly to the FBI.
Lo stesso qui (https://slashcrypto.org/2017/01/13/WhatsApp_backdoor/), non è una backdoor, ma un attacco MiM.
Non utilizzate whatsapp se ci tenete alla privacy, usate signal, wire o le chat segrete di telegram ovvero tutti software open source.

:ave:

Falso: un software closed può benissimo essere sicuro tanto quanto uno open.

La dimostrazione, peraltro, è banale.

Per quanto scritto sopra, è del tutto falso.

:mc:

sono interessato al codice iniettato nei repository di linux, hai qualche link?

:muro:

E' una porta sul retro-bottega "involontaria" :rotfl:

Signal non riesce a registrare il mio num. Su Telegram invece non c'è registrato quasi nessuno dei miei contatti :p
Mi sa che si è quasi obbligati a restare con What's App :(

:mc:



:mano:



:cincin:



:ave:



:mc:



:muro:
Vedo che hai rinunciato definitivamente a qualsiasi tipo di argomentazione. :)

Signal non riesce a registrare il mio num. Su Telegram invece non c'è registrato quasi nessuno dei miei contatti :p
Mi sa che si è quasi obbligati a restare con What's App :(
Strano. Riprova più tardi o prova a contattarli.

:mc:
Non è che con una faccina te ne puoi uscire smentendo quello che avevo scritto.

Peraltro la dimostrazione di cui parlavo l'avevo fornita tempo fa proprio all'utente a cui ho replicato, che però "stranamente" l'avrà dimenticata, visto che ha ripetuto nuovamente lo stesso mantra.
Vedo che hai rinunciato definitivamente a qualsiasi tipo di argomentazione. :)
Argomentazione? Quale? :D Sei troppo generoso. ;)

Ma dopo aver saputo di PRISM e di tutti i sistemi di sorveglianza autorizzati senza difficoltà dall'NSA e dalle altre agenzie americane, davvero pensate di poter essere al sicuro su una chat di Whatsapp?? Sapete benissimo che google, facebook, microsoft, e tutti i principali provider di servizi di messaging, ricerca o di connettività hanno sottoscritto accordi con agenzie del governo americano, e anche di altri paesi, e passano regolarmente tutti i dati richiesti. Anzi, Snowden ha dimostrato che si andava ben oltre...

Lo scandalo per la scoperta di una backdoor o di una lacuna di sicurezza, oggi, è una cosa ridicola. Nessuno di questi sistemi garantisce la vostra privacy, è una cosa scontata. Se davvero la volete dovete adottare sistemi di crittografia su canali più sicuri.

Esatto

Falso: un software closed può benissimo essere sicuro tanto quanto uno open.

La dimostrazione, peraltro, è banale.

Per quanto scritto sopra, è del tutto falso.

Leggendo sul blog del ricercatore (https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/) che ha scoperto la falla.
Proprietary closed-source crypto software is the wrong path. After all this - potentially mallicious code - handles all our decrypted messages. Next time the FBI will not ask Apple but WhatsApp to ship a version of their code that will send all decrypted messages directly to the FBI.
Penso abbia molte più competenze di chiunque qui su questo forum su questo argomento. Poi sei libero di pensare quello che vuoi, contento tu...

Aggiungo la presa di posizione ufficiale di Open Whisper Systems: https://whispersystems.org/blog/there-is-no-whatsapp-backdoor/

Quindi?! Non smentisce niente anzi per fortuna conferma la gravità della falla.


Anche io sono completamente favorevole alla completa trasparenza, soprattutto sui software di sicurezza, comunque ti faccio notare che WA è closed source eppure questa vulnerabilità è venuta fuori lo stesso.


Essere closed source non significa che le falle non vengano fuori (vedi windows e la sua storia). E' una questione di trasparenza soprattutto dopo lo scandalo Prism.
Ripeto, non utilizzate whatsapp se ci tenete alla privacy, usate signal, wire o le chat segrete di telegram ovvero tutti software open source.
Per un software di sicurezza, essere open source è una condizione necessaria, ma non sufficiente.

Leggendo sul blog del ricercatore (https://tobi.rocks/2016/04/whats-app-retransmission-vulnerability/) che ha scoperto la falla.
Proprietary closed-source crypto software is the wrong path. After all this - potentially mallicious code - handles all our decrypted messages. Next time the FBI will not ask Apple but WhatsApp to ship a version of their code that will send all decrypted messages directly to the FBI.
Penso abbia molte più competenze di chiunque qui su questo forum su questo argomento. Poi sei libero di pensare quello che vuoi, contento tu...
Ti ho già DIMOSTRATO in passato che la tua asserzione è falsa, e questo non lo può smontare nemmeno il ricercatore di cui sopra.

Le dimostrazioni non hanno nulla a che vedere col pensiero, né si possono piegare alle fantasie di chiunque: sono e rimangono valide a prescindere.
Per un software di sicurezza, essere open source è una condizione necessaria, ma non sufficiente.
Ripeterlo ancora non lo renderà automaticamente vero: è una falsità, e te l'ho già DIMOSTRATO in passato. Il fatto che tu non lo voglia accettare è un problema tuo, ma la dimostrazione rimane.

Comunque per me non c'è alcun problema: se sei convinto della tua asserzione puoi tranquillamente dimostrarmi che sia vera.

Formalizziamo il problema in questione. Sia x un software di "sicurezza" (qualunque cosa tu intenda per sicurezza / sicuro; per semplicità). Se x è "sicuro" (vedi parentesi precedente) allora x è necessariamente open source.

Accomodati pure, e per quanto mi riguarda puoi sottoporre il problema anche ai massimi esperti in ambito di sicurezza. Ma fatti dare la DIMOSTRAZIONE (formale) del problema: delle chiacchiere come le tue non me ne faccio niente. :read:

Ti ho già DIMOSTRATO in passato che la tua asserzione è falsa, e questo non lo può smontare nemmeno il ricercatore di cui sopra.

Le dimostrazioni non hanno nulla a che vedere col pensiero, né si possono piegare alle fantasie di chiunque: sono e rimangono valide a prescindere.

Ripeterlo ancora non lo renderà automaticamente vero: è una falsità, e te l'ho già DIMOSTRATO in passato. Il fatto che tu non lo voglia accettare è un problema tuo, ma la dimostrazione rimane.

Comunque per me non c'è alcun problema: se sei convinto della tua asserzione puoi tranquillamente dimostrarmi che sia vera.

Formalizziamo il problema in questione. Sia x un software di "sicurezza" (qualunque cosa tu intenda per sicurezza / sicuro; per semplicità). Se x è "sicuro" (vedi parentesi precedente) allora x è necessariamente open source.

Accomodati pure, e per quanto mi riguarda puoi sottoporre il problema anche ai massimi esperti in ambito di sicurezza. Ma fatti dare la DIMOSTRAZIONE (formale) del problema: delle chiacchiere come le tue non me ne faccio niente. :read:

Quale sarebbe stata la dimostrazione? Riportala e vediamo...

Premetto che la mia affermazione non è un teorema (non esiste una dimostrazione), ma una congettura sostenuta dal 99.9% degli esperti in materia.
Dimostrare che: P=software sicurezza Q=open source
P=>Q , software sicurezza => open source
non è possibile in modo automatico o manuale.
Al momento non esistono sistemi formali in grado di dimostrare che il 100% del codice sorgente di un software sia sicuro, ma esistono sistemi in grado di verificare le "parti critiche" di un software. Ottimo articolo in materia (https://www.quantamagazine.org/20160920-formal-verification-creates-hacker-proof-code/).
Questa verifica richiede che il software sia open source.
Esistono esempi di software sicuri che sono closed source? Forse, ma non è possibile verificarlo non avendo il codice sorgente disponibile.

In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. Fonte (https://www.schneier.com/crypto-gram/archives/1999/0915.html#OpenSourceandSecurity)

Sei troppo sicuro di te stesso e pensi di saperne più di esperti in materia, abbassa la cresta...

Quale sarebbe stata la dimostrazione? Riportala e vediamo...
Sia x un software di cui è disponibile il sorgente e che viene considerato "sicuro".

Prendo i sorgenti di x, e genero da essi un'applicazione y in cui cambio soltanto delle scritte e l'interfaccia grafica in modo che y non sia riconoscibile da x; quindi il codice rimane lo stesso.

Di y metto a disposizione soltanto i binari, e dunque non è possibile analizzarne sorgenti, in quanto il software rimane chiuso.

Se x è sicuro, lo è anche y, perché il codice non è cambiato.

Ma y è closed, e dunque secondo la tua tesi dovrebbe, invece, essere necessariamente open source.

Da cui la falsificazione della tua tesi.
Premetto che la mia affermazione non è un teorema (non esiste una dimostrazione),
E mai esisterà, visto che rientrerebbe nel problema dell'arresto, dimostrato essere incomputabile.
ma una congettura sostenuta dal 99.9% degli esperti in materia.
Le congetture si basano su numerosi DATI/FATTI, che possano consentire di tracciare un diagramma / andamento dello studio in oggetto.

A parole, quindi, puoi sostenere quello che vuoi, ma finché non porti questo 99,9% di dati, non valgono nulla.
Dimostrare che: P=software sicurezza Q=open source
P=>Q , software sicurezza => open source
non è possibile in modo automatico o manuale.
E non esisterà, come già detto, perché chi ha avuto modo di studiare Teoria della Computabilità all'università (o per conto proprio), dovrebbe aver intuito subito, a naso, che ciò che chiedi risulta riconducibile al famigerato problema dell'arresto, che è noto essere INCOMPUTABILE.

Quindi non ti sforzare: sarebbe tempo perso. Non potrai mai dimostrare nulla del genere, nemmeno se avessi a disposizione l'intero tempo di vita dell'universo.
Al momento non esistono sistemi formali in grado di dimostrare che il 100% del codice sorgente di un software sia sicuro, ma esistono sistemi in grado di verificare le "parti critiche" di un software. Ottimo articolo in materia (https://www.quantamagazine.org/20160920-formal-verification-creates-hacker-proof-code/).
Ovvio: per piccole, precise, porzioni di software è un lavoro che è possibile fare. E lo si fa con software molto delicati, come quello di un pacemaker o del controllo del nocciolo di una centrale nucleare.

Ma è un lavoro ENORME, che richiede un sacco di tempo (e soldi, ovviamente), che non si può fare con qualunque software, specialmente con la complessità che hanno raggiunto quelli moderni.
Questa verifica richiede che il software sia open source.
Esistono esempi di software sicuri che sono closed source? Forse, ma non è possibile verificarlo non avendo il codice sorgente disponibile.
Infatti il problema non è tanto che il software debba essere open, ma che si debba avere a disposizione il codice. Differenza che può sembrare sottile, ma le cui implicazioni sono fondamentali per la discussione.
In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. Fonte (https://www.schneier.com/crypto-gram/archives/1999/0915.html#OpenSourceandSecurity)
Opinione rispettabile, ma che è possibile non condividere.

Quando dimostrerà formalmente che un software closed è intrinsecamente insicuro ne riparleremo. Ma vedi sopra: dubito che anche lui lo possa fare.
Sei troppo sicuro di te stesso e pensi di saperne più di esperti in materia, abbassa la cresta...
Mi basta quel che ho studiato per smontare queste affermazioni: la matematica (di cui l'informatica è una branca) NON è un'opinione.

Forse lo è per te, che non hai affrontato studi di un certo tipo.

Comunque puoi benissimo scomodare il tizio in questione e chiederli gentilmente la dimostrazione di cui sopra. Qual è il problema qui? Tanto è un esperto in materia, no? Gli dovrebbe essere vita facile.

E poi io sono un neubie in confronto: cosa vuoi che sia smontarmi? Sarà un gioco da ragazzi. :O

Scusate c'è un errore: "È stata trovata su WhatsApp una backdoor di sicurezza che può permettere allo staff della NSA di intercettare e leggere i messaggi di testo"

E' una porta sul retro-bottega "involontaria" :rotfl:

:D

...involontaria :sofico:

Vedo che hai rinunciato definitivamente a qualsiasi tipo di argomentazione. :)

LEGENDA

:mc: = 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 :ciapet:

Non è che con una faccina te ne puoi uscire smentendo quello che avevo scritto.

Peraltro la dimostrazione di cui parlavo l'avevo fornita tempo fa proprio all'utente a cui ho replicato, che però "stranamente" l'avrà dimenticata, visto che ha ripetuto nuovamente lo stesso mantra.

:mc: = 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”...
Ma ci sarà o no, una differenza fra mala fede e buona 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?! :sofico:


Argomentazione? Quale? :D Sei troppo generoso. ;)

:mc:

Quale sarebbe stata la dimostrazione? Riportala e vediamo...

Premetto che la mia affermazione non è un teorema (non esiste una dimostrazione), ma una congettura sostenuta dal 99.9% degli esperti in materia.
Dimostrare che: P=software sicurezza Q=open source
P=>Q , software sicurezza => open source
non è possibile in modo automatico o manuale.
Al momento non esistono sistemi formali in grado di dimostrare che il 100% del codice sorgente di un software sia sicuro, ma esistono sistemi in grado di verificare le "parti critiche" di un software. Ottimo articolo in materia (https://www.quantamagazine.org/20160920-formal-verification-creates-hacker-proof-code/).
Questa verifica richiede che il software sia open source.
Esistono esempi di software sicuri che sono closed source? Forse, ma non è possibile verificarlo non avendo il codice sorgente disponibile.

In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. Fonte (https://www.schneier.com/crypto-gram/archives/1999/0915.html#OpenSourceandSecurity)


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


Sei troppo sicuro di te stesso e pensi di saperne più di esperti in materia, abbassa la cresta...

:tapiro:

Sia x un software di cui è disponibile il sorgente e che viene considerato "sicuro".

Prendo i sorgenti di x, e genero da essi un'applicazione y in cui cambio soltanto delle scritte e l'interfaccia grafica in modo che y non sia riconoscibile da x; quindi il codice rimane lo stesso.

Di y metto a disposizione soltanto i binari, e dunque non è possibile analizzarne sorgenti, in quanto il software rimane chiuso.

Se x è sicuro, lo è anche y, perché il codice non è cambiato.

Ma y è closed, e dunque secondo la tua tesi dovrebbe, invece, essere necessariamente open source.

Da cui la falsificazione della tua tesi.

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

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




Infatti il problema non è tanto che il software debba essere open, ma che si debba avere a disposizione il codice.

...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... :sofico:


Quando dimostrerà formalmente che un software closed è intrinsecamente insicuro ne riparleremo. Ma vedi sopra: dubito che anche lui lo possa fare.


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

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...:sofico: :mc: :sofico: :mc:

Sia x un software di cui è disponibile il sorgente e che viene considerato "sicuro".

Prendo i sorgenti di x, e genero da essi un'applicazione y in cui cambio soltanto delle scritte e l'interfaccia grafica in modo che y non sia riconoscibile da x; quindi il codice rimane lo stesso.

Di y metto a disposizione soltanto i binari, e dunque non è possibile analizzarne sorgenti, in quanto il software rimane chiuso.

Se x è sicuro, lo è anche y, perché il codice non è cambiato.

Ma y è closed, e dunque secondo la tua tesi dovrebbe, invece, essere necessariamente open source.

Da cui la falsificazione della tua tesi.

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.

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

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.

Tu controlli il codice sorgente dei software open? Se no, allora sei sicuro solo quando qualche esperto del settore da qualche analisi dedicata.
Dimenticate che ci sono enti che hanno accesso anche al codice di Windows e che, nonostante sia più che chiuso, gli esperti di Google (giusto per fare un esempio) sono in grado di trovare falle e problemi vari.

La verità, all'atto pratico, è che sono pochi quelli che davvero leggono il codice, ancora meno quelli che lo capiscono. Gira e rigira, data la mole di determinati progetti (ossia tutti quelli critici), sono sempre gli stessi ad avere gli occhi puntati sui sorgenti.

Un'altra cosa che, chissà perché, non si considera mai è che il codice può anche essere disponibile, ma se è scritto male e non è documentato, è poco più comprensibile dell'aramaico antico.

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.

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

Il codice di Linux è disponibile da 25 anni. Per un decennio (10 anni) una falla è rimasta lì, ben nota ma non sistemata perché nemmeno Torvalds aveva trovato il modo di risolvere la cosa.

E OpenSSL? Due anni di bug gravissimo (dato il tipo di progetto).

A me sembra palese che, all'atto pratico, gli unici che studiano il sorgente sono: gli sviluppatori originali e gli esperti di sicurezza, ossia gli stessi che trovano le falle pure in Windows.

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.

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

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

Sia x un software di cui è disponibile il sorgente e che viene considerato "sicuro".

Prendo i sorgenti di x, e genero da essi un'applicazione y in cui cambio soltanto delle scritte e l'interfaccia grafica in modo che y non sia riconoscibile da x; quindi il codice rimane lo stesso.

Di y metto a disposizione soltanto i binari, e dunque non è possibile analizzarne sorgenti, in quanto il software rimane chiuso.

Se x è sicuro, lo è anche y, perché il codice non è cambiato.

Ma y è closed, e dunque secondo la tua tesi dovrebbe, invece, essere necessariamente open source.

Da cui la falsificazione della tua tesi.

Ti ha già risposto l'utente Opteranium con un obiezione che dimostra il non senso di voler avere questa dimostrazione.
La dimostrazione matematica da te proposta, matematicamente è corretta, ma ha validità teorica.
Ha i seguenti problemi reali e pratici:

Per poter affermare che y sia sicuro in quanto compilato da x, occorre avere il sorgente di x.
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?

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


E mai esisterà, visto che rientrerebbe nel problema dell'arresto, dimostrato essere incomputabile.

E non esisterà, come già detto, perché chi ha avuto modo di studiare Teoria della Computabilità all'università (o per conto proprio), dovrebbe aver intuito subito, a naso, che ciò che chiedi risulta riconducibile al famigerato problema dell'arresto, che è noto essere INCOMPUTABILE.

Quindi non ti sforzare: sarebbe tempo perso. Non potrai mai dimostrare nulla del genere, nemmeno se avessi a disposizione l'intero tempo di vita dell'universo.


Se vogliamo parlare di Teoria della calcolabilità, inutile visto il non senso della dimostrazione, dobbiamo considerare il teorema di Rice (https://en.wikipedia.org/wiki/Rice%27s_theorem) e non il problema dell'arresto: there exists no automatic method that decides with generality non-trivial questions on the behavior of computer programs.


Le congetture si basano su numerosi DATI/FATTI, che possano consentire di tracciare un diagramma / andamento dello studio in oggetto.

A parole, quindi, puoi sostenere quello che vuoi, ma finché non porti questo 99,9% di dati, non valgono nulla.

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.


Ovvio: per piccole, precise, porzioni di software è un lavoro che è possibile fare. E lo si fa con software molto delicati, come quello di un pacemaker o del controllo del nocciolo di una centrale nucleare.

Ma è un lavoro ENORME, che richiede un sacco di tempo (e soldi, ovviamente), che non si può fare con qualunque software, specialmente con la complessità che hanno raggiunto quelli moderni.


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 (https://en.wikipedia.org/wiki/Pareto_principle#In_software) (non è dimostrabile nemmeno questo, ma l'evidenza pratica lo rende utilizzabile).


Infatti il problema non è tanto che il software debba essere open, ma che si debba avere a disposizione il codice. Differenza che può sembrare sottile, ma le cui implicazioni sono fondamentali per la discussione.


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


Opinione rispettabile, ma che è possibile non condividere.

Quando dimostrerà formalmente che un software closed è intrinsecamente insicuro ne riparleremo. Ma vedi sopra: dubito che anche lui lo possa fare.


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.


Mi basta quel che ho studiato per smontare queste affermazioni: la matematica (di cui l'informatica è una branca) NON è un'opinione.

Forse lo è per te, che non hai affrontato studi di un certo tipo.

Comunque puoi benissimo scomodare il tizio in questione e chiederli gentilmente la dimostrazione di cui sopra. Qual è il problema qui? Tanto è un esperto in materia, no? Gli dovrebbe essere vita facile.

E poi io sono un neubie in confronto: cosa vuoi che sia smontarmi? Sarà un gioco da ragazzi. :O

Non è una lotta a chi smonta l'altro.
Una domanda: ti sei mai chiesto perché i ricercatori di sicurezza affermano quanto riportato da me nei vari messaggi precedenti?!
Adesso spero sia chiaro che non è un teorema, al massimo una congettura, non è necessario dimostrare l'evidenza pratica.
Se vuoi una prova matematica non l'avrai mai, molti software funzionano correttamente senza una prova matematica.

Il codice di Linux è disponibile da 25 anni. Per un decennio (10 anni) una falla è rimasta lì, ben nota ma non sistemata perché nemmeno Torvalds aveva trovato il modo di risolvere la cosa.

E OpenSSL? Due anni di bug gravissimo (dato il tipo di progetto).

A me sembra palese che, all'atto pratico, gli unici che studiano il sorgente sono: gli sviluppatori originali e gli esperti di sicurezza, ossia gli stessi che trovano le falle pure in Windows.

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

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.

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.

ma non vi stancate mai?

:confused:

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?

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.

https://www.schneier.com/blog/archives/2017/01/whatsapp_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.

La risposta del ricercatore che ha scoperto la falla di sicurezza direttamente sul guardian (https://www.theguardian.com/technology/2017/jan/16/whatsapp-vulnerability-facebook).
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 (http://www.ansa.it/sito/notizie/tecnologia/internet_social/2016/11/17/facebook-sospeso-luso-dei-dati-whatsapp-per-la-pubblicita-in-ue_e941ad84-ffce-41d5-9ba9-ee7c474390b6.html)), ho cancellato il mio contatto whatsapp e raccomando di usare signal, wire o telegram.

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

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

:mc: = 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 :ciapet:
Le solite mistificazioni & complottismi con cui ami condire le tue filippiche. Nulla di nuovo...
:mc: = 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?! :sofico:
Nel mio pianeta queste si chiamano ipotesi. Nel tuo certezze (ma senza prove).
:mc:
Hai risposto precedentemente con un commento condito soltanto di faccine. Dunque NON hai argomentato. :read:

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

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...:read:
In tal caso sei liberissimo di smontare la mia dimostrazione: accomodati pure.
:tapiro:
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"....:mc: ...la realtà è ASSAI più complessa :read:
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: :mc:
...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... :sofico:
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...:sofico: :mc: :sofico: :mc:
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!
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...
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... :rolleyes:

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. :read:

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:

Per poter affermare che y sia sicuro in quanto compilato da x, occorre avere il sorgente di x.
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. :rolleyes:
dobbiamo considerare il teorema di Rice (https://en.wikipedia.org/wiki/Rice%27s_theorem) 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 (https://en.wikipedia.org/wiki/Rice%27s_theorem#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 (https://en.wikipedia.org/wiki/Pareto_principle#In_software) (non è dimostrabile nemmeno questo, ma l'evidenza pratica lo rende utilizzabile).
How many lines of code are in the Linux kernel? (https://www.quora.com/How-many-lines-of-code-are-in-the-Linux-kernel?share=1):

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

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.

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..:D

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.

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.

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.

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.

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..:D
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.
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.
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 :D) 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++. :fagiano:

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

http://systemadmin.es/wp-content/uploads/2015/03/random-by-debian.jpg

:D
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. :fagiano:

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. :D
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 (http://www.programmazione.it/index.php?entity=eitem&idItem=42536)

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 :Prrr: ma dubito che ce ne sara' il bisogno(e magari qualche soldino entra in qualche progetto GPL dalle cause vinte :D :D :D :D :D).

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

Fonti: le sue email. :D

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.

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.

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.

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).
C'è per lo meno una sostanziale differenza: l'autorità terza non persegue il profitto con quel software come farebbe l'azienda che lo produce.

Poi certo, se chiedo ad un'autorità del governo USA di certificare che nel software crittato non ci sono backdoor, allora... :asd:
Ma un ente certificatore ben strutturato potrebbe comunque dare discrete garanzie.

[...] Mi viene solo il dubbio se una cosa del genere sia fattibile in maniera estensiva in tutte le situazioni che lo richiedono.

In alcuni ambiti (es. pagamenti elettronici) la cosa è già realizzata.

In generale, gli utenti si stanno abituando a scaricare il software da pochi store.
Bisognerebbe che questi store fossero gestiti da un ente terzo, non dagli stessi fornitori di hw e/o S.O. (Apple, Google, MS, ...).

Naturalmente le regole dovranno essere più stringenti delle attuali e le procedure di validazione ben codificate.

Sul problema di chi vigila sul vigilante... questo si pone in ogni attività umana; di solito si dice che bisogna avere fiducia nella giustizia.

In alcuni ambiti (es. pagamenti elettronici) la cosa è già realizzata.

In generale, gli utenti si stanno abituando a scaricare il software da pochi store.
Bisognerebbe che questi store fossero gestiti da un ente terzo, non dagli stessi fornitori di hw e/o S.O. (Apple, Google, MS, ...).

Naturalmente le regole dovranno essere più stringenti delle attuali e le procedure di validazione ben codificate.

Sul problema di chi vigila sul vigilante... questo si pone in ogni attività umana; di solito si dice che bisogna avere fiducia nella giustizia.

Lo store è una fonte di guadagno per chi fornisce tale servizio, quindi è normale che rimanga nelle sue mani.

Si dice che si deve avere fiducia nella giustizia, altrimenti il sistema va gambe all'aria, e perché, in teoria, i cittadini "controllano" chi propone le leggi che poi i vigilanti dovranno far rispettare. Insomma, IN TEORIA, una buona e vera democrazia è un sistema equilibrato.

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.
Ma anche no. :)

La GPL si applica e ha effetti solo su software che è con essa licenziato, o con cui ne viene a contatto (estendendo viralmente i suoi effetti).

Col procedimento che ho descritto, il software GPL rimane rigorosamente isolato dall'altro codice, e dunque non può estendere su quest'ultimo i suoi effetti: è il mio lavoro, che ho sviluppato senza toccare minimamente il codice GPL, e dunque... rimane mio.

Soltanto DOPO l'offuscamento il codice GPL viene a contatto dell'altro, ma a questo punto è troppo tardi. :cool:

La clausola che hai riportato vale per il caso comune: hai preso un codice GPL, e l'hai modificato, e c'hai lavorato. E quindi chi ha scritto la GPL vuole tutelarsi da successivi offuscamenti, di quello che è diventato interamente codice GPL.
Comunque se ci credi vai, al massimo verra' fatta la GPL 4 :Prrr: ma dubito che ce ne sara' il bisogno(e magari qualche soldino entra in qualche progetto GPL dalle cause vinte :D :D :D :D :D).
Senz'altro, ma non tutto il codice GPL è automaticamente estensibile alla v4. Linux, ad esempio, è fermo alla GPL v2. ;)

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

….e con ciò cosa hai aggiunto a questa conversazione?!?!...la TUA forzatura di far passare chi sta dubitando di Facebook-WhatsApp come soggetti che sbandierano il fatto che NESSUNO è in grado di leggere i messaggi fra due utenti criptati end-to-end proprio non c'entra una beata “ipotesi” fra codice chiuso ed aperto.
Qui la questione è se chi “offre gratuitamente” questa applicazione per comunicare, abbia o meno inserito backdoors per continuare a fare quello che gli permette di prosperare ( in maniera ben oltre le regole stabilite in Europa in merito alla privacy ).

LA cosa ilare è che ti spertichi in battaglie contro i mulini a vento e poi scrivi: “ Ciò che conta, e lo ribadisco per l'n-esima volta, è che di un software si possa accedere al sorgente per controllarlo. “ :sofico: :sofico: :sofico:

= tuoi poemi schizofrenici :mc:



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

….guarda che non era rivolto a te, respira e sforzati di pensare che il mondo è bello ...questo potrebbe essere nuovo per te ;)



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.


Come al solito perdi il controllo sbilanciandoti in offese che ho seri dubbi tu stesso possa capire...
comunque contento tu !!!
Il riferimento alla buona o mala fede è correlato al comportamento delle OTT... :-)

PS E poi come già fatto in passato ti consiglio vivamente di mantenere un tono adatto al rispetto ed alla convivenza su questo forum...oltre a dimostrare cose che stanno solo nel tuo mondo piccolo-piccolo, ti consiglio di leggere il regolamento del forum, ok?! :)



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

Ancora con il giochino delle tre carte ….ma veramente ti reputi ( ahi te! :doh: ) così distante dalla realtà da non aver MAI sentito, anche lontanamente, parlare di profilazione , profilazione incrociata , di brokeraggio dati?!?!?... hai mai letto i permessi che le “app” degli smartphone pretendono per funzionare ( raccolta di dati personali illmitata)!?!....ma dai....o forse, sei ignaro , visto che dici di non conoscere l'obsolescenza programmata che è un asset imprescindibile senza il quale la profittabilità di molte multinazionali ICT sarebbe ridicola?! :read:

Tornando nello specifico argomento della raccolta continuativa ed indiscriminata dei dati, hai mai sentito parlare di BIG DATA, o nel tuo piccolo mondo questa è una ipotesi ed in quanto tale ….ahahahahaha....NON esiste ….arihahahahahahahaha!!!!:sofico:
:doh:



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

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

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

Direi che ti commenti da solo.


….diciamo che se non sei in grado di leggere i commenti di questa discussione , senza seguire il filo logico connotato dalla parola “LEGENDA “ ( che sembri non conoscere...poco male...vai e cerca ;) , forse a commentarsi da solo è il tuo atteggiamento e soprattutto le tue affermazioni scomposte.



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.

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: :mc:


Diciamo che la tua dimostrazione descrive una realtà talmente semplificata che si può tranquillamente riportare al mondo dei fumetti.
La realtà è più complessa fors'anche della tua capacità di percepirla a fronte del tuo atteggiamento da negazionista assoluto.

….d'altronde come potersi aspettare da un soggetto che nega dinamiche acclarate senza nemmeno rappresentarle con delle variabili all'interno di VERE EQUAZIONI e SISTEMI RAPPRENSTATIVI del mondo reale...

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


E queste tue parole la misura di quanto tu sia di parte e di come sia NEGAZIONISTA...puro negazionista :muro:



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

...Sia x un software di cui è disponibile il sorgente e che viene considerato "sicuro".

Prendo i sorgenti di x, e genero da essi un'applicazione y in cui cambio soltanto delle scritte e l'interfaccia grafica in modo che y non sia riconoscibile da x; quindi il codice rimane lo stesso.

Di y metto a disposizione soltanto i binari, e dunque non è possibile analizzarne sorgenti, in quanto il software rimane chiuso.

Se x è sicuro, lo è anche y, perché il codice non è cambiato.
….

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


PREMESSA:
La matematica serve a rappresentare il mondo reale. Ed OVE il modello stilizzato riproduca la DINAMICA effettiva, è in grado di diventare predittivo.
Quando ti sforzi enormemente per produrre una equazione di seconda media, primo trimestre, e la vuoi spacciare per rappresentativa della realtà....mbhè... il tuo obiettivo è irraggiungibile...fattene una ragione ...e trova una serenità interiore che ti guidi sulla strada del rispetto e della buona educazione, per prima cosa e della coerenza (...magari ) più in la...

Venendo alla TUA Dimostrazione, dal punto di vista PRETTAMENTE FORMALE, non fa una piega.
Ma la vera domanda è: Cosa centra QUESTA dimostrazione con il mondo reale e soprattutto con l'oggetto di questo articolo?!?!? :sofico:


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


....si ! questo nel fantastico mondo di Alice dove la meraviglia è nei soggetti che tu "ipotizzi" avere accesso al codice....:D





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?


....ma scivi veramente?!?!?!?!?!?!?!?!?!?!? :sofico:
Opterium ha descritto uno scenario TOTALMENTE differente....stai rispondendo con le pere ad un argomento di filosofia :mc:



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

...e se non si facesse parte di questo “cerchio magico “ ( gli stessi creatori e enti / aziende che hanno il PERMESSO di analizzarlo....sempre concesso dai primi...vale a dire i creatori che “magari” hanno dei contratti blindati di non divulgazione...quindi il tutto rimane sempre in “FAMIGLIA”...ma ops....c'è una ipotesi che non hai “pensata”....uno dei creatori che inizia a “vendere“ informazioni riservate.....chissà perchè mi viene in mente Snowden... Una ipotesi non presente nel tuo repertorio, ma accaduta nel mondo reale ;)





...

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

….quindi finalmente nel tuo mondo sorge una “ipotesi” che il sw chiuso possa contenere backdoor(S)....allora esiste il dubbio nel tuo pianeta e ….vuol dire che NESSUNO AL MONDO ( tieni forte.... NEANCHE TU...hahaha ) può certificare un sw a fonte chiusa come privo di backdoor! :read:



Al di là di un ipotetico giudizio di carattere legale, è proprio la mentalità che va condannata.
La licenza in questione ha come filosofia la correttezza e la trasparenza.
Andare contro questi principi è da imbroglioni. Punto.
Al di là del giudice pinco o pallino.
Ancora peggio è arrovellersi per trovare un semiappiglio per fottere le regole perché questo oltretutto denota proprio impegno e premeditazione.

La cosa veramente “singolare” è che chi sta negando la realtà, poi si incensa rivendicando tecniche per nascondere backdoor a “prova di controllo”....:doh:

Continui a non convincermi, ma comunque fai pure. Alla fine è un magistrato a decidere se questo escamotage per aggirare la licenza é valido, non io.
Nemmeno io sono un magistrato, ma mi sono studiato e ho ben chiaro il diritto d'autore, e in quanto autore so che ho pieno ed esclusivo godimento del frutto del mio ingegno, e dunque deciso io in che modo possa essere fruito.

Ovviamente lo stesso vale per chi ha deciso di licenziare il proprio codice come GPL. Ma vale soltanto per il SUO codice, appunto, e non può estenderlo a quello di altri.

Tranne quando ne viene a contatto, come sappiamo.
Al di là di un ipotetico giudizio di carattere legale, è proprio la mentalità che va condannata.
La licenza in questione ha come filosofia la correttezza e la trasparenza.
No, ha come filosofia mettere le mani anche su codice altrui (se ne viene a contatto): è questo che condanno.

Nulla da dire se uno decide di rilasciare i suoi sorgenti, e se vuole tutelarsi da modifiche a QUEL, e solo quello, SUO codice. Assolutamente legittimo.
Andare contro questi principi è da imbroglioni. Punto.
Adesso stai passando a delle offese gratuite nonché infondate.

Sei un bugiardo e un mistificatore!
Al di là del giudice pinco o pallino.
Ancora peggio è arrovellersi per trovare un semiappiglio per fottere le regole perché questo oltretutto denota proprio impegno e premeditazione.
Le regole sono quelle del copyright e del diritto d'autore, che non valgono solo per codice licenziato come GPL. :read:

Poi che io sia fieramente avverso alle licenze virali non è che lo si scopra adesso.

Come già detto, sono assolutamente contrario ad estendere gli effetti di queste licenze su codice ALTRUI. E di conseguenza mi adopero nel trovare soluzioni per boicottarle.

Cosa che, peraltro, si fa già da ben prima, e con altri mezzi. Nello specifico, è ben noto nonché usato il meccanismo delle IPC per richiamare codice proprietario da parte di codice GPL.

Un altro modo più "pulito", se vogliamo, ma che ha esattamente gli stessi effetti: impedire di estendere la viralità della licenza a codice altrui.

@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?)

Fai come ti pare se ne sei convinto... Se ti infili in un guaio giudiziario sono affari tuoi (e visto il contesto non mi dispiace neanche).

Dubito che si infilerebbe in guai giudiziari. Pure io avevo letto di varie tecniche per eludere (in maniera del tutto legale) i termini della GPL.

Tra l'altro non è l'unico sviluppatore a criticare la viralità di tale licenza, senza considerare che credo sia in declino il suo utilizzo (al contrario di MIT, Apache, BSD, etc.).

Non capisco proprio cosa c'entri questo discorso. Non sto dicendo che gli debba necessariamente piacere la GPL.
Sto dicendo che sta tentando di aggirarla con trucchetti che di fatto violano lo spirito della licenza stessa.
Uno puo' dire quello che gli pare ma non mi pare assolutamente un esempio di correttezza.

Ma qua il punto non è la legalità o meno della cosa? :D

Sulla correttezza, ognuno ha le sue opinioni, ovviamente. :)

:confused: :confused: :confused: Sei tu che nella seconda parte del discorso del tuo scorso post parli di roba che non c'entra con le questioni legali. Io mi sono limitato a risponderti.

Hai ragione, mea culpa. :D
Comunque il punto è che già oggi si usano tecniche per tenere al sicuro il proprio codice dalla viralità della GPL, non è che cdimauro stia rivelando chissà che di nuovo.


Per il resto...
Se la licenza dice X e tu inventi un modo per aggirare X, uno puo' dire quello che gli pare, ma quello che stai trovando e' una scappatoia legislativa per fare quello che secondo lo spirito della licenza stessa ti impedirebbe. Che riesca o no non e' IMHO proprio un comportamento edificante.

Ma non è nemmeno molto "corretto" il fatto che la licenza sia virale. Che tu voglia che il tuo codice rimanga per sempre libero, modificabile, etc, va benissimo, così come è giusto che tu abbia uno strumento legale per farlo.

Ma se io utilizzo una porzione di codice tuo in un mio programma, perché dovrei rilasciare anche il MIO codice? cdimauro (perché questo discorso si è già fatto decine di volte) dice che una licenza "corretta" lo obbligherebbe solo a rilasciare eventuali modifiche al codice altrui (oltre che lo stesso), ma non il SUO codice.

Ovviamente, io lo stesso discorso lo faccio anche a parti invertite. Nessuno dovrebbe obbligarmi a rendere il mio software closed, se io non lo volessi.

Ovviamente c'è un motivo se la GPL è questa: Stallman vuole che tutto il codice sia sotto GPL, fine. L'intero progetto GNU è nato esclusivamente per questioni ideologiche, mica gliene fregava niente di scrivere un sistema operativo, per cui la licenza non è altro che uno strumento utile alla causa.

Non ti piace la GPL e i suoi termini? Non usarla e non usare il codice licenziato con essa. Non mi pare troppo complicato.

Hai tirato in ballo la correttezza di fronte alla sua soluzione. Ciò che conta è che sia legale o meno. Se, restando nei termini della licenza, si può comunque preservare il proprio codice, fine della storia.
Tutto la polemica sta ruotando intorno a questo o no?

Polemica ???? Ma dove ??? Io lo sto pure invitando a rilasciare il suo codice per fare offuscamento e di fare quello che gli pare, tanto e' responsabilita' sua.

La correttezza e' un altro discorso che ovviamente non fa parte del processo giudiziario
(pero' in giudizio una sentenza puo' essere aggravata dalla premeditazione.. ad esempio)

La premeditazione subentra in caso di reato. Se il suo strumento permette il rispetto dei termini legali della licenza, la correttezza rimane un punto di vista personale.

Comunque, ripeto, anch'io avevo letto di tecniche già usate per aggirare la viralità della GPL; posterò eventuali link appena riuscirò a trovare ulteriori informazioni più dettagliate. :D

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)

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 quella del 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.

L'open source è nato proprio per non parlare delle tematiche "ideologiche" della GPL, infatti Stallman sbraita sempre contro chi parla di Open Source e non di Free Software.

Quindi, io spero che tu utilizzi esclusivamente free software, cioè, ad esempio:

- una delle distro GNU/Linux ufficialmente supportate dalla FSF
- uno smartphone che faccia girare Replicant.

Altrimenti non va bene.

:confused: :confused:
Stai facendo un discorso che non ha proprio la minima logica.
Perche' non andrebbe bene?
Perche' devi sperare che io usi software free?

Perché tu hai scritto:"La filosfia della licenza GPL (copyleft) sono ben precise e chiare.
Senza dubbi. Senza interpretazioni."

Se tu supporti e sostieni vivamente la filosofia della FSF (di cui la GPL è figlia) devi farlo come si deve. La GPL esiste solo ed esclusivamente per un motivo: far sparire tutto il software che NON rispetta le 4 libertà. Altrimenti non avrebbe alcun senso la sua viralità. Anzi, è l'intero progetto GNU che ha solo e soltanto questo scopo.

Qui (https://www.gnu.org/distros/common-distros.html) c'è un elenco di distribuzioni che NON rispetta la politica della FSF, con le varie motivazioni.

Quindi, ripeto, per correttezza e coerenza mi aspetto che i sostenitori del Free Software seguano la filosofia fino in fondo.

Attaccare il software closed, parlare della superiorità di quello libero, e poi usare un iPhone è insensato. No?

Non vedo perche il tema del topic tu lo debba spostare sulle mie abitudini.

Sostenere il software libero, anche con forza, non implica il non acquistare software chiuso o a pagamento.

Sostenere un'ideologia significa, appunto, sostenerla. Se si ritiene che il software libero sia la via corretta da seguire, a rigor di logica non ha senso supportare economicamente software chiuso.

Per chi sostiene veramente il free software tra Windows, iOS e macOS non c'è alcuna differenza: sono da evitare a prescindere dalla bontà tecnica.

Quindi, per Stallman, anche il tuo acquistare (e quindi rinforzare economicamente) software NON GPL "e' contro tutto questo [che hai tirato fuori parlando dello scopo della GPL]".

A me delle tue abitudini non importa, ovviamente, ma siccome la GPL è lo strumento legale di una ben precisa ideologia, mi sembra un po' incoerente sostenere una cosa e non l'altra, all'atto pratico.

Questo perche vedi il mondo bianco o nero.
Esiste il grigio.

Secondo il tuo ragionamento tutte le persone che sono contro un governo, come gli italiani che criticano spesso aspramente l'operato dei nostri politici, dovrebbero, per coerenza, o organizzare una rivoluzione o andare via da questo paese.
Perche se resti qui, con le tue tasse, i tuoi voti, anche di protesta, comunque foraggi il sistema, che continua a andare avanti.

Tutti quelli che sono contro l'inquinamento o le guerre, dovrebbero per coerenza iniziare ad andare a piedi, non usare piu uno spray, boicottare le macrocoltivazioni che usano prodotti chimici eccetera eccetera eccetera.

Se sei per il rispetto della vita umana, come anche penso che tu sia, dovresti fare tante cose, in piccolo, per esempio, dovresti non usare piu un PC tablet ecc perche nelle miniere di cobalto sfruttano i bimbi.

Sempre se rispetti l'ambiente e la vita, come penso che fai anche te, non dovresti piu mangiare le banane, perche per fornire il tonnellaggio richiesto per l'export, fanno dei casini allucinanti , inquinano e muore gente.

e cosi via.

Nella vita esiste il grigio, fatevene una ragione

Eh no, mi dispiace, ed è lo stesso Stallman a dire che tutto il software deve essere libero. E Stallman, fino a prova contraria, è il Presidente della FSF, nonché fondatore, nonché ideologo, nonché padre di GNU e della GPL. GNU che, ripeto, è nato esclusivamente per questioni ideologiche, e lo ripeto. Quindi, usarne versioni annacquate (perché sì, il free software è una figata, ma i driver binari di nVidia fanno andare meglio la mia GPU) significa non aiutare la causa.

Dunque, se sostieni ideologicamente la GPL e il software libero, devi andare contro tutto il software closed, e, di conseguenza, non acquistarlo né usarlo.

Altrimenti, diciamo che si fa distinzione tra software closed in base a chi lo sviluppa e distribuisce.

Se sostieni il rispetto della vita umana smetti di usare il cell perche i ripetitori fanno venire i tumori e il cobalto viene estratto sfruttando il lavoro minorile.

Vorrà dire che siamo due ipocriti. :)

Ma il punto è che si è passati dalla validità legale di una licenza, alla correttezza, al rispetto dell'ideologia di fondo, che però non sostieni nemmeno tu, in quanto i soldi li dai anche al "nemico", foraggiando ulteriormente lo sviluppo di software closed.

Allora hai proprio capito male tutto il discorso fin dal'inizio.
Io ho solo condannato la ricerca di un metodo cavilloso per fottere l'ideologia che incarna la licenza di tipo GPL.

Io se compro software chiuso non faccio nulla di male, al massimo faro i conti con me stesso sul mio concetto interiore di coerenza, che riguarda una mia riflessione personale e non interessa a nessuno.

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

Non perche' non sia possibile, ma perche' Torvalds e' in disaccordo con alcuni termini della GPL3. Se si rendesse necessario aggiungere delle clausule che ritiene piu' opportune niente gli vieta di farlo.

Lo so, ma il punto è che lui stesso ha detto che mai e poi mai passerà alla GPLv3, perché pure a lui dell'aspetto ideologico frega meno di niente.

Il kernel linux e' comunque sotto GPL2 e non altre licenze perche' comunque Linus stesso crede in un modello di sviluppo in cui i sorgenti e le modifiche sono sempre disponibili e modificabili.
Credo che integrare codice offuscato vada in ogni caso contro il pensiero di Torvalds, che e' pragmatico ma di certo non apolitico . Di conseguenza non mi farei troppe illusioni...

(che poi quello che non sta bene a Torvalds della GPL 3 e' la clausola sulla tivoization. che piu' o meno non c'entra una mazza con il discorso in corso)

Beh, ora non ricordo nel dettaglio, ma se non ricordo male non è tanto una questione politica, quanto che a lui interessava (quando licenziò il kernel) avere la certezza di ricevere le modifiche al codice e che, inoltre, nessuno potesse appropriarsi del suo lavoro per realizzare un prodotto chiuso e farci su un sacco di soldi.

Ma comunque Torvalds è in completo disaccordo con la FSF.

Comunque so che si incazzerebbe, o almeno lo immagino, ma già oggi il kernel è pieno di blob binari, no? Tant'è che le distro libere devono prima "ripulire" Linux.

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 :ciapet:
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 :mc: ) 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 :sofico:

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!:read:




@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à " :ciapet:

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

Ipotesi e tesi si basano su assunzioni REALISTICHE...sbagliate le quali, le conclusioni non possono che essere incorrette :D
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 :read: ( e due !)

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? :rolleyes: :mc:
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.
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... :muro:

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.

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 (https://github.com/01org/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. :muro:
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...

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:D , 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.

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... :rolleyes:

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. :read:

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 (https://www.theguardian.com/technology/2017/jan/16/whatsapp-vulnerability-facebook).
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."

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

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.
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 (https://www.theguardian.com/technology/2017/jan/16/whatsapp-vulnerability-facebook).
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.

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.


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.


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


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.


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 (https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic) 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 (https://www.gnu.org/licenses/gpl-faq.html#UnreleasedMods) una copia del codice sorgente.

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.


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.


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.


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.


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 (https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic) 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 (https://www.gnu.org/licenses/gpl-faq.html#UnreleasedMods) una copia del codice sorgente.

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. :rolleyes:


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


Che si riconduce proprio al teorema dell'arresto. Stessa pagina, poco più avanti: Proof by reduction to the halting problem (https://en.wikipedia.org/wiki/Rice%27s_theorem#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.


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.


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.


How many lines of code are in the Linux kernel? (https://www.quora.com/How-many-lines-of-code-are-in-the-Linux-kernel?share=1):

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


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?


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.


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. :read:

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


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


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 (https://it.wikipedia.org/wiki/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.


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.

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 (http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/open-source-security.html) 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 (https://www.bloomberg.com/news/articles/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers) usava (https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013) 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.

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.

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. :D

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

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

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. :D

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.