Microsoft AntiSpyware è disponibile in versione beta

[DevilsAdvocate]

Il primo motivo e' che per comprendere il codice lo devi
studiare, con una semplice lettura puoi giusto assicurarti che non ci siano errori di sintassi.
Il secondo motivo e' che il 99% delle vulnerabilita'
(c'e' un 1% di errore umano) dipendono da come il
compilatore gestisce i sorgenti stessi....
Ad esempio il solito stranominato buffer overflow,
se ci fai caso in quasi nessun programma il codice
fa riferimenti espliciti al buffer.
Quindi per trovare vulnerabilita' leggendo il codice
dovresti conoscere a menadito il compilatore e
tutti i modi in cui puo' compilare (vedi ad esempio
gcc che compila per intel 386, pentium, pentium 2,
athlon/xp, amd64 in modi diversi).

Semmai il codice aperto renderebbe possibile a
qualcuno "darti i sorgenti sbagliati" perche'
tu li compili e ne ottenga una versione del programma
con una backdoor "fatta in casa". Ma se i sorgenti
li prendi da fonti sicure, (caso di linux) o se
li ottieni gia' compilati da fonte certa, una
volta ottenuti per modificarteli l'hacker dovrebbe
gia'avere i privilegi di root (quindi una backdoor).

Inoltre se confronti il tempo per "studiare" 3 o 4 megabyte di sorgenti con quello che serve per
"testare sul campo" le vulnerabilita' usando il
programma assieme a tools autosviluppati (come poteva
essere un monitor dello stack per lo stack overflow),
si parla di tempi piu' grandi nell'ordine delle
decine......

[RaouL_BennetH]

Originariamente inviato da DevilsAdvocate
Il primo motivo e' che per comprendere il codice lo devi
studiare, con una semplice lettura puoi giusto assicurarti che non ci siano errori di sintassi.
Il secondo motivo e' che il 99% delle vulnerabilita'
(c'e' un 1% di errore umano) dipendono da come il
compilatore gestisce i sorgenti stessi....
Ad esempio il solito stranominato buffer overflow,
se ci fai caso in quasi nessun programma il codice
fa riferimenti espliciti al buffer.
Quindi per trovare vulnerabilita' leggendo il codice
dovresti conoscere a menadito il compilatore e
tutti i modi in cui puo' compilare (vedi ad esempio
gcc che compila per intel 386, pentium, pentium 2,
athlon/xp, amd64 in modi diversi).

Semmai il codice aperto renderebbe possibile a
qualcuno "darti i sorgenti sbagliati" perche'
tu li compili e ne ottenga una versione del programma
con una backdoor "fatta in casa". Ma se i sorgenti
li prendi da fonti sicure, (caso di linux) o se
li ottieni gia' compilati da fonte certa, una
volta ottenuti per modificarteli l'hacker dovrebbe
gia'avere i privilegi di root (quindi una backdoor).

Inoltre se confronti il tempo per "studiare" 3 o 4 megabyte di sorgenti con quello che serve per
"testare sul campo" le vulnerabilita' usando il
programma assieme a tools autosviluppati (come poteva
essere un monitor dello stack per lo stack overflow),
si parla di tempi piu' grandi nell'ordine delle
decine......

Difatti se hai notato il mio "semplice" era appunto tra virgolette.
Ma quello che volevo capire è:

Supponiamo che io sia uno degli sviluppatori di un kernel qualsiasi, e che io abbia il compito di curare la parte relativa ai driver, che so, usb per esempio.
Supposto che tale kernel sia open source, io scrivo il mio bel modulo con una gran bella backdoor dentro. Dato che il mio codice è visibile a tutti, cioè, è visibile a chi legge ma non capisce, a chi legge e capisce, a chi legge, scrive, capisce e modifica, e anche a chi non gli frega niente di leggere; ora, dato che, per una normale conseguenza di cose, di sicuro il mio codice sarà letto, straletto studiato e strastudiato dagli altri mantainer, credo che le possibilità che la mia backdoor passi inosservata sia pari a zero, cioè, la stessa possibilità che avrei di inserirla in un kernel closed dove lavora insieme a me un team di sviluppatori. Cioè, il fatto che la maggioranza degli utenti non sia capace di capire un sorgente è ovvio, ma è altrettanto ovvio che esiste una moltitudine di programmatori in grado di leggere e capire il contenuto.

La domanda quindi sarebbe:

E chi ti dice che i mantainer ti vengano a dire se c'è o non c'è una backdoor?

Allo stesso tempo credo sia lecito chiedersi:

E chi ti dice che in un software closed, non ci siano backdoor?

E qui, una delle possibili risposte potrebbe essere sulla facoltà, almeno, di avere uno strumento di verifica, nel senso che, appunto, in un software open esiste ALMENO la possibilità di PROVARE leggere e studiarne il contenuto.

Chiaro è che la maggior parte degli utenti, me compreso, devono in ogni caso fidarsi sia in una situazione open che in una closed, dato che, per molti, il problema di avere o meno a disposizione i sorgenti di una qualsiasi cosa non si pone perchè non avremmo comunque le capacità per comprenderne i contenuti.

Vorrei fare un altro esempio che mi riguarda:

L'ho detto già moltissime volte ma lo ripeto anche adesso:
io uso senza farmi troppi problemi sia windows che linux e, se ne avessi la possibilità, proverei senza indugio alcuno qualsiasi altra piattaforma oggi disponibile perchè amo conoscere e cercare di capire qualcosa senza farmi troppi pregiudizi. Non ho mai avuto un approccio del tipo questo è meglio di quello, ma cerco, nel limite delle mie capacità, di pensare sempre che ogni piattaforma sia diversa da un'altra. Premessa questa piccola cosa, faccio il mio piccolo esempio:

Ho fatto un programmino in visual basic, fatto l'exe e il programma fa quel che deve fare. Bene, se io distribuisco questo programma, seguendo la "prassi closed", installerò solo un eseguibile su un pc. Dentro questo eseguibile, solo io so cosa c'è dentro..... potrebbe anche esserci un controllo che fa delle operazioni all'insaputa dell'utente e che ne violi la privacy o altro.

Adesso, se invece io questo programma, lo distribuissi insieme ai sorgenti, prima o poi, qualcuno più smaliziato, che magari conosce bene visual basic, capirebbe al volo cosa fa un determinato modulo all'interno del sorgente, perchè all'interno di un linguaggio di programmazione qualsiasi, io posso "esprimermi" diversamente da qualcun altro, ma di sicuro non posso reinventarmi parole chiave, i cicli, il modo di operare sui socket etc..

Perciò ri-chiedo, questa, non è una "semplice" (occhio alle virgolette) esemplificazione di quello che avviene tra un software closed ed uno open?

[fek]

Originariamente inviato da RaouL_BennetH
Solo su questo tuo punto, potresti spiegarmi perchè non basterebbe una "semplice" lettura?

No polemica, sono solo curioso.

Il motivo principale e' perche' non c'e' nulla di piu' complicato che leggere codice scritto da altri, tanto piu' se questo codice non e' pensato per essere leggibile (come purtroppo e' la maggior parte del codice). Trent'anni di Ingegneria del Software hanno insegnato che non e' possibile leggere un programma come fosse un libro seduti in poltrona

Immagina di leggere il codice di un metodo, che magari richiede precondizioni che sono garantite da una o piu' classi in un'altra parte del codice che tu non hai ancora visto, oppure implementa la soluzione ad un problema che tu non hai ancora visto e non e' stato documentato. Come fai a capire se quel codice e' giusto o no a prima vista? Ricordati che state parlando della possibilita' di prendere i sorgenti di un qualunque progetto OS, leggerli e in poco tempo trovare i bug.
Se fosse possibile, non servirebbe a nulla testare il codice oppure avere un reparto di QA, basterebbe leggere il codice per risolvere tutti i problemi. Che bel mondo sarebbe

Esistono pratiche ben documentate per "leggere il codice" per trovare bug, ma chiamiamole col loro nome: Code Inspection.
Una Code Inspection formale prevede che io che ho scritto il codice e tu che lo hai letto ci sediamo davanti ad un tavolo e discutiamo sui problemi che pensi di aver trovato. Come facciamo ad organizzare una Code Inspection formale se io vivo in UK e tu in Italia? Dai, ti ospito io se mi porti gli spaghetti

E qui arrivo a rispondere a chi ha obiettato che un team closed source puo' essere "distribuito" in varie sedi sparse per il mondo. Vorrei un esempio concreto, perche' io non ho mai sentito parlare di un team che lavora sullo stesso modulo con programmatori distribuiti. Ho sentito parlare di team che magari scrivono il motore 3d (un modulo) in Europa ed il resto del gioco (un altro modulo) in Canda, come ad esempio la Ubisoft, ma mi pare diverso da un sistema di sviluppo che presuppone che chiunque in qualunque parte del mondo abbia la possibilita' di cambiare qualunque pezzo di codice in qualunque modulo.

Nel caso del team distribuito di Ubisoft, il team di game programmer e' cliente del team che scrive il motore 3d.

A questo punto una piccola curiosita': chi mi puo' mostrare come fare magari eXtreme Programming (una metodologia di sviluppo molto di moda negli ultimi anni) in ambiente Open Source? Quando alla base dell'XP c'e' il Pair Programming (due programmatori sullo stesso PC a programmare) ed una fitta comunicazione con iterazioni di design, coding, testing, integration di 2/3 settimane?

Il mondo ideale e' una meraviglia, la realta' dice che l'Open Source ha i suoi pregi e i suoi difetti, fra i suoi pregi non c'e' sicuramente l'essere piu' sicuro, anzi.

[fek]

Originariamente inviato da RaouL_BennetH Adesso, se invece io questo programma, lo distribuissi insieme ai sorgenti, prima o poi, qualcuno più smaliziato, che magari conosce bene visual basic, capirebbe al volo cosa fa un determinato modulo all'interno del sorgente, perchè all'interno di un linguaggio di programmazione qualsiasi, io posso "esprimermi" diversamente da qualcun altro, ma di sicuro non posso reinventarmi parole chiave, i cicli, il modo di operare sui socket etc..

Perciò ri-chiedo, questa, non è una "semplice" (occhio alle virgolette) esemplificazione di quello che avviene tra un software closed ed uno open?

Si', ma e' solo una parte della storia.
Io posso prendere il tuo sorgente, inserirci una backdoor mia, ricompilarlo e distribuirlo senza dire a nessuno che l'ho modificato. Chi lo installa non ha alcun modo automatico per sapere se sta installando la versione originale oppure quella con la mia backdoor, non c'e' alcun sistema di firma che garantisca all'utente che sta installando il programma che tu hai distribuito con le funzionalita' (e magari i bug) che tu hai programmato.
Quanto tempo passera' prima che qualcuno si accorga della backdoor che io ho inserito? Prima o poi qualcuno se ne accorgera' di sicuro leggendo i sorgenti modificati da me, o magari io sono particolarmente smaliziato e disonesto da distirbuire solo l'eseguibile, non importa, importa che ci sara' un periodo di tempo non uguale a zero durante il quale io posso fare danni sfruttando il fatto che tu hai distribuito i sorgenti del tuo prodotto.
Da notare che io faccio tutto a tua insaputa, non ti vengo a chiedere il permesso di inserire la mia modifica nei tuoi sorgenti.

Ci si puo' girare attorno quanto si vuole, ma questa' e' una grave vulnerabilita' intrinseca all'Open Source che non e' eliminabile in alcun modo. Se tu distribuisci i sorgenti, io posso modificarli e truffaldinamente ridistribuirli e ci sara' sempre il gonzo che li installa pensando che nessuno li abbia modificati.

[RaouL_BennetH]

Originariamente inviato da fek
Il motivo principale e' perche' non c'e' nulla di piu' complicato che leggere codice scritto da altri, tanto piu' se questo codice non e' pensato per essere leggibile (come purtroppo e' la maggior parte del codice). Trent'anni di Ingegneria del Software hanno insegnato che non e' possibile leggere un programma come fosse un libro seduti in poltrona

Immagina di leggere il codice di un metodo, che magari richiede precondizioni che sono garantite da una o piu' classi in un'altra parte del codice che tu non hai ancora visto, oppure implementa la soluzione ad un problema che tu non hai ancora visto e non e' stato documentato. Come fai a capire se quel codice e' giusto o no a prima vista? Ricordati che state parlando della possibilita' di prendere i sorgenti di un qualunque progetto OS, leggerli e in poco tempo trovare i bug.
Se fosse possibile, non servirebbe a nulla testare il codice oppure avere un reparto di QA, basterebbe leggere il codice per risolvere tutti i problemi. Che bel mondo sarebbe

Esistono pratiche ben documentate per "leggere il codice" per trovare bug, ma chiamiamole col loro nome: Code Inspection.
Una Code Inspection formale prevede che io che ho scritto il codice e tu che lo hai letto ci sediamo davanti ad un tavolo e discutiamo sui problemi che pensi di aver trovato. Come facciamo ad organizzare una Code Inspection formale se io vivo in UK e tu in Italia? Dai, ti ospito io se mi porti gli spaghetti

E qui arrivo a rispondere a chi ha obiettato che un team closed source puo' essere "distribuito" in varie sedi sparse per il mondo. Vorrei un esempio concreto, perche' io non ho mai sentito parlare di un team che lavora sullo stesso modulo con programmatori distribuiti. Ho sentito parlare di team che magari scrivono il motore 3d (un modulo) in Europa ed il resto del gioco (un altro modulo) in Canda, come ad esempio la Ubisoft, ma mi pare diverso da un sistema di sviluppo che presuppone che chiunque in qualunque parte del mondo abbia la possibilita' di cambiare qualunque pezzo di codice in qualunque modulo.

Nel caso del team distribuito di Ubisoft, il team di game programmer e' cliente del team che scrive il motore 3d.

A questo punto una piccola curiosita': chi mi puo' mostrare come fare magari eXtreme Programming (una metodologia di sviluppo molto di moda negli ultimi anni) in ambiente Open Source? Quando alla base dell'XP c'e' il Pair Programming (due programmatori sullo stesso PC a programmare) ed una fitta comunicazione con iterazioni di design, coding, testing, integration di 2/3 settimane?

Il mondo ideale e' una meraviglia, la realta' dice che l'Open Source ha i suoi pregi e i suoi difetti, fra i suoi pregi non c'e' sicuramente l'essere piu' sicuro, anzi.

Ok, ora il tuo punto di vista mi è molto più chiaro, thx.

[RaouL_BennetH]

Originariamente inviato da fek
Si', ma e' solo una parte della storia.
Io posso prendere il tuo sorgente, inserirci una backdoor mia, ricompilarlo e distribuirlo senza dire a nessuno che l'ho modificato. Chi lo installa non ha alcun modo automatico per sapere se sta installando la versione originale oppure quella con la mia backdoor, non c'e' alcun sistema di firma che garantisca all'utente che sta installando il programma che tu hai distribuito con le funzionalita' (e magari i bug) che tu hai programmato.
Quanto tempo passera' prima che qualcuno si accorga della backdoor che io ho inserito? Prima o poi qualcuno se ne accorgera' di sicuro leggendo i sorgenti modificati da me, o magari io sono particolarmente smaliziato e disonesto da distirbuire solo l'eseguibile, non importa, importa che ci sara' un periodo di tempo non uguale a zero durante il quale io posso fare danni sfruttando il fatto che tu hai distribuito i sorgenti del tuo prodotto.
Da notare che io faccio tutto a tua insaputa, non ti vengo a chiedere il permesso di inserire la mia modifica nei tuoi sorgenti.

Ci si puo' girare attorno quanto si vuole, ma questa' e' una grave vulnerabilita' intrinseca all'Open Source che non e' eliminabile in alcun modo. Se tu distribuisci i sorgenti, io posso modificarli e truffaldinamente ridistribuirli e ci sara' sempre il gonzo che li installa pensando che nessuno li abbia modificati.

Uhm, però tu parli di software non "firmato" o non certificato o non "signaturizzato", e può succedere la stessa identica cosa con un software closed distribuito senza le dovute precauzioni.

Ripeto, per me e tanti come me il tutto (open o closed) si basa sulla fiducia in entrambi i casi, mi piacerebbe però capire anche per gli esperti come ci si pone, a parte fek, in questo caso, del quale credo di aver compreso i legittimi dubbi.

[fek]

Originariamente inviato da RaouL_BennetH
Uhm, però tu parli di software non "firmato" o non certificato o non "signaturizzato", e può succedere la stessa identica cosa con un software closed distribuito senza le dovute precauzioni.

Sicuramente hai ragione.
Infatti ho visto in quest'ottica l'esternazione di un uomo Microsoft riguardo al fatto che Firefox non sia "firmato". L'ho interpretato piu' come un richiamo all'esigenza di firmare le installazioni, non come un richiamo a Firefox in particolare.

Credo che la differenza fra closed e open in questo caso sia nel fatto che non c'e' modo (almeno che io conosca) di "firmare" un'applicazione open source visto che posso sempre ricompilarmi i sorgenti per conto mio, mentre un eseguibile closed distribuito non firmato e' imperizia dello sviluppatore.

[Ikitt_Claw]

Originariamente inviato da fek
Credo che la differenza fra closed e open in questo caso sia nel fatto che non c'e' modo (almeno che io conosca) di "firmare" un'applicazione open source visto che posso sempre ricompilarmi i sorgenti per conto mio, mentre un eseguibile closed distribuito non firmato e' imperizia dello sviluppatore.

Da anni le distribuzioni firmano i binari che rilasciano. Se uno compila il sorgente (che e` sovente firmato dal team di sviluppo), affari suoi, si presuppone che abbia un buon motivo per farlo e la capacita` di cavarsi dai guai.

[edit]
Peraltro, ammettiamo che il sottoscritto, noto furbacchione, prenda i sorgenti di gaim (http://gaim.sf.net) [1], e modifichi i suddetti in modo da immettere una patch truffaldina che sniffi le password.

Poi come faccio a distribuire la mia copia taroccata?
- mando le patch al team. Forse me le accetta, forse no. In ogni caso le leggono, e a meno che non sia particolarmente creativo nell'offuscare il codice, la vedo dura che la backdoor passi. Tutto questo prescindendo da code review, code inspection, impossibilita` di etc. etc.
- mando le patch alle distribuzioni: come sopra, anzi peggio, perche` il feedback al team originale e` garantito che avvenga
- metto su un sito tipo http://better-gaim.sf.net, raccontando frottole per invogliare al donwload. Due sottopossibilita`:
-- metto a disposizione i sorgenti: ok, nulla da dire, posso fregare qualcuno ma e` comunque questione di tempo prima di ricadere nei casi suddetti. Comunque qualcuno dovrebbe spiegarmi dove sta la differenza tra questa contraffazione e quella di un comune software closed source
-- NON metto a disposizione i sorgenti: con la simpatica differenza che dopo poco tempo mi trovo i legali della FSF o di chi altro a casa, ricado nel caso precedente.

+++

[1] gaim e` il primo SW che mi e` venuto in mente. NON e` un buon esempio di ingegneria del software ne, probabilmente, di sviluppo
[/edit]

[Ikitt_Claw]

Originariamente inviato da fek
E qui arrivo a rispondere a chi ha obiettato che un team closed source puo' essere "distribuito" in varie sedi sparse per il mondo. Vorrei un esempio concreto, perche' io non ho mai sentito parlare di un team che lavora sullo stesso modulo con programmatori distribuiti. Ho sentito parlare di team che magari scrivono il motore 3d (un modulo) in Europa ed il resto del gioco (un altro modulo) in Canda, come ad esempio la Ubisoft, ma mi pare diverso da un sistema di sviluppo che presuppone che chiunque in qualunque parte del mondo abbia la possibilita' di cambiare qualunque pezzo di codice in qualunque modulo.

Non presuppone, permette. I difetti che vengono attiribuiti come intrinseci all'open source appaiono piuttosto come "worst pratice" diffuse che parti insostituibili del paradigma di sviluppo.

A questo punto una piccola curiosita': chi mi puo' mostrare come fare magari eXtreme Programming (una metodologia di sviluppo molto di moda negli ultimi anni) in ambiente Open Source? Quando alla base dell'XP c'e' il Pair Programming (due programmatori sullo stesso PC a programmare) ed una fitta comunicazione con iterazioni di design, coding, testing, integration di 2/3 settimane?

Esattamente come nel closed source: prendo due programmatori e li metto allo stesso PC. Prerequisito (esattamente come nel closed source): avere tutti e due i programmatori sotto lo stesso tetto.

Continuo a non ravvisare alcun elemento intrinseco alla metodologia open source che proibisca quanto detto, e l'applicazione delle tecniche che citi.

Il mondo ideale e' una meraviglia, la realta' dice che l'Open Source ha i suoi pregi e i suoi difetti, fra i suoi pregi non c'e' sicuramente l'essere piu' sicuro, anzi.

Ognuno ha diritto alla sua opinione...

[fek]

Originariamente inviato da Ikitt_Claw
Non presuppone, permette. I difetti che vengono attiribuiti come intrinseci all'open source appaiono piuttosto come "worst pratice" diffuse che parti insostituibili del paradigma di sviluppo.

Quindi rilasciare i sorgenti e una "worst practice" nell'Open Source? Non si finisce mai d'imparare.

Esattamente come nel closed source: prendo due programmatori e li metto allo stesso PC. Prerequisito (esattamente come nel closed source): avere tutti e due i programmatori sotto lo stesso tetto.

Se non fosse che fare Pair Programming signifca cambiare le coppie che programmano dopo ogni giorno di sviluppo.
Forse abbiamo trovato un modo per salvare Alitalia.

Originariamente inviato da Ikitt_Claw
Ognuno ha diritto alla sua opinione...

Non tutti pero' la sostengono con dati e fatti

[fek]

Originariamente inviato da Ikitt_Claw
Da anni le distribuzioni firmano i binari che rilasciano. Se uno compila il sorgente (che e` sovente firmato dal team di sviluppo), affari suoi, si presuppone che abbia un buon motivo per farlo e la capacita` di cavarsi dai guai.

Ho scaricato ieri Python (anch'io ogni tanto cedo al lato oscuro), sul sito pubblicano il CRC del file che viene distribuito, per controllare che il file sia originale avrei dovuto scaricarmi un altro programma, calcolare il CRC e confrontarli. Ti pare che lo abbia fatto? Sono troppo pigro, mi sono fidato e come me immagino tanti altri...
No, non e' colpa mia se sono pigro, l'autenticazione dovrebbe essere trasparente e automatica per essere user friendly e utile.

Chiunque avrebbe potuto prendere i sorgenti di Pyhton, inserire una backdoor e ridistribuirlo ad esempio...

Poi come faccio a distribuire la mia copia taroccata?

... via peer 2 peer.

Come qualcuno ha detto e' stato gia' fatto a dimostrazione di cio' che affermo.
In fondo siamo partiti dall'affermazione di qualcuno che gridava l'Open Source come intrinsecamente sicuro, e mi sono preoccupato solo di dimostrare che quest'affermazione e' falsa.

- mando le patch al team. Forse me le accetta, forse no. In ogni caso le leggono, e a meno che non sia particolarmente creativo nell'offuscare il codice, la vedo dura che la backdoor passi. Tutto questo prescindendo da code review, code inspection, impossibilita` di etc. etc.

Qui stiamo girando in tondo e ripetendo cose gia' dette: non basta leggere il sorgente come un libro per capire come funziona, non puoi prescindere da code review e code inspection. Se potessi, non esisterebbero i team di QA, non esisterebbe il testing, nessuno si preoccuperebbe di spendere milioni di dollari per migliorare la qualita' del software. Basterebbe dare una lettura ai sorgenti...

- metto su un sito tipo http://better-gaim.sf.net, raccontando frottole per invogliare al donwload. Due sottopossibilita`:
-- metto a disposizione i sorgenti: ok, nulla da dire, posso fregare qualcuno ma e` comunque questione di tempo prima di ricadere nei casi suddetti. Comunque qualcuno dovrebbe spiegarmi dove sta la differenza tra questa contraffazione e quella di un comune software closed source

E' questione di tempo, ovvio, ma del tempo e' sempre passato, tu vuoi basare un sistema di sicurezza sulla speranza che le frodi vengano riconosciute al piu' presto o sul limitare il piu' possibile che le frodi avvengano? Meglio curare che prevenire, vedo...

-- NON metto a disposizione i sorgenti: con la simpatica differenza che dopo poco tempo mi trovo i legali della FSF o di chi altro a casa, ricado nel caso precedente.

Hai mai usato un proxy per nascondere il tuo ip?

[Ikitt_Claw]

Originariamente inviato da fek
Quindi rilasciare i sorgenti e una "worst practice" nell'Open Source? Non si finisce mai d'imparare.

No. Lo e` l'accettare patch da chiunque senza adeguata verifica
(pregasi notare che non ho adetto che cio` avviene sempre. Ho detto che e` "worst pratice" quando accade, non che e` parte intrinseca della metodologia di sviluppo open source).

Se non fosse che fare Pair Programming signifca cambiare le coppie che programmano dopo ogni giorno di sviluppo.

Continuo a non vedere il nesso... Pazienza, sopravvivero`. (vedasi messaggio successivo)

Non tutti pero' la sostengono con dati e fatti

Beh, in effetti il fatto che tu possa fare un fork maligno di un software open source mi pare decisamente inoppugnabile. Come questo riesca a danneggiare l'orginale, e` ancora poco chiaro.

[Ikitt_Claw]

Originariamente inviato da fek
Ho scaricato ieri Python (anch'io ogni tanto cedo al lato oscuro), sul sito pubblicano il CRC del file che viene distribuito, per controllare che il file sia originale avrei dovuto scaricarmi un altro programma, calcolare il CRC e confrontarli. Ti pare che lo abbia fatto? Sono troppo pigro, mi sono fidato e come me immagino tanti altri...

Problemi tuoi/vostri, perdonami.

Stamattina il mio antivirus mi ha avvisato che "evilprogram.exe" e` affetto da win95.cih, ma io sapevo che era un programma importantissimo mandatomi da un mio collega fidato e l'ho eseguito normalmente...

No, non e' colpa mia se sono pigro, l'autenticazione dovrebbe essere trasparente e automatica per essere user friendly e utile.

Lo e` su piattaforma nativa. rpm ha il controllo delle signature integrato.

Chiunque avrebbe potuto prendere i sorgenti di Pyhton, inserire una backdoor e ridistribuirlo ad esempio...

Idem per qualsiasi altro software (es: mi tarocco l'installer).

Come qualcuno ha detto e' stato gia' fatto a dimostrazione di cio' che affermo.

L'ho detto io, me lo ricordo.
E ti ricordo che c'e` stata compromissione del server di mezzo.

In fondo siamo partiti dall'affermazione di qualcuno che gridava l'Open Source come intrinsecamente sicuro, e mi sono preoccupato solo di dimostrare che quest'affermazione e' falsa.

C'hai provato, e pur con tutta la mia buona volonta` non m'hai convinto.
Semplicemente perche` posso fare *tutto* quel che hai detto tu anche con software closed source (per tacere del solito discorso ricorrente del pair programming, quello e` un'altro discorso). Non mi pare proprio tu abbia usato nella tua dimostrazione proprieta` intrinseche dell'open source.

Qui stiamo girando in tondo e ripetendo cose gia' dette:

Pare anche a me.

non basta leggere il sorgente come un libro per capire come funziona,

Pero` basta leggerlo per capire che c'e` una backdoor nel ./configure (incidende di libpcap).
Ah, inciso: il mantainer di un progetto open source di solito ha una conoscienza un filino approfondita del modulo che mantiene... Magari perche` solitamente l'ha scritto lui...

E' questione di tempo, ovvio, ma del tempo e' sempre passato, tu vuoi basare un sistema di sicurezza sulla speranza che le frodi vengano riconosciute al piu' presto o sul limitare il piu' possibile che le frodi avvengano? Meglio curare che prevenire, vedo...

Pregasi notare che il software che e` stato contagiato NON era quello originale, bensi` un fork.

Con questo direi che concludo la mia partecipazione al thread. Continua pure, se vuoi, con la tua dimostrazione. Personalmente di elementi dubitativi ne ho fornito, credo, a sufficienza.

Ma, ovviamente, non avendoli forniti in coppia, bensi` da solo, presumo che abbiano un peso molto molto basso

[fek]

Originariamente inviato da Ikitt_Claw
Problemi tuoi/vostri, perdonami.

No. Problemi di chi mi fornisce software non user friendly.
Ma si sa che molti sostenitori dell'OS prima di fare sesso si tirano una martellata sulle balle altrimenti e' troppo facile

Semplicemente perche` posso fare *tutto* quel che hai detto tu anche con software closed source (per tacere del solito discorso ricorrente del pair programming, quello e` un'altro discorso). Non mi pare proprio tu abbia usato nella tua dimostrazione proprieta` intrinseche dell'open source.

Conoscendoti a questo punto penso tu faccia finta di non capire. Spiegami senza i sorgenti di PippoWord closed source come faccio a metterci dentro una back door.

Pero` basta leggerlo per capire che c'e` una backdoor nel ./configure (incidende di libpcap).
Ah, inciso: il mantainer di un progetto open source di solito ha una conoscienza un filino approfondita del modulo che mantiene... Magari perche` solitamente l'ha scritto lui...

Come ho detto prima, se per te basta leggere un sorgente per trovare difetti la discussione non puo' proseguire. Evidentemente sei un programmatore molto migliore di me perche' io spendo giorni a capire i sorgenti altrui e lo devo fare ogni giorno per lavoro.

[fek]

Originariamente inviato da Ikitt_Claw
No. Lo e` l'accettare patch da chiunque senza adeguata verifica
(pregasi notare che non ho adetto che cio` avviene sempre. Ho detto che e` "worst pratice" quando accade, non che e` parte intrinseca della metodologia di sviluppo open source).

E per l'ennesima volta ripeto che nessuno ha mai parlato di accettare patch senza controllarle.
Ho detto, e lo ripeto ancora, che mi basta avere i sorgenti per poter modificare il programma in maniera malignia. E poi ho diversi modi per distribuirlo fra i quali proporlo come patch.

Ma il punto nodale che ti ostini ad ignorare e' che avendo i sorgenti posso modificare il programma originale. E' questo il mio discorso, il resto sono i tuoi cavilli per portare il discorso lontano dal punto che per ovvi motivi non e' possibile controbattere.

[RaouL_BennetH]

Originariamente inviato da fek
Ma il punto nodale che ti ostini ad ignorare e' che avendo i sorgenti posso modificare il programma originale. E' questo il mio discorso, il resto sono i tuoi cavilli per portare il discorso lontano dal punto che per ovvi motivi non e' possibile controbattere.

Però, quello su cui dovresti riflettere un poco di più anche tu, è che appunto, modificando i sorgenti dell'originale, crei un fork maligno dell'originale, e distribuiresti appunto il fork maligno, non l'originale che è firmato e signaturizzato.

Il tuo fork maligno, potrei scaricarlo io come tanti altri che si "fidano" perchè non competenti, ma non potresti in alcun modo sostituirlo all'originale firmato e signaturizzato.

Poi, per quanto riguarda il "leggere i sorgenti", il discorso va fatto sopratutto su un unico file che è il ./configure. Li, ci devono essere solo determinate cose, una qualsiasi cosa in più, anche poco chiara oppure offuscata ad arte dal malintenzionato, salta subito all'occhio anche se leggendola non la si comprende.

Mi spiego:

So che nel ./configure di k3b ci devono essere solo e soltanto (per esempio) 5 direttive con scritto:

1) fai questo
2) fai questo pure
3) fai anche questo
4) copia qui e li
5) saluta l'utente e dagli il benvenuto

E questo posso tranquillamente confrontarlo sempre con il ./configure dell'originale.

Una qualsiasi cosa diversa, aggiunta o scritta in maniera differente, salta agli occhi in un istante.

Sono invece d'accordo sul fatto che, per chi è costretto a fidarsi, ci dovrebbe essere appunto una sorta di controllo molto più user friendly, ma questo lo credo sia per il mondo open che per quello closed.

[fek]

Originariamente inviato da RaouL_BennetH
Però, quello su cui dovresti riflettere un poco di più anche tu, è che appunto, modificando i sorgenti dell'originale, crei un fork maligno dell'originale, e distribuiresti appunto il fork maligno, non l'originale che è firmato e signaturizzato.

Il tuo fork maligno, potrei scaricarlo io come tanti altri che si "fidano" perchè non competenti, ma non potresti in alcun modo sostituirlo all'originale firmato e signaturizzato.

E' ovvio. Non ho mai affermato il contrario.

In sintesi:
- avere i sorgenti mi permette di creare una versione potenzialmente dannosa che posso provare a spacciare per originale
- non avere i sorgenti non me lo permette

[DjMix]

Originariamente inviato da fek
- non avere i sorgenti non me lo permette

Ti ricordi come funzionavano i virus che infettavano gli .exe e i .com?

[gcc-336]

fek, non capisco se stai facendo sul serio o se ci stai prendendo in giro, ma comunque il discorso che stai facendo è completamente inverosimile. a meno che uno non sia un idiota, il software si prende solo dal sito degli sviluppatori oppure da un mirror della propria distribuzione: nel primo caso ci si fida degli sviluppatori, e si presume che, per restare al tuo esempio, gli sviluppatori di python non mettano backdoors e siano in grado di riconoscere la malignità di un'eventuale patch di tezi. nel secondo caso ci si fida dei mantainer della propria distro, e si suppone che prendano il codice dagli sviluppatori, non mettano backdoors e non aggiungano patch di cui non capiscono il funzionamento. mi sai spiegare che idiota su questo pianeta direbbe "mi serve python! lo scarico da www.python.org o vado a cercarlo su cicciopasticcio.altervista.org... beh, cicciopasticcio è un nome simpatico, lo prendo da qui".

l'unico caso in cui quello che dici potrebbe accadere è il caso della compromissione del server, ma a prescindere dal fatto che non è una cosa che capita spesso e che comunque non ci vuole una vita ad accorgersene, il software closed source mica è al sicuro. basta modificare l'installer di nero burning rom, per citarne uno, e fargli installare anche il mio programmino-backdoor... e vallo a scoprire dopo.

[cdimauro]

Originariamente inviato da Nemios
Per evitare le contraffazioni esistono metodi tipo MD5SUM e firme digitali. Nessuno sta dicendo che l'open source sia perfetto, però al contrario del closed source se non ti fidi puoi controllare e purtroppo a questo mondo oramai ci si può fidare poco.

Sempre se sai cosa voglia dire MD5, firma digitale e soprattutto sai come utilizzarli.

Se creo una versione maligna di un software open source, posso non fregare te perché sei più "smaliziato", ma l'utente dummy sicuramente sì. Il nocciolo della questione sta tutto qui...