Dubbio sicurezza opensource

[cdimauro]

Originariamente inviato da nico159

E quando mai avrei detto che è una tecnologia? :=)

"L'open source nasce con lo scopo di creare una tecnologia migliore e far sì che tutti ne possano partecipare."

Certo, ma le cose cambiano se sono 100 che lo fanno a fin di bene contro 10 che lo fanno con cattive intenzioni. 100 persone hanno più possibilità di 10 persone.

Indubbiamente, ma stiamo parlando astrattamente di possibilità. Tanto per fare un esempio, un solo "cattivone" potrebbe trovare e sfruttare una falla di sicurezza sfuggita agli occhi di 100 "angioletti".

Anche con il modello di sviluppo open source, si testano i cambiamenti apportati :-) Esempio. FireFox ha una vulnerabilità documentata. La patch è già pronta, chi vuole può già applicarla, ma la nuova sottoversione verrà rilasciata solo dopo 5 giorni di testing.
Inoltre, è troppo generico. Sfido io la Microsoft a volerci fare del testing di mesi, quando viene scoperta una vulnerabilità di grado critico in un suo prodotto.

L'ho già scritto: meglio un workaround in attesa di una patch sviluppata con tutti i crismi.

Non ha proprio senso rilasciare una patch subito: c'è il forte rischio di creare più problemi di quanti ne dovrebbe risolvere.

E' come se per curarti una malattia ti dessi subito un vaccino che potrebbe, però, svilupparti un cancro (perché non è stato testato come si deve).

Ovvio che non mi riferisco ai sorgenti, Come si potrebbe mai? Pagagonare Firefox a Opera basandosi sui sorgenti? Quali sorgenti?

Non parlavo in generale: quando parlavo di "opinabile", mi riferivo al fatto che tante volte mi è capitato di avere fra le mani sorgenti di scarsa qualità.

I confronti si possono fare soltanto se si lavora in un'azienda che produce software closed, oppure a causa della "fuoriscita" degli stessi.
Ad esempio, ho avuto la possibilità di analizzare alcuni sorgenti di Windows, e debbo dire che la qualità del codice prodotto è notevole. Idem per quanto riguarda lo stage / tesi di laurea che ho fatto all'STMicroelectronics.

Scusa :°) Ma c'è sempre qualcuno che coordina ogni progetto. Cosa credi? Un responsabile di progetto c'è sempre.

Non sempre: spesso c'è soltanto qualcuno che tira avanti la baracca.
Organizzazioni gerarchiche ne esistono poche, e quando ci sono la libertà di apportare contributi non c'è. Anche per questo esiste il forking.

E uno sguardo a progetti come Apache httpd, gcc e NetBSD, giusto per fare due nomi, no?

Tu l'hai mai data un'occhiata a GCC (e GNU Pascal, che da esso dipendeva fortemente)? Fallo.

[cdimauro]

Originariamente inviato da r.

Un progetto open source è più insicuro perchè tutti hanno la possibilità di guardare il codice?

La risposta più corretta è no (il che non vuol dire che sia vero il contrario).

A parte quanto scritto già da fek e col quale mi trovo d'accordo, c'è da considerare anche il contesto. Io non renderei mai pubblico lo schema dell'allarme di casa mia, ad esempio.

[k0nt3]

Originariamente inviato da fek

Ti ripeto di si', sono entrambi linguaggi di modellazione del design formali, uno basato su diagrammi (ad esempio i diagrammi di classe di UML), l'altro sulla descrizione mediante una grammatica formale e piu' vicino al linguaggio naturale delle precondizioni, postcodinzioni e invarianze (JML). Una specie di Design By Contract alla Eiffel, ma decisamente meno elegante.

Sono due strumenti diversi che perseguono gli stessi scopi (e che non adoro).

ti sbagli! servono a due cose diverse! altrimenti xkè li abbiamo usati tutti e due nello stesso progetto? uno serve in una fase della progettazione e l'altro in un'altra! UML è un livello leggermente + alto di JML! e comunque chiunque li ha usati sa ke servono a cose diverse! JML è un linguaggio per dare le specifiche e non è affatto poco elegante come sostieni!

[k0nt3]

Originariamente inviato da fek

Sono perfettamente in topic invece, visto che stai insultando chiunque non ti dia ragione, mi limito a riportarti in riga

io insultato cosa? rileggi tutto a vedere ki insulta ki! incredibile! hai gia perso la memoria?

[cdimauro]

Originariamente inviato da k0nt3

l'unica cosa certa è ke il modello closed source non significa più sicurezza

Ma nemmeno il contrario: vedi messaggi precedenti.

[k0nt3]

Originariamente inviato da jappilas

pensa ke a me all' esame di Ing SW hanno fatto studiare un frammento di codice di un paio di centinaia di linee, con complessità ciclometrica intorno a 35 (se non ricordo male), determinando domini di correttezza per i casi di percorrenza di: tutte le condizioni, tutte le istruzioni, condizioni AND istruzioni... il secondo esercizio consisteva nell' analisi di un' applicazione che gestisse manipolazione da client esterni su strutture dati gerarchiche e aggregate, e modellazione tramite i DP necessari (se non ricordo male ci andava un Composite, un Observer, il Proxy e una Factory... il diagramma mi prese 3 fogli A4... )
nessuno ti tormenta... faccio solo un confrontino tra un esame di ingsoft vecchio e nuovo ordinamento

guarda ke io non ho detto ke all'esame dovevo produrre la javadoc! ho detto ke la javadoc ke ho prodotto in laboratorio (non ma solo ma in team) è stata valutata! non entriamo nel merito ma non penso proprio ke ora gli esami sono + facili! questa è bella! allora xkè quasi nessuno si riesce a laureare a luglio? si ho dovuto ankio determinare i domini di correttezza non ti preoccupare! tranquillo ke il testing strutturale l'abbiamo fatto!

Originariamente inviato da jappilas

commentare non è inutile a priori... spesso però potrebbe tranquillamete essere sostituito da una naming convention più "umana"
hai la fortuna che un simbolo in C non ha praticamente vincoli sul naming... perchè non sfruttarlo per far assomigliare un programma a un "discorso" in inglese?

almeno tu ragioni! sono contento ke ci possa essere dialogo! secondo me l'idea di far assomigliare il codice a linguaggio naturale è irrealizzabile! ci hanno provato con sql.. e se non ci sono riusciti i ricercatori di IBM (i migliori di tutto il mondo) ci sarà un motivo! comunque commentare il codice non basta! bisogna commentarlo bene! un codice commentato male è di scarsa qualità, niente da dire.

[k0nt3]

Originariamente inviato da cdimauro

Ma nemmeno il contrario: vedi messaggi precedenti.

non ho mai detto il contrario! la mia riflessione si basa sulla seguente cosa:
xkè devo mettere in piedi una struttura complessa, rigida e pesante quando con una struttura semplice, elastica e leggera ottengo software ke con la stessa probabilità contiene un bug?

[Gica78R]

A proposito di sicurezza nel modello di distribuzione closed-source ( ), di patch e di velocita' di rilascio delle stesse, tocchera' attendere almeno altri 5 giorni per quella recente (e gravissima) vulnerabilita' di Windows relativa al formato WMF:

http://attivissimo.blogspot.com/2006...enta-come.html


A quanto pare la situazione e' molto molto grave!

[k0nt3]

comunque sia io con "documentazione" non intendevo solo i commenti! e tu fek hai detto ke l'intera documentazione è inutile! allora mi kiedo quanti di voi sono riusciti a programmare in java senza avere mai aperto la javadoc! se io costruisco una classe ke fa qualcosa come un modulo a se stante, è indice di qualità fornire una documentazione sufficiente per capire come funziona la classe nei minimi dettagli! inoltre spesso e volentieri il nome di un metodo è autoesplicativo, ma non privo di ambiguità!
e poi quanti di voi quando vogliono sapere cosa fa una funzione di java leggono il suo codice?

[k0nt3]

open source non va confuso con freeware... rilasciare il sorgente non vuol dire non essere pagato! mi sembra ke questo non sia molto kiaro a voi programmatori closed! allo stesso modo closed source non vuol dire a pagamento (sapevate ke c'è una versione di zone alarm gratis? minimale ovvio! ma x uso domenstico + ke sufficiente)! se poi la maggiorparte del software open viene retribuito mediante offerte opzionali è un altro conto! secondo me non è affatto male come sistema!

[Zorcan]

Originariamente inviato da fek

Piuttosto che sintetizzare ulteriormente, invece, ti prego di usare piu' parole perche' stai facendo molta confusione. [cut] Il poter guardare dentro il codice non e' una liberta' inalienabile dell'uomo.

Francamente non so che dirti, a questo punto temo che qualunque cosa dica verrà rispedita al mittente con i soliti "non capisco", "non è pertinente" o frasi di rito simili (e francamente un po' infantili). In realtà, si capisce tutto e gli esempi sono pertinenti, almeno alle orecchie di chi vuole ascoltare. I sofismi per ingarbugliare il discorso ("puoi vedere il codice solo se te lo permetto"... e grazie al piffero, verrebbe da aggiungere) sono un po' ridicoli, soprattutto quando il tema è alquanto semplice. In questo caso preciso, dubito che sia possibile un punto di vista comune: io ritengo l'opensource una risorsa, altri lo ritengono una delle tante opzioni. Ma è un'interpretazione strumentale per poterne sminuire il valore: in realtà e inconfutabilmente, tra un programma trasparente ed uno che non posso sapere come sia fatto e cosa contenga, c'è una disparità di valore e affidabilità alquanto palese, specie in tempi come quelli attuali in cui il software, anche grazie a Microsoft e ai suoi investimenti sulla "sicurezza", va sempre più perdendo lo spirito originario per trasformarsi invece in una castrante e sofisticatissima scatola nera il cui scopo non ci è del tutto chiaro.

[fek]

Originariamente inviato da VICIUS

Sistema la build machine invece di perdere tempo qui nel forum a parlare del piu e del meno

ciao

Ma se la sto prendendo a calci da tre giorni quella maledetta. Va e viene

[k0nt3]

Originariamente inviato da Zorcan

Francamente non so che dirti, a questo punto temo che qualunque cosa dica verrà rispedita al mittente con i soliti "non capisco", "non è pertinente" o frasi di rito simili (e francamente un po' infantili).

sono daccordo! mi sembra ke fek critica a priori qualunque cosa venga detta da me e da te! questo non fa altro ke confondere tutte le persone ke leggono questa discussione e inquina il topic con cose non pertinenti ! cerchiamo di arrivare a un dialogo invece di dire solo "non sono daccordo punto e basta", "non è vero punto e basta" o "io so molte cose più di te punto e basta"! ma chi crede di essere fek? l'inventore dell'informatica? xkè io dovrei accettare la SUA personale definizione di "open source"? se non gli va bene quella di wikipedia può discuterne con ki l'ha scritta ke magari la correggono!

[fek]

Originariamente inviato da pinok

@fek e jappilas
Vi offendete se vi dico che sono punti di vista ??
Non potete partire dal presupposto che un codice è scritto in uno stile che per consuetudine comprendete.
Io che non arrivo dalla computer grafica, devo potere comprendere cosa fa un singolo pezzo di codice senza dovermi studiare i pezzi prima o i pezzi dopo.
Poi semmai vado a vederli.
Può darsi che per voi le Capabilities siano una cosa, ma che arrivi un programmatore che con Capabilities ne intende un altra. Un minimo cenno evita menate.

Non sono punti di vista invece. Qui stai facendo un errore di fondo: stai confondendo il fatto che a te non e' chiaro il dominio del problema con il fatto che pensi che da questo derivi che il codice stesso non sia chiaro.

Sono due concetti separati: se tu non sai che cosa sia l'HDR (e non sei tenuto a saperlo) significa che non conosci il dominio del problema del quale quel codice e' la soluzione. Non significa che la soluzione stessa non sia chiara, perche' lo e': abilita l'HDR, controlla le capabilities, crea i render target, crea i filtri. Chiunque guardando quel codice capisce questo, perche' e' chiaro dal codice stesso. Spesso quando scrivo codice chiamo un non programmatore e gli chiedo di leggere quello che sto scrivendo; ovviamente un non programmatore non ha dimestichezza con il dominio del problema e neppure con il formalismo, ma proprio per questo voglio vedere se il mio codice riesce a comunicare l'idea della soluzione. Se non ci riesce, lo riscrivo.

Il dominio del problema non dev'essere invece spiegato in codice, viene documentato dai requisiti: se non sai che cosa sia l'HDR e ti interessa saperlo, leggi il documento di requisiti dove e' spiegato, sarebbe oltremodo sbagliato ogni volta che cito l'HDR in codice dover spiegare in un commento che cos'e'

Nei "controcommenti" mi hai detto cosa fanno certe variabili, ma questo si capiva. Infatti ho detto che il codice era comprensibile.

Infatti non ha bisogno di commenti

Ma non mi hai detto il perché lo fanno li, piuttosto che non altrove, o perché in un modo piuttosto che in un altro.
E' questo che giustifica la logica del codice: non deve fare qualcosa, ma arrivare a qualcosa. Ti potrei sbattere lì un loop che non fa niente e dirti: "E' chiaro, sta contando da 1 a 1000". Ok, grazie. Ma perché? Se non c'è un perchè, probabilmente è un refuso.

Il qualcosa a cui deve arrivare (si chiama dominio del problema) e' documentato dai requisiti, NON deve essere documentato dal codice. Per altro anche in questo caso non sono spesso necessari i commenti, perche' esistono i test (acceptance test) scritti in linguaggio formale che documentano i requisiti, e poi testano se il codice li incontra.

Il perche' poi, ad esempio, controllo le caps e' il poter creare i render target: e' scritto li', nel codice, e' inutile ripeterlo in un commento.

Per quel che ne so, tra 2 mesi guardano quel pezzo di codice che hai postato, potrebbe avere avuto senso inizializzare la variabile a false. Perchè non l'ho fatto? Vuoi mica che mi vada a risfogliare 2000 pagine di specifiche, sempre che esistano ?

No, basta che guarda il codice, il codice ti dice esattamente perche' ho inizializzato quella variabile a false: per disabilitare l'HDR. E' scritto li', nel codice.

[fek]

Originariamente inviato da k0nt3

ti sbagli! servono a due cose diverse! altrimenti xkè li abbiamo usati tutti e due nello stesso progetto?

Perche' sono due formalismi a due livelli di astrazione differenti, te l'ho scritto. Ma ti devo proprio spiegare tutto. Torna a studiare dai

[fek]

Originariamente inviato da k0nt3

se io costruisco una classe ke fa qualcosa come un modulo a se stante, è indice di qualità fornire una documentazione sufficiente per capire come funziona la classe nei minimi dettagli! inoltre spesso e volentieri il nome di un metodo è autoesplicativo, ma non privo di ambiguità!
e poi quanti di voi quando vogliono sapere cosa fa una funzione di java leggono il suo codice?

No, se sei un principiante scrivi la documentazione, se sei un buon programmatore scrivi gli unit test che documentano in codice le post condizioni e l'interfaccia della classe, e allo stesso tempo la testano.

Quando ho un metodo di una classe e voglio sapere come usarlo leggo i test relativi.

[cdimauro]

Originariamente inviato da fek

No, l'indentazione e' importante.

E a volte indispensabile.

[fek]

Originariamente inviato da k0nt3

sono daccordo! mi sembra ke fek critica a priori qualunque cosa venga detta da me e da te! questo non fa altro ke confondere tutte le persone ke leggono questa discussione e inquina il topic con cose non pertinenti ! cerchiamo di arrivare a un dialogo invece di dire solo "non sono daccordo punto e basta", "non è vero punto e basta" o "io so molte cose più di te punto e basta"! ma chi crede di essere fek? l'inventore dell'informatica? xkè io dovrei accettare la SUA personale definizione di "open source"? se non gli va bene quella di wikipedia può discuterne con ki l'ha scritta ke magari la correggono!

La stai mettendo sul personale perche' hai finiti i pochi argomenti a disposizione?

Non e' la mia personale definizione di open source, e' la definizione corretta di open source, c'e' una differenza sostanziale che ti sfugge.

E mi sembra di averti spiegato per filo e per segno perche' commentare il codice e' da principianti, la differenza fra modello di distribuzione e metodologia di sviluppo, l'inadeguatezza della documentazione classica. Non e' insultando l'interlocutore che ha una marea di esperienza in piu di te che arrivi al dialogo.

[cdimauro]

Originariamente inviato da k0nt3

skerzi vero? abbiamo fatto tutte queste cose in ingSW1! ci soffermeremo meglio nel testing in ingSW2! non mi prendere x ignorante ti prego!! il refactoring da solo non basta e i commenti sono vitali a meno ke il mio professore è deficente! ti prego contattalo xkè qui riskiamo ke 2milioni di ingegnieri escono ignoranti dall'università!

No, rischi di trovarti con tante nozioni e strumenti (non dico tutti, sia chiaro) che sul campo (leggi: lavoro) non ti servono.

[k0nt3]

Originariamente inviato da fek

Perche' sono due formalismi a due livelli di astrazione differenti, te l'ho scritto. Ma ti devo proprio spiegare tutto. Torna a studiare dai

xkè rispondi alle domande ke non ti faccio?
tu hai scritto: "Sono due strumenti diversi che perseguono gli stessi scopi" e penso ke questo non puoi contestarlo! adesso scrivi ke sono due livelli di astrazione diversi! come sappiamo ogni livello di astrazione ha uno scopo diverso... no? altrimenti ne facciamo uno solo ke tanto gli altri sono ripetitivi xkè mirano a raggiungere lo stesso scopo!