Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

GIGABYTE GAMING A16, Raptor Lake e RTX 5060 Laptop insieme per giocare al giusto prezzo
GIGABYTE GAMING A16, Raptor Lake e RTX 5060 Laptop insieme per giocare al giusto prezzo
Il Gigabyte Gaming A16 offre un buon equilibrio tra prestazioni e prezzo: con Core i7-13620H e RTX 5060 Laptop garantisce gaming fluido in Full HD/1440p e supporto DLSS 4. Display 165 Hz reattivo, buona autonomia e raffreddamento efficace; peccano però le USB e la qualità cromatica del pannello. Prezzo: circa 1200€.
iPhone 17 Pro: più di uno smartphone. È uno studio di produzione in formato tascabile
iPhone 17 Pro: più di uno smartphone. È uno studio di produzione in formato tascabile
C'è tanta sostanza nel nuovo smartphone della Mela dedicato ai creator digitali. Nuovo telaio in alluminio, sistema di raffreddamento vapor chamber e tre fotocamere da 48 megapixel: non è un semplice smartphone, ma uno studio di produzione digitale on-the-go
Intel Panther Lake: i processori per i notebook del 2026
Intel Panther Lake: i processori per i notebook del 2026
Panther Lake è il nome in codice della prossima generazione di processori Intel Core Ultra, che vedremo al debutto da inizio 2026 nei notebook e nei sistemi desktop più compatti. Nuovi core, nuove GPU e soprattutto una struttura a tile che vede per la prima volta l'utilizzo della tecnologia produttiva Intel 18A: tanta potenza in più, ma senza perdere in efficienza
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 16-03-2016, 20:44   #61
matteop3
Senior Member
 
Iscritto dal: Jan 2016
Messaggi: 320
Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Appunto l'hai appena detto. E' l'unica valutazione comparativa disponibile fatta da un ente terzo e imparziale. Fatti una domanda del perchè tutti te la riportano...



No. Ancora? Whatsapp è a sorgente chiuso. Come fai a negarlo? Leggi anche su Wikipedia
Inoltre il codice di Signal è GPLv3 il che rende impossibile utilizzarlo in un programma a sorgente chiuso con licenza proprietaria come Whatsapp (Whatsapp non può utilizzare lo stesso codice di Signal, ma solo il suo protocollo con nuovo codice scritto da zero leggi). E' il fondamento della licenza copyleft GPL.

Telegram ha il codice sorgente per tutti i client aperto
Le API per sviluppare i BOT e le applicazioni aperte
Protocollo Mproto e FAQ tenciche

Per favore invece di dire sciocchezze, documentati...
Io davvero mi chiedo se tu abbia letto una sola parola di tutto quel che ho scritto.
matteop3 è offline   Rispondi citando il messaggio o parte di esso
Old 16-03-2016, 21:18   #62
Erotavlas_turbo
Senior Member
 
Iscritto dal: Jun 2007
Messaggi: 768
Quote:
Originariamente inviato da matteop3 Guarda i messaggi
Le chat normali di Telegram NON utilizzano la crittografia end-to-end, occhio (ma probabilmente lo sai già).
https://telegram.org/faq/it#d-quindi...grafate-i-dati
Dal link che hai riportato tu. La nostra crittografia è basata sulla crittografia AES simmetrica a 256-bit, sulla crittografia RSA 2048 e sullo scambio di chiavi di sicurezza Diffie-Hellman.
Questo significa che utilizzano sia la crittografia asimmetrica RSA sia quella simmetrica AES. La differenza è solo una: il client è open source quindi puoi vedere l'implementazione del codice per la connessione e la crittografia end-to-end mentre il server è closed source e quindi non puoi vedere l'implementazione del codice per la connessione e la crittografia client-server.
Un implementazione di un sistema di crittografia closed source non è affidabile per definizione e la connessione client-server non è affidabile.

Quote:
Originariamente inviato da matteop3 Guarda i messaggi
Le chat segrete si affidano al traballante MTProto (certo, è comunque meglio che usare le chat normali).
Si? Fonti per questa affermazione? Ti ripeto l'unica comparativa è quella della EFF che da 7/7 alle chat segrete e 4/7 alle chat pubbliche di Telegram. Whatsapp si ferma a 2/7.

Quote:
Originariamente inviato da matteop3 Guarda i messaggi
Il fatto di essere open source dà una sicurezza potenziale, non certa; un software open source non è intrinsecamente sicuro perché è open source eh.
Vero. Un codice open source è affidabile proprio perché tutti possono controllare la sua implementazione. Un codice closed source è inaffidabile per definizione. Nessuno può controllarlo solo la casa produttrice.

Quote:
Originariamente inviato da matteop3 Guarda i messaggi
Crittografia client-server è molto diverso da crittografia end-to-end, l'unica che realmente garantisce che solo mittente e destinatario accedano in chiaro ai messaggi, quindi le chat normali di Telegram non sono sicure.
http://www.hwupgrade.it/forum/showpo...1&postcount=38
Si le chat normali di Telegram non sono sicure perché il codice del server di Telegram è chiuso e non possiamo vedere se ci sono back door e la sua implementazione.
Erotavlas_turbo è offline   Rispondi citando il messaggio o parte di esso
Old 16-03-2016, 21:21   #63
Erotavlas_turbo
Senior Member
 
Iscritto dal: Jun 2007
Messaggi: 768
Quote:
Originariamente inviato da matteop3 Guarda i messaggi
Io davvero mi chiedo se tu abbia letto una sola parola di tutto quel che ho scritto.
Si me lo chiedo anche io. Non conosci la differenza tra open source e closed source. Difendi per forza Whatsapp dicendo che utilizza il codice di Signal quando questo è impossibile a causa delle licenze software...Whatsapp ha ricevuto un punteggio bassissimo dall'unica comparativa imparziale presente in rete della EFF.
Vedi tu. Io non ho più niente da dire.
Erotavlas_turbo è offline   Rispondi citando il messaggio o parte di esso
Old 16-03-2016, 21:35   #64
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Un codice open source è affidabile proprio perché tutti possono controllare la sua implementazione.
Falso. Lo dimostra il caso OpenSSH.

Lo dimostrano pure le recentissime falle venite fuori dopo diversi anni esclusivamente grazie al lavoro di review di Google e Red Hat (che sono aziende che hanno precisi interessi).
Quote:
Un codice closed source è inaffidabile per definizione.
Falso. Il fatto che non siano disponibili i sorgenti non è, logica alla mano, dimostrazione che un software sia inaffidabile. Può benissimo essere affidabilissimo. Semplicemente il codice che lo genera non è disponibile a tutti.
Quote:
Nessuno può controllarlo solo la casa produttrice.
Falso anche questo. Mai sentito parlare di reverse engineering?
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 16-03-2016, 22:07   #65
matteop3
Senior Member
 
Iscritto dal: Jan 2016
Messaggi: 320
Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Si le chat normali di Telegram non sono sicure perché il codice del server di Telegram è chiuso e non possiamo vedere se ci sono back door e la sua implementazione.
Le chat normali di Telegram non sono insicure perché il server è closed source, lo sono perché la crittografia client-server (a differenza di quella end-to-end) non impedisce al server di poter leggere in chiaro i contenuti delle conversazioni, open/closed non c'entra nulla in questa circostanza.
matteop3 è offline   Rispondi citando il messaggio o parte di esso
Old 16-03-2016, 22:10   #66
matteop3
Senior Member
 
Iscritto dal: Jan 2016
Messaggi: 320
Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Non conosci la differenza tra open source e closed source.
O.o

Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Difendi per forza Whatsapp dicendo che utilizza il codice di Signal quando questo è impossibile a causa delle licenze software...
Evidentemente quando prima te l'ho linkato non l'hai aperto: https://whispersystems.org/blog/whatsapp/

At Open Whisper Systems, our goal is to make private communication simple. For the past three years, we’ve been developing a modern, open source, strong encryption protocol for asynchronous messaging systems, designed to make seamless end-to-end encrypted messaging possible.
Today we’re excited to publicly announce a partnership with WhatsApp, the most popular messaging app in the world, to incorporate the TextSecure protocol into their clients and provide end-to-end encryption for their users by default.

Ultima modifica di matteop3 : 16-03-2016 alle 22:13.
matteop3 è offline   Rispondi citando il messaggio o parte di esso
Old 16-03-2016, 23:01   #67
Nui_Mg
Senior Member
 
L'Avatar di Nui_Mg
 
Iscritto dal: Jan 2007
Messaggi: 6671
Io attendo l'effettiva e conclusa implementazione per esprimere giudizio, chi vivrà vedrà, attualmente sono solo leggermente scettico, anche conoscendo Zuckerotto e la mission del suo core business.

C'è comunque una cosa che sinceramente mi scoccia (che impongono un po' tutti, tranne skype, hangouts, viber e qualche altro) e cioè il registrarsi/accedere solo fornendo obbligatoriamente il numero telefonico. I messagersinternet oriented sono usatissimi anche da chi non usa in alcun modo la rete cellulare (per limiti tecnici, vedi tanti tablet basici con solo wifi, oppure per inutilità di spendere maggiormente perché magari si è sempre coperti da wifi, per esempio scuola, casa, lavoro).
Nui_Mg è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 07:19   #68
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3826
[quote=Erotavlas_turbo;43483227]
Un implementazione di un sistema di crittografia closed source non è affidabile per definizione e la connessione client-server non è affidabile.
[/QUOT]

Allora dimostra (nel senso matematico del termine) che il poter leggere il sorgente sia GARANZIA di affidabilità.
I programmi si sviluppano nello stesso, identico, modo, indipendentemente dal tipo di licenza con cui vengono distribuiti.

Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Vero. Un codice open source è affidabile proprio perché tutti possono controllare la sua implementazione. Un codice closed source è inaffidabile per definizione. Nessuno può controllarlo solo la casa produttrice.
IN TEORIA, perché, in pratica, CHI legge i sorgenti? Come ha detto cdimauro, oltre alla clamorosa vicenda OpenSSH (che sarebbe anche una libreria un filino importante), andrebbe ricordato che le ultime falle, presenti da anni, sono state individuate da Google e Red Hat, che non sono affatto gli hacker della comunità, ma aziende votate al lucro. Quindi, gira e rigira, scopriamo che il codice dei progetti grossi lo leggono (e comprendono) solo quelli che ci lavorano?

Senza dimenticare che la sicurezza di un algoritmo nel settore della sicurezza è una caratteristica matematica, al netto, ovviamente, di SEMPRE possibili errori nell'implementazione, open o closed che sia.
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 08:59   #69
calabar
Senior Member
 
L'Avatar di calabar
 
Iscritto dal: Oct 2001
Messaggi: 14736
Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Si me lo chiedo anche io. Non conosci la differenza tra open source e closed source. Difendi per forza Whatsapp dicendo che utilizza il codice di Signal quando questo è impossibile a causa delle licenze software...Whatsapp ha ricevuto un punteggio bassissimo dall'unica comparativa imparziale presente in rete della EFF.
Vedi tu. Io non ho più niente da dire.
Credo che tu abbia frainteso la sua posizione.
Lui non difende WhatsApp (anzi...), ma ritiene il protocolo TextSecure ottimo e si felicita della sua adozione in WhatsApp.

Sui problemi di sicurezza di Telegram ci sono in rete diversi documenti da leggere (anche io in passato ne ho linkato qualcuno) che evidenziano problemi nell'intera architettura e mostrano come certi tipi di test (in cui Telegram ne esce bene) siano anche essi concettualmente fallati (ossia non ci sia una corrispondenza tra il risultato del test e la sicurezza reale).
Non chiedermi di linkarli anche qui perchè non ho davvero il tempo di cercarli di nuovo.

Il fatto che venga usato per WhatsApp direi che è possibilissimo.
GPLv3 non è totalmente chiusa al software commerciale e il software può essere integrato (alle dovute condizioni), senza contare che nulla vieta ai programmatori di Signal, che ne sono i fautori, di rilasciare il codice direttamente a WhatsAPP sotto altra licenza (del resto se c'è una collaborazione...).

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Falso. ...
Mi sembra che tu non abbia affatto colto il punto del discorso.

Non si parlava della qualità del software (e citare problemi e bug non serve a nulla, dato che tutti sanno che nessun softare è totalmente sicuro da questo punto di vista, né quello open, né quello close), ma del fatto che in un software closed source non si è in grado di verificare come di fatti utilizzi questa sicurezza.
Certo, se hai totale fiducia in una casa software per te può essere lo stesso, ma per chi è un po' più diffidente la differenza è abissale.

In altre parole, se io ho la competenza, posso controllare il codice del software e verificare se in effetti i miei dati cifrati non vengano letti da chi non deve o rimangano scoperti durante qualche passaggio.
Più in generale, dato che questa competenza non è certo alla portata di tutti, il rilascio del codice sorgente garantisce che chi ha competenza e interesse (anche i tuoi "avversari", che ovviamente avrebbero tutto l'interesse a far emergere il problema) possa di fatto verificare che le cose siano state fatte come si deve, e denunciare la cosa in caso contrario.

Ultima modifica di calabar : 17-03-2016 alle 09:02.
calabar è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 13:25   #70
matteop3
Senior Member
 
Iscritto dal: Jan 2016
Messaggi: 320
Quote:
Originariamente inviato da calabar Guarda i messaggi
Sui problemi di sicurezza di Telegram ci sono in rete diversi documenti da leggere (anche io in passato ne ho linkato qualcuno) che evidenziano problemi nell'intera architettura e mostrano come certi tipi di test (in cui Telegram ne esce bene) siano anche essi concettualmente fallati (ossia non ci sia una corrispondenza tra il risultato del test e la sicurezza reale).
Non chiedermi di linkarli anche qui perchè non ho davvero il tempo di cercarli di nuovo.
Sì, tutto ciò si riferisce al loro famoso crypto-contest, un'enorme "truffa".
Qui due post molto interessanti a riguardo:
http://www.cryptofails.com/post/7054...alysis-contest
http://www.thoughtcrime.org/blog/tel...pto-challenge/

Quote:
Originariamente inviato da calabar Guarda i messaggi
Mi sembra che tu non abbia affatto colto il punto del discorso.

Non si parlava della qualità del software (e citare problemi e bug non serve a nulla, dato che tutti sanno che nessun softare è totalmente sicuro da questo punto di vista, né quello open, né quello close), ma del fatto che in un software closed source non si è in grado di verificare come di fatti utilizzi questa sicurezza.
Certo, se hai totale fiducia in una casa software per te può essere lo stesso, ma per chi è un po' più diffidente la differenza è abissale.

In altre parole, se io ho la competenza, posso controllare il codice del software e verificare se in effetti i miei dati cifrati non vengano letti da chi non deve o rimangano scoperti durante qualche passaggio.
Più in generale, dato che questa competenza non è certo alla portata di tutti, il rilascio del codice sorgente garantisce che chi ha competenza e interesse (anche i tuoi "avversari", che ovviamente avrebbero tutto l'interesse a far emergere il problema) possa di fatto verificare che le cose siano state fatte come si deve, e denunciare la cosa in caso contrario.
Esatto, è proprio questa la vera forza del concetto di open source. A livello pratico non incide sull'effettiva sicurezza, ma è comunque un requisito importante (se non altro in prospettiva) per un software che voglia definirsi sicuro.
matteop3 è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 17:30   #71
Erotavlas_turbo
Senior Member
 
Iscritto dal: Jun 2007
Messaggi: 768
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Falso. Lo dimostra il caso OpenSSH.

Lo dimostrano pure le recentissime falle venite fuori dopo diversi anni esclusivamente grazie al lavoro di review di Google e Red Hat (che sono aziende che hanno precisi interessi).
Un codice open source è affidabile proprio per questo motivo. Se ci sono falle inserite volutamente o meno prima o poi vengono fuori...
Il codice closed source non ti garantisce questo aspetto.

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Falso. Il fatto che non siano disponibili i sorgenti non è, logica alla mano, dimostrazione che un software sia inaffidabile. Può benissimo essere affidabilissimo. Semplicemente il codice che lo genera non è disponibile a tutti.
Certo ma un codice con sorgenti disponibili ti consente di vedere come è stato fatto e questo è fondamentale per un software che mira a gestire la riservatezza...

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Falso anche questo. Mai sentito parlare di reverse engineering?
Si vuoi mettere il reverse engineering con avere il codice sorgente disponibile? Hai mai fatto una prova?

Il punto focale è la trasparenza che un codice chiuso non fornisce e non potrà mai fornire e per questo è intrinsecamente inaffidabile.

Ultima modifica di Erotavlas_turbo : 17-03-2016 alle 17:48.
Erotavlas_turbo è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 17:38   #72
Erotavlas_turbo
Senior Member
 
Iscritto dal: Jun 2007
Messaggi: 768
Quote:
Originariamente inviato da GTKM Guarda i messaggi
Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Un implementazione di un sistema di crittografia closed source non è affidabile per definizione e la connessione client-server non è affidabile.
Allora dimostra (nel senso matematico del termine) che il poter leggere il sorgente sia GARANZIA di affidabilità.
I programmi si sviluppano nello stesso, identico, modo, indipendentemente dal tipo di licenza con cui vengono distribuiti.
Dato lo stesso algoritmo con due implementazioni open source e closed source, solo la prima è trasparente e ti consente di vedere l'implementazione. La seconda è inaffidabile per definizione. Ti devi fidare di chi la implementa.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
IN TEORIA, perché, in pratica, CHI legge i sorgenti? Come ha detto cdimauro, oltre alla clamorosa vicenda OpenSSH (che sarebbe anche una libreria un filino importante), andrebbe ricordato che le ultime falle, presenti da anni, sono state individuate da Google e Red Hat, che non sono affatto gli hacker della comunità, ma aziende votate al lucro. Quindi, gira e rigira, scopriamo che il codice dei progetti grossi lo leggono (e comprendono) solo quelli che ci lavorano?
Anche questo è vero. Sono le grandi aziende che sostengono la filosofia open source, ma per loro interessi non per motivi etici, ad apportare le grandi modifiche. Questo è normale considerando quanti dipendenti abbiano se paragonato al singolo esperto hacker.

Quote:
Originariamente inviato da GTKM Guarda i messaggi
Senza dimenticare che la sicurezza di un algoritmo nel settore della sicurezza è una caratteristica matematica, al netto, ovviamente, di SEMPRE possibili errori nell'implementazione, open o closed che sia.
Certo, ripeto dato lo stesso algoritmo con due implementazioni open source e closed source, solo la prima è trasparente e ti consente di vedere l'implementazione. La seconda è inaffidabile per definizione. Ti devi fidare di chi la implementa.
Erotavlas_turbo è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 17:46   #73
Erotavlas_turbo
Senior Member
 
Iscritto dal: Jun 2007
Messaggi: 768
Quote:
Originariamente inviato da calabar Guarda i messaggi
Credo che tu abbia frainteso la sua posizione.
Lui non difende WhatsApp (anzi...), ma ritiene il protocolo TextSecure ottimo e si felicita della sua adozione in WhatsApp.
Non mi pare se rileggi tutto il thread.

Quote:
Originariamente inviato da calabar Guarda i messaggi
Sui problemi di sicurezza di Telegram ci sono in rete diversi documenti da leggere (anche io in passato ne ho linkato qualcuno) che evidenziano problemi nell'intera architettura e mostrano come certi tipi di test (in cui Telegram ne esce bene) siano anche essi concettualmente fallati (ossia non ci sia una corrispondenza tra il risultato del test e la sicurezza reale).
Non chiedermi di linkarli anche qui perchè non ho davvero il tempo di cercarli di nuovo.
Può essere...non c'è un'analisi valida di Telegram oltre che la EFF. Puoi riportarla...

Quote:
Originariamente inviato da calabar Guarda i messaggi
Il fatto che venga usato per WhatsApp direi che è possibilissimo.
GPLv3 non è totalmente chiusa al software commerciale e il software può essere integrato (alle dovute condizioni), senza contare che nulla vieta ai programmatori di Signal, che ne sono i fautori, di rilasciare il codice direttamente a WhatsAPP sotto altra licenza (del resto se c'è una collaborazione...).
No questo non è possibile. Non puoi includere o linkare codice open source con licenza GPL dentro un codice proprietario quindi closed source (la licenza BSD per esempio ti consente questo). Puoi vendere un prodotto che utilizza codice open source con licenza GPL, ma devi rilasciare il codice con la stessa licenza open source GPL.


Quote:
Originariamente inviato da calabar Guarda i messaggi
Mi sembra che tu non abbia affatto colto il punto del discorso.

Non si parlava della qualità del software (e citare problemi e bug non serve a nulla, dato che tutti sanno che nessun softare è totalmente sicuro da questo punto di vista, né quello open, né quello close), ma del fatto che in un software closed source non si è in grado di verificare come di fatti utilizzi questa sicurezza.
Certo, se hai totale fiducia in una casa software per te può essere lo stesso, ma per chi è un po' più diffidente la differenza è abissale.

In altre parole, se io ho la competenza, posso controllare il codice del software e verificare se in effetti i miei dati cifrati non vengano letti da chi non deve o rimangano scoperti durante qualche passaggio.
Più in generale, dato che questa competenza non è certo alla portata di tutti, il rilascio del codice sorgente garantisce che chi ha competenza e interesse (anche i tuoi "avversari", che ovviamente avrebbero tutto l'interesse a far emergere il problema) possa di fatto verificare che le cose siano state fatte come si deve, e denunciare la cosa in caso contrario.
Esatto!!!
Erotavlas_turbo è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 17:51   #74
Erotavlas_turbo
Senior Member
 
Iscritto dal: Jun 2007
Messaggi: 768
Quote:
Originariamente inviato da matteop3 Guarda i messaggi
Sì, tutto ciò si riferisce al loro famoso crypto-contest, un'enorme "truffa".
Qui due post molto interessanti a riguardo:
http://www.cryptofails.com/post/7054...alysis-contest
http://www.thoughtcrime.org/blog/tel...pto-challenge/


Esatto, è proprio questa la vera forza del concetto di open source. A livello pratico non incide sull'effettiva sicurezza, ma è comunque un requisito importante (se non altro in prospettiva) per un software che voglia definirsi sicuro.
Leggi cosa c'è scritto qui.
Want to make sure your code never ends up on Crypto Fails? I provide an inexpensive security auditing service, with discounts for free software!
Mi dovrei fidare di questo privato che chiede soldi e non della EFF?
Mi fai ridere...
Riportami qualcosa di serio...
Erotavlas_turbo è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 17:57   #75
matteop3
Senior Member
 
Iscritto dal: Jan 2016
Messaggi: 320
Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Non mi pare se rileggi tutto il thread.
Ma dai, ma sei serio?

Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
No questo non è possibile. Non puoi includere o linkare codice open source con licenza GPL dentro un codice proprietario quindi closed source (la licenza BSD per esempio ti consente questo). Puoi vendere un prodotto che utilizza codice open source con licenza GPL, ma devi rilasciare il codice con la stessa licenza open source GPL.
Ho visto poche persone negare l'evidenza dei fatti in questo modo, tu sei una di quelle.

Ma per curiosità, hai aperto il post del blog di Open Whisper Systems che ti ho linkato prima? Ho anche riportato qui sul forum l'estratto chiave. L'hai letto?
http://www.hwupgrade.it/forum/showpo...8&postcount=66

Ultima modifica di matteop3 : 17-03-2016 alle 18:05.
matteop3 è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 18:00   #76
matteop3
Senior Member
 
Iscritto dal: Jan 2016
Messaggi: 320
Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Leggi cosa c'è scritto qui.
Want to make sure your code never ends up on Crypto Fails? I provide an inexpensive security auditing service, with discounts for free software!
Mi dovrei fidare di questo privato che chiede soldi e non della EFF?
Mi fai ridere...
Riportami qualcosa di serio...
Ti vorrei fare una domanda. Cosa non ti convince di ciò che c'è scritto nei post che ti ho linkato? Entriamo nel merito e analizziamo la validità di cosa c'è scritto e non di chi l'ha scritto.
matteop3 è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 20:50   #77
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Quote:
Originariamente inviato da calabar Guarda i messaggi
Mi sembra che tu non abbia affatto colto il punto del discorso.

Non si parlava della qualità del software (e citare problemi e bug non serve a nulla, dato che tutti sanno che nessun softare è totalmente sicuro da questo punto di vista, né quello open, né quello close), ma del fatto che in un software closed source non si è in grado di verificare come di fatti utilizzi questa sicurezza.
Certo, se hai totale fiducia in una casa software per te può essere lo stesso, ma per chi è un po' più diffidente la differenza è abissale.

In altre parole, se io ho la competenza, posso controllare il codice del software e verificare se in effetti i miei dati cifrati non vengano letti da chi non deve o rimangano scoperti durante qualche passaggio.
Più in generale, dato che questa competenza non è certo alla portata di tutti, il rilascio del codice sorgente garantisce che chi ha competenza e interesse (anche i tuoi "avversari", che ovviamente avrebbero tutto l'interesse a far emergere il problema) possa di fatto verificare che le cose siano state fatte come si deve, e denunciare la cosa in caso contrario.
Il senso del discorso mi era chiaro, ma io sono intervenuto sulla parte strettamente tecnica.

Premesso questo, non è vero che il software closed non si possa verificare. Intanto c'è il reverse engineering che ho citato prima. Poi ci sono società di analisi della sicurezza che possono accedere ai sorgenti e validarli.
Quote:
Originariamente inviato da matteop3 Guarda i messaggi
Esatto, è proprio questa la vera forza del concetto di open source. A livello pratico non incide sull'effettiva sicurezza, ma è comunque un requisito importante (se non altro in prospettiva) per un software che voglia definirsi sicuro.
Allora mi daresti una definizione oggettiva e incontrovertibile di software "sicuro"?
Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
Un codice open source è affidabile proprio per questo motivo. Se ci sono falle inserite volutamente o meno prima o poi vengono fuori...
Questo non è affatto dimostrato: possono benissimo rimanere non scoperte.
Quote:
Il codice closed source non ti garantisce questo aspetto.
Anche questo non è affatto dimostrato. Dimentichi che quello che per te è codice closed, per tante altre persone non lo è, perché:
- ci lavorano (banale e ovvio);
- ci fanno reverse engineering;
- ci fanno analisi (vedi sopra).
Quote:
Certo ma un codice con sorgenti disponibili ti consente di vedere come è stato fatto e questo è fondamentale per un software che mira a gestire la riservatezza...
La cosa fondamentale è gestire la riservatezza.

I sorgenti disponibili non sono di per sé garanzia di ciò. Vedi gli esempi che ho fatto prima.
Quote:
Si vuoi mettere il reverse engineering con avere il codice sorgente disponibile? Hai mai fatto una prova?
Direi proprio di sì, e non sono affatto l'unico.
Quote:
Il punto focale è la trasparenza che un codice chiuso non fornisce e non potrà mai fornire e per questo è intrinsecamente inaffidabile.
E' un'asserzione che rimane falsa, per quanto già detto.

Ma puoi sempre dimostrare il contrario, se ci riesci.
Quote:
Originariamente inviato da Erotavlas_turbo Guarda i messaggi
No questo non è possibile. Non puoi includere o linkare codice open source con licenza GPL dentro un codice proprietario quindi closed source (la licenza BSD per esempio ti consente questo). Puoi vendere un prodotto che utilizza codice open source con licenza GPL, ma devi rilasciare il codice con la stessa licenza open source GPL.
Potresti sempre realizzare un loader con licenza GPL, che carica un binario (ad esempio una comune libreria condivisa/dinamica/DLL) generato da codice non GPL.

nVidia, se non ricordo male, per Linux ha uno stub open source con licenza GPL, che carica un blob binario che contiene il vero codice dei driver.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 21:06   #78
Erotavlas_turbo
Senior Member
 
Iscritto dal: Jun 2007
Messaggi: 768
Quote:
Originariamente inviato da matteop3 Guarda i messaggi
Ma dai, ma sei serio?
Si mi pare che tu voglia per forza sostenere whatsapp e criticare telegram senza aver argomentazioni valide in tale senso.

Quote:
Originariamente inviato da matteop3 Guarda i messaggi
Ho visto poche persone negare l'evidenza dei fatti in questo modo, tu sei una di quelle.

Ma per curiosità, hai aperto il post del blog di Open Whisper Systems che ti ho linkato prima? Ho anche riportato qui sul forum l'estratto chiave. L'hai letto?
http://www.hwupgrade.it/forum/showpo...8&postcount=66
Domanda: conosci la licenza GPL? Se no studiala e poi torna a rispondere...
Erotavlas_turbo è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 21:07   #79
Erotavlas_turbo
Senior Member
 
Iscritto dal: Jun 2007
Messaggi: 768
Quote:
Originariamente inviato da matteop3 Guarda i messaggi
Ti vorrei fare una domanda. Cosa non ti convince di ciò che c'è scritto nei post che ti ho linkato? Entriamo nel merito e analizziamo la validità di cosa c'è scritto e non di chi l'ha scritto.
Cosa non mi convince?
Queste parole:
Want to make sure your code never ends up on Crypto Fails? I provide an inexpensive security auditing service, with discounts for free software!
Prese dalla pagina about del sito che hai riportato
Erotavlas_turbo è offline   Rispondi citando il messaggio o parte di esso
Old 17-03-2016, 22:04   #80
Erotavlas_turbo
Senior Member
 
Iscritto dal: Jun 2007
Messaggi: 768
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Un codice open source è affidabile proprio per questo motivo. Se ci sono falle inserite volutamente o meno prima o poi vengono fuori...
Questo non è affatto dimostrato: possono benissimo rimanere non scoperte.
Si non è dimostrato, ma è un dato di fatto. In un codice closed source le falle vengono fuori molto più difficilmente o non vengono mai fuori...

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Anche questo non è affatto dimostrato. Dimentichi che quello che per te è codice closed, per tante altre persone non lo è, perché:
- ci lavorano (banale e ovvio);
- ci fanno reverse engineering;
- ci fanno analisi (vedi sopra).
Cioé?

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Il punto focale è la trasparenza che un codice chiuso non fornisce e non potrà mai fornire e per questo è intrinsecamente inaffidabile.
Un paragone che calza perfettamente per la trasparenza tra codice open source e codice closed source è quello tra un prodotto alimentare con etichetta dove vengono dichiarati gli ingredienti e la loro provenienza e un prodotto alimentare dove compare solo il nome del prodotto.
Per il secondo tipo di prodotto alimentare ci sono persone:
- che ci lavorano (banale e ovvio);
- ci fanno reverse engineering (cercando di capire gli ingredienti);
- ci fanno analisi (capendo il contenuto chimico se alterato, nocivo, etc.).
Alla fine rimane sempre un prodotto per cui il consumatore deve avere fiducia del produttore.
Open source -> trasparenza anche se non esente da bug
Closed source -> fiducia
Dopo lo scandalo Prism in cui NSA utilizzava le falle e le back door volutamente lasciate aperte dai maggiori protagonisti del software Google, Microsoft, Apple, Facebook, Yahoo, non c'è molto da fidarsi del codice closed source.

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Potresti sempre realizzare un loader con licenza GPL, che carica un binario (ad esempio una comune libreria condivisa/dinamica/DLL) generato da codice non GPL.

nVidia, se non ricordo male, per Linux ha uno stub open source con licenza GPL, che carica un blob binario che contiene il vero codice dei driver.
Questo è sbagliato. Direttamente dalla licenza GPLv2-GPLv3
The fourth section for version 2 of the license and the seventh section of version 3 require that programs distributed as pre-compiled binaries are accompanied by a copy of the source code, a written offer to distribute the source code via the same mechanism as the pre-compiled binary, or the written offer to obtain the source code that the user got when they received the pre-compiled binary under the GPL
Informati...
Erotavlas_turbo è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


GIGABYTE GAMING A16, Raptor Lake e RTX 5060 Laptop insieme per giocare al giusto prezzo GIGABYTE GAMING A16, Raptor Lake e RTX 5060 Lapt...
iPhone 17 Pro: più di uno smartphone. È uno studio di produzione in formato tascabile iPhone 17 Pro: più di uno smartphone. &Eg...
Intel Panther Lake: i processori per i notebook del 2026 Intel Panther Lake: i processori per i notebook ...
Intel Xeon 6+: è tempo di Clearwater Forest Intel Xeon 6+: è tempo di Clearwater Fore...
4K a 160Hz o Full HD a 320Hz? Titan Army P2712V, a un prezzo molto basso 4K a 160Hz o Full HD a 320Hz? Titan Army P2712V,...
Mango conferma violazione dati degli ute...
Apple Vision Pro si rinnova: ora è...
Memoria 2D: dimensioni atomiche che rivo...
ASML chiude il Q3 con 7,5 miliardi di ri...
Norvegia, obiettivo raggiunto: il 100% d...
Apple svela i nuovi iPad Pro con M5: un ...
Google Pixel 10 Pro e 10 Pro XL: due top...
Apple MacBook Pro 14'': ufficiale con ch...
HONOR 400 Smart debutta in Italia: batte...
Apple M5 è potentissimo: prestazi...
GrapheneOS non solo sui Pixel: confermat...
Microsoft subisce un duro colpo: land te...
Portatile tuttofare Lenovo a soli 399€ c...
Arriva anche su Radeon: lo scioglimento ...
SpaceX Starship: mostrati nuovi video de...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 16:17.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v
1