Newsgroup: it.lavoro.informatica
Titolo: The Internet Will Never Be Secure, Ever (Because it's written in C.)

http://gilesbowkett.blogspot.it/2014/04/the-internet-will-never-be-secure-ever.html
 
 
 
Prendo popcorn.
 
  ngw
 

 Prendo popcorn.
 
Io ho la birra, ne vuoi una?
 
m.


Popcorn e birra?
 
bah!

 Prendo popcorn.
 
in attesa dei puri & duri del c. ma credo ci sia ben poco da confutare.
 
 


   Ecco un nudo, duro e puro: Theo de Raadt
 
http://article.gmane.org/gmane.os.openbsd.misc/211963
 
 
[...]
 
 > OpenSSL is not developed by a responsible team.
 
 
   Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 
http://article.gmane.org/gmane.os.openbsd.misc/211963
 
 
Francamente, in questo caso, trovo pochi motivi per dargli torto, mi sfugge qualcosa?
 
Ciao
  Francesco

 Francamente, in questo caso, trovo pochi motivi per dargli torto, mi sfugge qualcosa?
 
No, assolutamente. Solo che a me viene una riflessione. Quasi tutto quel che è di livello superiore, e che implementa i principi descritti nell'articolo, è scritto più o meno in C, compreso il Python che sto usando adesso. Ergo... ;)
 
-- 
Ciao!
Luca

 No, assolutamente. Solo che a me viene una riflessione. Quasi tutto quel che è di livello superiore, e che implementa i principi descritti nell'articolo, è scritto più o meno in C, compreso il Python che sto usando adesso. Ergo... ;)
 
Bisogna vedere se c'è un motivo stringente, oppure se è solo una relativa pigrizia di non riscrivere tutto daccapo (comprese librerie di sistema) in un diverso linguaggio, per es. di quelli che usano una VM che garantisce più elevati livelli di sicurezza.
Certo se poi il baco è logico c'è poco da fare, passerà attraverso qualunque VM od altro meccanismo di controllo.

 oppure se è solo una relativa pigrizia di non riscrivere tutto daccapo (comprese librerie di sistema) in un diverso linguaggio, per es. di quelli che usano una VM che garantisce più elevati livelli di sicurezza.
 
OK, ma la VM in qualche linguaggio deve essere scritta, e si torna a casa. Ti faccio un esempio, così ci si capisce. Python. Per molti aspetti non mi piace, ma gli va riconosciuto che è solido, consistente e tutto sommato veloce da usare. Però poi l'interprete è scritto in C, e se vuoi creare nuove librerie che affrontano magari qualcosa non previsto dalla Standard Library, puoi farlo in C.
 
C ha tutti i difetti descritti nell'articolo (che io amavo, è stato il periodo in cui mi sono divertito di più e in cui ho fatto le peggio porcherie); però, alla fine, se gratti, scopri che son gli stessi difetti di TUTTI i linguaggi di livello basso, in cui davanti sostanzialmente hai la macchina.
 
-- 
Ciao!
Luca
 
 

 C ha tutti i difetti descritti nell'articolo (che io amavo, è stato il periodo in cui mi sono divertito di più e in cui ho fatto le peggio porcherie); però, alla fine, se gratti, scopri che son gli stessi difetti di TUTTI i linguaggi di livello basso, in cui davanti sostanzialmente hai la macchina.
 
si ma ti dimentichi che quell'articolo parla delle vulnerabilità di 
internet, quindi non è che sia proprio indifferente quanto gratti.

 OK, ma la VM in qualche linguaggio deve essere scritta, e si torna a casa. Ti faccio un esempio, così ci si capisce. Python. Per molti aspetti non mi piace, ma gli va riconosciuto che è solido, consistente e tutto sommato veloce da usare. Però poi l'interprete è scritto in C, e se vuoi creare nuove librerie che affrontano magari qualcosa non previsto dalla Standard Library, puoi farlo in C.
 
Un conto è scrivere "solo" (si fa per dire) la VM in C, o magari assembler. Un altro conto è scrivere tutto in C. Poche migliaia di righe contro milioni o miliardi, con relativo aumento della probabilità che ci sia qualche bug.
Non conosco Python, ma probabilmente, come per molti altri linguaggi, sei assolutamente costretto a ricorrere a librerie esterne in C od altro per casi molto particolari. Oppure per la pigrizia (si fa ancora per dire) di non riscrivere cose molto complesse. Cosa che invece è stata fatta ampiamente per Java, magari in nome della ricerca della famigerata portabilità assoluta.
(mi sa però che è l'unico caso) 
 
 

 tu esponi dei programmi java non la virtual machine. 
 
Vero, un altro punto a favore.
 
 

 
http://gilesbowkett.blogspot.it/2014/04/the-internet-will-never-be-secure-ever.html
 
 
IMHO c'e' poco da commentare, specialmente se inizia con frasi tipo questa:
 
"My opinion, then and now, is that C and other languages without memory checks are unsuitable for writing secure code"
 
Provo a spiegare quello che penso con un esempio, e mi adeguo al linguaggio scurrile dell'articolo. Se un automobilista e' un caxxone alla guida, lo sara' sia se guida una ferrari che se guida una panda. Con la differenza che i danni che puo' fare guidando una ferrari sono di gran lunga superiori a quelli che puo' fare guidando una panda. Ora, se un guidatore caxxone ha fatto dei danni, proprio perche' e' un caxxone non cerchera' di cambiare il suo stile di guida, ma continuera' a far danni e se la prendera' con la ferrari, con la panda, con le cavallette, coi pedoni, coi vigili, coi ciclisti, col governo ladro, etc.
 
IMVHO.
 

 No, assolutamente.Solo che a me viene una riflessione.
 >Quasi tutto quel che č di livello superiore, e che implementa i 
principi descritti nell'articolo,
 >č scritto piů o meno in C, compreso il Python che sto usando adesso. 
Ergo... ;)
 
 
Per gli altri linguaggi non so, ma per python gia' qualche anno
fa si sentiva parlare di questo:
 
http://pypy.org/
 
 
Non mi chiedere se e' ancora seguito/aggiornato e quale sia lo stato 
dell'arte attuale (non esercito piu' e quindi seguo anche molto meno)
 
Per quanto riguarda la notizia dell'oggetto in se, non ho mai capito
perche' chi scrive in C non puo' scrivere codice corretto mentre chi 
scrive ad esempio il garbage collector di java deve scrivere per forza
tutto corretto (indipendentemente se lo scriva in C o in altri 
linguaggi).  E perche' ad esempio chi ha scritto pypy dovrebbe averlo 
scritto "bene" necessariamente, senza bug che inficino la sicurezza.
 
Ma la suddetta incomprensione e' destinata a restare tale in eterno,
per quanto mi riguarsa, visto che comunque sono problemi che non mi
riguardano piu'.
 
Ciao,
Marco.
 
 
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

 coi pedoni, coi vigili, coi ciclisti, col governo ladro, etc.
 
a parte che l'esempio "ferrari vs. panda" non rende affatto con la 
situazione "without memory checks vs. with memory checks", in ogni modo 
non confuta la tesi a cui arrivano; è oggettivo, dal punto di vista dei 
pedoni e dei ciclisti, fintanto che gran parte delle auto in circolazione 
sono ferrari le strade non saranno sicure. che poi questo dipenda dai 
guidatori cazzoni se ne può parlare, ma è oggettivo che le strade mostrano 
insidie contro le quali le ferrari non hanno dispositivi di sicurezza 
adeguati, per cui anche i guidatori bravi possono commettere errori 
fatali. 

 in ogni modo non confuta la tesi a cui arrivano; 
 
sinceramente ho difficolta' anche a capire a quale tesi voglia arrivare l'autore dell'articolo, e soprattutto se ha una tesi (razionale) che vuole sostenere. Perche' i ragionamenti del tipo "se mio nonno aveva tre palle era un flipper" non li riesco a seguire.
 

 Nel caso specifico il problema e' che c'e' sempre l'omino dei computer a scrivere il codice, e che un linguaggio di programmazione *dovrebbe* esser scelto a seconda del problema che si sta andando a risolvere e da tanti altri parametri del caso, non per partito preso al bar dello sport.
 
Ed allora, considerato che siamo nel 2014, e considerato che tuttora si continuano a scrivere tonnellate di codice in C, anche e soprattutto per software molto critici, se ne dovrebbe concludere che negli ultimi 25-30 anni non è cambiato nulla e non è stato inventato niente di meglio. Il che non mi sembra convincente.

 internet, quindi non è che sia proprio indifferente quanto gratti.
 
Beh, però un'affermazione del genere:
 
"My opinion, then and now, is that C and other languages without memory checks are unsuitable for writing secure code..."
 
E' talmente perentoria che io l'ho percepita non limitata a Internet...
 
-- 
Ciao!
Luca

 l'autore dell'articolo, 
 
direi il titolo (e sottotitolo) parlano chiaro.


si ma se l'articolo titola "the internet will never be secure, ever" non 
vedo dubbi su quale sia l'argomento, senza contare i riferimenti con 
l'attualità. isolare una frase dal contesto e attribuirgli un significato 
diverso è un esercizio abbastanza uggioso...

 anche e soprattutto per software molto critici,
 
I software "molto critici" in genere sono quelli per sistemi real-time,
tipo controllo di treni/aerei, ecc. dove piu' che la securuty contano le 
performance.
 
 
se ne dovrebbe concludere che negli ultimi 25-30 anni non è cambiato 
nulla e non è stato inventato niente di meglio.
 
Il che non mi sembra convincente.
 
Il problema e' che a me risultava che sono almeno 10 anni che C/C++ 
vengono evitati come la peste (tranne appunto per software "molto 
critici" come sistemi real-time,  embedded  e simili).



Infatti non lo e', semplicemente internet ne e' la manifestazione piu' evidente.
E se davanti ad una falla del livello di heartbleed per un software stratestato, in produzione in mezzo universo conosciuto, nel core di qualunque distro linux, BSD (OpenBSD incluso se non erro) e su qualunque server dell'universo, sviluppata certamente non da coglioni, il meglio che si riesce a tirar fuori e' mettere in discussione l'autore del software... beh, speriamo sempre nel proverbiale asteroide :D
 
  ngw


Classico argomento ad hominem dove per giustificare una tecnologia che di fatto non gestisce la memoria e di fatto ha continui problemi proprio nella gestione della memoria (disastro heartbleed, il piu' recente di una serie assolutamente infinita), si da la colpa agli sviluppatori che questo bug l'hanno introdotto.
Been there done that.
 
  ngw

 che questo bug l'hanno introdotto.
 
internet ha circa 2,405,518,376 utenti (
http://www.internetworldstats.com/stats.htm
), un numero di protocolli che non sto neanche a contare, una diversita' di programmatori, lingue, metodologie, esigenze,  difficili anche solo da immaginare. Mi sembra giusto un tantinello "shortsighted" dire che e' colpa di un linguaggio anzicche' un altro se non e' sicura. Questo indipendentemente dai pregi/difetti che un linguaggio puo' avere, e che IMHO vanno comunque valutati caso per caso, eisgnenza per esigenza, progetto per progetto e... <joke><tease>sviluppatore per sviluppatore</tease></joke>

 Classico argomento ad hominem dove per giustificare una tecnologia che di fatto non gestisce la memoria e di fatto ha continui problemi proprio nella gestione della memoria (disastro heartbleed, il piu' recente di una serie assolutamente infinita), si da la colpa agli sviluppatori che questo bug l'hanno introdotto.
 
Beh, non è che puoi dare la colpa al destino cinico e baro o allo strumento. Anche perché, se sei uno sviluppatore ben preparato, dopo un po' i limiti dello strumento li conosci bene.
Faccio riferimento al mio passato da C-ista, anche se son passati eoni e sviluppavo sotto DOS. Io SAPEVO PERFETTAMENTE quali erano i problemi che potevo incontrare, proprio nella gestione della memoria (noto peraltro che non si parla della frammentazione, a mia memoria una delle rogne più grosse); di conseguenza, sapevo che, se veniva fuori un problema, era colpa mia e mia responsabilità scovarla.
Il problema IMHO è che i tempi son cambiati, che gli sviluppatori mediamente son formati meno (penso all'intera platea, non alle eccellenze) e che la velocità di sviluppo richiesta oggi è molto più elevata di quella di un tempo (e in effetti questi ultimi due punti lavorano insieme). 
Nella fattispecie, poi,  mi lascia perplesso che di un buco del genere, in un software strausato come giustamente dicevi, non si sia accorto nessuno finora.
 
-- 
Ciao!
Luca


Io sono come sempre sono combattuto tra lo scoprire quanto e' profonda la tana del bianconiglio in questa perenne bidonville dell'informatica che e' ILI o semplicemente farmi una ghignata per la comicita' degli argomenti, che francamente farebbero ridere un diplomando dell'ITIS (o piangere).
Schneier su Heartbleed parla di "catastrofe" ("Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.), il software e' OpenSSL, ha circa 200 anni, e' in produzione letteralmente ovunque e piu' che testato, e' in C. Il bug "allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content.".
Lo stesso bug sarebbe potuto accadere con altre tecnologie che la memoria la gesiscono? Ovviamente no. Questo e' quanto, non c'e' molto altro da dire, salvo le solite cretinate che con l'informatica hanno poco da spartire e starebbero meglio in un bar milanese la sera del derby, magari arrivando a sostenere come una VM e un GC non impediscano bug di tutt'altra natura che con una VM e una GC c'entrano un paio di cazzi, o di come una VM non entrera' mai nella memoria dell'orologio Casio degli anni '80 ereditato dal nonnino, e varie eventuali, che al peggio non c'e' mai fine.
 
Adavadai,
  ngw
 


E' perche' OpenSSL e' Opensource, ed erano tutti a Yoga. Vorrai mica che siano stanchi a lavoro, porco di un cazzo.
Sti coglioni di OpenSSL mediamente formati meno del Menegotto.
(si, e' il caso di buttarla sul ridere, davvero)
 
  ngw

presso cui ho fatto colloqui.
 
Certo che l'informatica e' grande. Per me e' il contrario, lavoro solo in 
C(++) da ormai piu' di 15 anni e molto raramente ho visto o dovuto 
interfacciarmi con altro. 
 

 performance.
 
Direi proprio che non è esattamente così...
 


Cioe' vorresti fare sistemi real time in linguaggi che inseriscono 
overhead per controlli sulla security sforando le dead-line ?
 
In ogni caso la parte interessante dal mio punto di vista era quella che 
hai tagliato, ovvero: quali aziende continuano a sviluppare condice
in C/C++ a tonnellate ?


 Beh, non è che puoi dare la colpa al destino cinico e baro o allo strumento. Anche perché, se sei uno sviluppatore ben preparato, dopo un po' i limiti dello strumento li conosci bene.
 
Se nel caso Openssl si tratta effettivamente del "solito" overflow di memoria, bisogna comunque dire che  ci hanno fatto una figura di me..., ehm, "un pò opaca" (:-) tutti quanti: sviluppatori; metodologia opensource; sistemi (procedure di qualità e test, software specifici, ecc.) di prevenzione degli arcinoti bug di memoria in C.
Il tutto è piuttosto stupefacente, e viene veramente da chiedersi se il bug in realtà fosse ben noto da tempo, e sia stato rivelato per motivi precisi. 
 

 in C/C++ a tonnellate ?
 
Magari tutte quelle che sviluppano parti di sistemi operativi, come drivers? O versioni speciali di Linux/Unix? O magari DBMS?
Ma forse ti riferivi a software gestionale, in quel caso ti dò ragione, si usa altro.

 precisi.
 
ecco il dietrologo di brozzi, diretto discendente dello strolago di brozzi 
che riconosceva i pruni al tatto e la merda al puzzo :P

 content.".
 
E la colpa e' il C.

Il giorno domenica 13 aprile 2014 23:08:06 UTC+2, rootkit ha scritto:
 
...
 
Ok, ottimo, allora questo frittatone di me.. è passato sotto il naso di tutti, te compreso :-))   


Stai sul pezzo:
 
*ORA ATTENZIONE A 1000!!11!!!!*
allows anyone on the Internet to read the memory
*FINE ATTENZIONE A 1000!!!!11!!*
 
  ngw

 (si, e' il caso di buttarla sul ridere, davvero)
 
Nick, è vero che io mi spiego male, ma è anche vero che tu hai la bruttissima abitudine di lavorare a preconcetti, e per far si che il mondo sia ad essi aderente di mettere in bocca agli altri cose che non hanno detto.
La mia riflessione era volta NON a criticare il team OpenSSL, ma a riflettere su quanto C, che a livello è appena sopra Assembly, sia adeguato allo sviluppo attuale, e prendendo in considerazione la media degli sviluppatori; stavo più ragionando sulle riflessioni dell'articolo, insomma.
Circa il buco, ci può sempre stare, che aumentando la complessità aumenta anche la possibilità di errore. La mia esperienza dice che prima o dopo qualcuno lo scopre, e allora si corre ai ripari. That's all. Aggiungo anche: io ho una buona libreria di buchi dormienti che ho risolto; l'ultimo, per dirne una, è stata una correzione, eseguita l'anno scorso, a un supervisore per impianto di risalita scritto nel 1998. Nella particolare condizione che ci hanno riportato il problema si verificava in modo regolare. Però, stranamente, dal 1998 al 2013 quella condizione non si era mai verificata (pensa che rogna, trovare una macchina con il DOS e l'ambiente di sviluppo ancora installato). E qui la riflessione (cui hai dato tutt'altro significato): strano che in un software un buco resti dormiente per molto tempo, sia per il mio supervisore che - a maggior ragione - per OpenSSL; non so, è qualcosa che mi ha sempre colpito. Questo senza voler attribuire colpe, chi è senza buco scagli la prima pietra!
 
-- 
Ciao!
Luca

 Il tutto è piuttosto stupefacente, e viene veramente da chiedersi se il bug in realtà fosse ben noto da tempo, e sia stato rivelato per motivi precisi.
 
Nooo, io sono molto più semplicistico. Si tratta di quel che da noi si chiama 'colpo de mona'. Grossomodo, a ciascuno di noi, ne capitano almeno una decina tutti i giorni. La fortuna? nel 99.99% dei casi non hanno effetti collaterali e sono innocui.
 
-- 
Ciao!
Luca

 E la colpa e' il C.
 
Conosci la storia di quell'ubbriaco, che sbattendo la testa contro un
palo ha dato la colpa al palo che si è trovato proprio lì dove doveva
passare lui? :-D

 Nooo, io sono molto più semplicistico. Si tratta di quel che da noi si chiama 'colpo de mona'. Grossomodo, a ciascuno di noi, ne capitano almeno una decina tutti i giorni. La fortuna? nel 99.99% dei casi non hanno effetti collaterali e sono innocui.
 
Mi prendo la libertà di pensare che  una libreria di crittazione diffusissima è un software molto più soggetto a verifiche di terze parti, ed anche attacchi veri e propri, di quanto non lo siano i miei e tuoi programmi.
Questo di per sè non dimostra niente, ma qui sembra che siamo di fronte non ad un piccolo bug che si manifesta in casi molto speciali e contorti, ma ad una vera e propria voragine. 
Quindi sono d'accordo con te, un normale software è bacato come una gruviera (però con bachini piccoli :-) ma in questo caso non so come non si possa essere molto stupiti.
 

 passare lui? :-D
 
Conosci al storia di chi si taglia una mano su una sega circolare da banco a cui ha tolto le protezioni "perchè se no non si lavora"?
 
Ecco questo è esattamente quello che succede a voler continuare ad un usare un linguaggio senza protezioni.
 
Ciao
  Francesco
 

 chiama 'colpo de mona'. 
 
Esatto, il tipo di colpo di mona che, se fai ad esempio il falegname, di fa saltare le dita con uansega circolare, motivo per cui si montano le protezioni sulle macchine utensili.
 
Volersi ostinare ad usare linguaggi senza protezioni è come ostinarsi a voler togliere le protezioni dagli untensili, è molto diffuso ma non per questo meno idiota.
 
Ciao
  Francesco

 Esatto, il tipo di colpo di mona che, se fai ad esempio il falegname, di fa saltare le dita con uansega circolare, motivo per cui si montano le protezioni sulle macchine utensili.
 
Qui più che al falegname, che perde solo le sue dita, mi fa pensare ad uno che maneggia una testata atomica già innescata, così risparmia tempo ... :-)

On Monday, April 14, 2014 11:48:23 AM UTC+2, Mario wrote:

Quindi, se capisco bene, te e askaholic sono quelli svegli svegli che hanno capito che il problema e' il bere, e continuano imperterriti fino alla cirrosi fulminante?
Io dico solo una cosa, che se nel 2014 si sta a botte di paralleli che ovviamente non c'entrano un cazzo (stare sul pezzo pare essere impossibili, e giu' di paragoni con automobili a chi piu' ne ha piu' ne metta), ci si trova a difendere una tecnologia del millenovecentosettanta (1970) presumibilmente per bieca abitudine e/o "perche' lo fanno tutti", per me un dubbietto che si e' uno zinzino sbagliato lavoro lo si dovrebbe avere.
 
  ngw


Direi che non sai di che parli, una vulnerabilita' resta "dormiente" finche' non la si scopre, visto che non si tratta di un "bug". OpenSSL e una tonnellata di altri software legacy vengono ispezionati in lungo e in largo nei limiti del possibile, ed e' anche andata di lusso che chi ha scoperto la vulnerabilita' l'ha resa pubblica e non l'ha sfruttata (peccato che non sia stato il primo a sfruttarla, e gia' arrivano le prime ammissioni dell'NSA).
Non c'entrano un cazzo gli "sviluppatori di oggi", se il tuo software ha avuto pochi problemi e' presumibilmente perche' nessuno se l'e' filato, e qui torniamo al vecchio "funziona, quindi e' buono".
C e' un linguaggio vecchio, senza protezioni, con una libreria standard piena bombata di problemi (basta vedere la faq di clc: 
http://c-faq.com/
), il cui livello di complessita' rasenta il delirio (sempre secondo comp.lang.c 8 anni di esperienza prima di poter dire "conosco ANSI C"), complessita' che alla fine *non serve ad un cazzo*, se non ad avere software vecchi di 30 anni ancora pieni di bug.
Queste sono le considerazioni che una persona *normale* puo' fare, il resto e' la solita rumenta "chiacchiere e distintivo".
 
  ngw.

 Queste sono le considerazioni che una persona *normale* puo' fare, il resto e' la solita rumenta "chiacchiere e distintivo".
 
Che però vedi solo tu, mi sa. Io sto chiacchierando senza distintivo... 
 
-- 
Ciao!
Luca

 Volersi ostinare ad usare linguaggi senza protezioni è come ostinarsi a voler togliere le protezioni dagli untensili, è molto diffuso ma non per questo meno idiota.
 
Però allora a me viene la domanda successiva. Secondo te - e non solo - qual è IL linguaggio? Premetto che a una domanda del genere io non so dare una risposta (su Python, che ultimamente uso abbastanza, confesso di avere qualche dubbio).
 
-- 
Ciao!
Luca

 Però allora a me viene la domanda successiva. Secondo te - e non solo - >qual è IL linguaggio? 
 
Non c'è IL linguaggio, ce ne sono tanti, il punto che abbiano una serie di misure di protezione per evitare di farsi del male per nulla.
 
Ciao
  Francesco
 
 

 Circa il buco, ci può sempre stare, che aumentando la complessità aumenta anche la possibilità di errore. La mia esperienza dice che prima o dopo qualcuno lo scopre, e allora si corre ai ripari. That's all. Aggiungo anche: io ho una buona libreria di buchi dormienti che ho risolto; l'ultimo, per dirne una, è stata una correzione, eseguita l'anno scorso, a un supervisore per impianto di risalita scritto nel 1998. Nella particolare condizione che ci hanno riportato il problema si verificava in modo regolare. Però, stranamente, dal 1998 al 2013 quella condizione non si era mai verificata (pensa che rogna, trovare una macchina con il DOS e l'ambiente di sviluppo ancora installato). E qui la riflessione (cui hai dato tutt'altro significato): strano che in un software un buco resti dormiente per molto tempo, sia per il mio supervisore che - a maggior ragione - per OpenSSL; non so, è qualcosa che mi ha sempre colpito. Questo senza voler attribuire colpe, chi è senza buco scagli la prima pietra!
 
mi sembra un punto di vista un po' infantile. una vulnerabilità come questa
non è un "bug dormiente", il fatto che a te sia manifestato adesso non implica
affatto che non ci siano state violazioni in passato anzi proprio il passato
è il tuo enorme problema che non risolvi correggendo il bug (tant'è che sei
costretto a chiedere a miliardi di persone di cambiare la loro password).

 tu esponi dei programmi java non la virtual machine.
 
Perche'?
 
http://arstechnica.com/security/2013/01/critical-java-zero-day-bug-is-being-massively-exploited-in-the-wild/
 

 C e' un linguaggio vecchio, senza protezioni, con una libreria standard piena bombata di problemi (basta vedere la faq di clc: 
http://c-faq.com/
), 
 
Tocca un'aggiunta. Io sto dando un occhio a queste faq, giusto per fare un tuffo nel passato. Molte sono domande banali banali, per rispondere alle quali basta sfogliare il K&R.
 
-- 
Ciao!
Luca

 mi sembra un punto di vista un po' infantile. 
 
Paradosso. A quasi mezzo secolo di vita fa quasi piacere sentirselo dire... :-D
 
-- 
Ciao!
Luca


 
Dare la colpa al C mi sembra un po' riduttivo. A questo punto potrei 
dare la colpa all'hardware che lascia ai programmatori la possibilita' 
di accedere alla memoria.
 
Usare una VM significa semplicemente spostare il problema ad un layer 
diverso. I bug di sicurezza sulle vm ci sono...
 
Nessuno nel thread ha tirato in ballo le performance. Se e' vero che a 
runtime spesso C/C++ e java sono comparabili, i linguaggi non compilati 
hanno generalmente performance inferiori. Nel caso di SSL basta la 
pesantezza degli algoritmi di cifratura e non vedo perche' sia 
necessario aggiungere una VM.
 
http://en.wikipedia.org/wiki/Java_performance
 
 
A questo punto mi sorgono un po' di domande:
 
Il team di openssl esegue unit testing sul codice che sviluppa? Viene 
fatta una review seria del codice prima che questo sia accettato nel 
branch ufficiale? Esistono delle best practice nell'uso delle funzioni 
che accedono alla memoria? Perche' se ne sono fregati di bypassare le 
protezioni della libc?
 

 protezioni della libc?
 
OpenSSL e' un pitale di merda. Peccato che sia anche inutilmente complesso e grande, proprio grazie all'utilizzo dell'ottimo C, e nessuno si prenda la briga di rifarlo/metterlo a posto.
Tra l'altro mai visto unit testing fatto in C, pare moltissimi siano convinti che il fatto che la compilazione non esploda sia un test piu' che sufficiente (argomento tirato fuori numerose volte anche su questo gruppo, se il compilatore non da rogne allora i bug sono solo di logica - lol)
 
  ngw

 Tra l'altro mai visto unit testing fatto in C, pare moltissimi siano convinti che il fatto che la compilazione non esploda sia un test piu' che sufficiente 
 
Mi verrebbe da chiedere a chi fa un'affermazione del genere se ha mai aperto una copia di K&R...
C è superato, sono il primo a dirlo, ma a leggere quel che scrivi - e son convinto che non lo pensi - pare che il problema sia il linguaggio in se. In realtà lo è, se non sai quel che stai facendo con precisione, esattamente come lo sarebbe Assembly.
 
 
-- 
Ciao!
Luca

 si e' uno zinzino sbagliato lavoro lo si dovrebbe avere.
 
a' maga circe, se ti riferisci a me sappi che 60% del tempo a lavoro lo passo con camice e protezioni a lavorare su agenti patogeni, in laboratori in cui solo per camminarci hai bisogno di tante di quelle certificazioni tecniche mediche di cui anche solo i nomi molto probabilmente non hai mai sentito in vita tua. Quindi hai sbagliato strada: la programmazione di rete NON e' il mio lavoro, e questo comunque NON e' un NG tecnico.
 
Qualche protocollo network in C l'ho implementato per informatica tanti anni fa, e concordo che programmazione di rete in C ha tante insidie, ma dare esclusivamente la colpa al C mi sembra esagerato. Una discussione positiva dai toni pacati e amichevoli si sarebbe anche potuta instaurare, ma dati i toni, per me e' finita qui. Se non ti piace il NG non ti ci forzano con la pistola a scriverci e a spalare merda gratuita su chi non la pensa come te. Passo e chiudo. Ciao.

 CUT
 
Classico askaholik, da una parte una spocchia infinita nel bullarsi di certificazioni, progettoni e cagate che non interessano a nessuno, dall'altra boccuccia a culo per "i toni".
Mi raccomando, scrivi quando hai qualcosa da dire, che tutta questa boria per delle opinioni mal circostanziate da medioman stonano parecchio.
Per il resto, 'sticazzi non rende l'idea.
 
  ngw
 
p.s. protocolli di rete c'entrano una sega, si vede che eri distratto :D


Ok, mi mostri qualche progetto con test delle unita'?
Ovviamente lo unit testing non era neppure stato inventato ai tempi del K&R, infatti non viene proprio coperto ne citato in quel libro. Del resto penso che in un thread che in qualche modo dimostra quanto obsoleto e' C, citare per ben due volte un libro che nemmeno copre l'ultimo standard ma si riferisce ancora al piu' vetusto C89 sia un modo per beccarsi qualche pacca sulla spalla a gratis da qualche ignorantello senza sapere bene di cosa si parla, ma si sa, io penso sempre male...
 
  ngw


Almeno dare una passata con un tool per static analysis?
 
Unit testing e' utile. Non risolve tutti i problemi, richiede tempo ma 
e' un qualcosa che serve. Specialmente quando vai a fare refactoring. 
Chi la pensa diversamente dovrebbe fare un altro mestiere o non 
lamentarsi che poi gli informatici siano trattati alla stregua dei 
pulitori di cessi :)
 
 
 
ngw: scusami, per errore avevo fatto reply solo a te.


Dici che il C e' obsoleto ma non ne spieghi i motivi e per quali 
applicazioni. Non mi sognerei mai di sviluppare un gestionale in C ma 
d'altra parte facendo firmware non saprei da dove cominciare se dovessi 
usare Java per accedere a un registro. Certo si potrebbe fare il chip 
con la jvm incorporata ma poi sono sicuro che vi lamentereste se il 
vostro cellulare costasse 50 euro in piu'.


A dire il vero l'ho fatto, e nei post precedenti ho anche previsto l'obiezione che hai appena fatto, vedi un po' te.
 
  ngw

 Per quel che mi riguarda, l'ultima cosa che ho scritto in C risale al '97
 
Ma magari prova a sentire anche qualcuno che il C continua a usarlo.
 


Hai ragione, mi ero perso il tuo post. Non capisco pero' perche' le 
definisci chiacchiere da bar. Il mondo non e' fatto solo di webservice 
con qualche migliaio di utenti. Il blog spara a zero sul C senza farne 
un'analisi seria. Imho openssl e' una di quelle librerie che ha davvero 
senso implementare in C. La cosa un po' triste e' che i colossi 
dell'informatica la usino ad occhi chiusi quando avrebbero le risorse 
per mettere su un team che si occupi solo di verificare ogni singolo 
commit fatto dagli sviluppatori.


OpenSSL *non e'* uno use case decente per C, siamo davvero solo a livello dello strato di software appena sopra il ferro, o che ha risorse limitatissime (ma limitatissime sul serio). Un sistema operativo puo' venire scritto in C, ad esempio, ma anche a quel livello le discussioni si sprecano (e' di 20 anni fa la diatriba sulla ML del kernel linux sulla possibilita' di reimplementarlo in C++, per esempio, con argomenti buoni da entrambe le parte - alla fine ha deciso Linus parlando se non sbaglio di gusti personali).
Ha una libreria standard dell'anteguerra che non fa praticamente nulla, e' tipato debolmente, non ha un GC (e tutta la gestione della memoria e' in mano allo sviluppatore, senza nemmeno il piccolo misero aiuto che viene dato da ObjC), e soprattutto, per una libreria nemmeno cosi' gigantesca, necessita di (cito testuale) "un team che si occupi solo di verificare ogni singolo commit fatto dagli sviluppatori". Ma siamo fuori di testa? Mi parli di Unit Testing, ma C non ha uno standard per lo unit testing. Ai miei tempi c'era cunit, ora vedo check, il linguaggio e' di bassissimo livello, quale impari? Analisi statica, dici che e' affidabile in che percentuale di casi? Perche' a me sembra in molto pochi. Ad esempio, non mi pare proprio che heartbleed sarebbe stato scoperto da un Valgrind, proprio per niente, ma magari tu hai piu' esperienza, io l'ho usato poco.
E francamente, trovo questi tentativi di dare la colpa agli sviluppatori abbastanza tristi: solo ultimamente abbiamo subito heartbleed, un bug critico su libyaml (libyaml!, non openssl, libyaml), non notare come il denominatore comune sia sempre C (come lo e' di sendmail, bind, apache, e una tonnellata di altri software con una storia di sicurezza dietro veramente incredibile, per roba vecchia 20 anni - casualmente, OpenSSH e' l'unico che si salva: che sia perche' e' in mano a dei paranoici totali con pratiche di code inspection da Gestapo?) e' davvero miope. Forse e' il caso di usare strumenti piu' consoni al 2014, che pensare che in 40 anni di informatica siamo rimasti fermi all'aritmetica dei puntatori e' almeno imbarazzante.
 
  ngw

 Del resto penso che in un thread che in qualche modo dimostra quanto obsoleto e' C, citare per ben due volte un libro che nemmeno copre l'ultimo standard ma si riferisce ancora al piu' vetusto C89 ...
 
Perché ti cito il K&R? per il semplice motivo che mi indichi come grandi criticità, con tanto di link, problemi che si potrebbero semplicemente risolvere sfogliando un pur vetusto K&R, e che un buon programmatore dell'epoca in cui IO lavoravo in C avrebbe risolto in 2 secondi netti (io ce ne avrei messo una decina ;-) ). 
Personalmente, al link che mi hai passato, ho fatto un tuffo nel passato, ai tempi in cui giochicchiavo con gli interrupt; con K&R e C ho un inevitabile legame affettivo storico, esattamente come ce l'ho con il Pascal e Grogono, con C++ e Stroustrup, con le prime versioni del Petzold, eccetera. 
Tu hai deciso, sapessi poi io perché, che per me quella è l'attualità. Bah...
 
Al che mi viene un sospetto: non è che non hai una mazza da fare, al momento, e stai trolleggiando? Perché c'è quel 'prendo popcorn' del primo messaggio che mi sta ronzando per la testa...
 
-- 
Ciao!
Luca
 
 

 usare Java per accedere a un registro. 
 
In effetti, è proprio quel che dicevo. Per quel che mi hanno spiegato - il mio campo applicativo è differente - il C ormai ha completamente sostituito l'assembly nella programmazione del firmware.
 
-- 
Ciao!
Luca

 pensare che in 40 anni di informatica siamo rimasti fermi all'aritmetica dei puntatori e' almeno imbarazzante.
 
Però ricordo che con l'aritmetica dei puntatori si facevano porcheriole decisamente pericolose e decisamente carine! :D
 
Scherzi a parte. Io un anno fa ho messo una pezza a un buco nella versione corrente di CherryPy. Fastidioso e ripetibile, e sistemato nella versione successiva (io avevo fatto una segnalazione al team, ma non credo sia stato quello il motivo per cui l'hanno risolto); dovrei dare la colpa a Python?
Quando io lavoravo in C, nel lontano '89, facevo parte di un gruppo; in questo, un collega scriveva del codice splendido e, se diceva che era a posto, era a posto; un altro che, quando diceva 'è a posto', avevi la certezza matematica che qualche problema c'era - e in effetti il primo collega prendeva il codice e lo ricontrollava, correggendolo. Vero, non c'era lo unit testing, ma non posso pensare che i problemi derivassero solo dal linguaggio.
 
-- 
Ciao!
Luca


Valgrind non fa analisi dinamica e comunque non e' il tool piu' avanzato 
in "commercio". Dai un occhio a questo:
 
http://www.coverity.com/products/code-advisor/
 
 
Siamo d'accordo che la flessibilita' del C renda facile commettere 
errori e che se non stai facendo qualcosa a basso livello il C non e' 
necessario e anche sul fatto che il GC fa miracoli. La discussione sul 
kernel scritto in C++ si e' risolta con Linus che faceva notare in modo 
"molto educato" che quel linguaggio ha delle feature che hanno un grande 
impatto sulle performance.
Il punto e' che librerie come openssl vengono usate a tutti i livelli. 
Puoi vederle come una parte di sistema operativo. Esistono decine di 
prodotti con limitatissime risorse di memoria e cpu che hanno bisogno di 
openssl. E anche in ambienti dove le risorse non sono limitate esistono 
problemi di performance dove anche piccoli overhead pesano sul budget. 
Alla fine e' vero che i tool di analisi, le best practice ecc. fanno il 
lavoro della VM ma scaricano il processore dal lavoro che la VM fa a 
runtime.
Probabilmente lavoriamo in campi diversi e quindi pensiamo a target 
diversi ma il mondo e' pieno di sistemi che di risorse non ne hanno mai 
abbastanza. Poi avviate una campagna per riscrivere internet in java e 
io scrivero' un bel blog dal titolo: The Internet will never be fast, 
Ever... because the software in your router/server/social network is 
written in java..

 Il blog spara a zero sul C senza farne un'analisi seria. 
 
Mi tocca quotare anche questa. Anche se mi sembra che tu vedi ancora, per il C, un ambito applicativo più ampio rispetto al mio.
 
-- 
Ciao!
Luca
 
 

 written in java..
 
<troll>
Propongo di riscrivere tutto in C#...
</troll>
 
-- 
Ciao!
Luca
 
 


Un paio dei progetti su cui ho lavorato di recente:
 
- Switch ottico: maggior parte del lavoro fatto in hardware ovviamente 
controllato da firmware scritto in C. Qui la parte di controllo sopra il 
firmware era fatta in C ma sarebbe potuta essere tranquillamente in java 
(un pezzettino lo era anche).
 
- Pannello antincendio: qt embedded inizialmente usando qml... progetto 
da oltre 400k euro che stava fallendo a causa delle scarse prestazioni 
dell'interprete qml. Il dev di digia a berlino ci e' rimasto un po' male 
quando gli ho fatto vedere i risultati del profiler.
 
- Firmware per un elettrodomestico (per il prossimo natale ne saranno 
prodotti 2 milioni): e' stato necessario acquistare la versione a 
pagamento del compilatore perche' altrimenti il codice non stava nella 
flash. Aumentare la flash era fuori discussione visto che anche se fosse 
costata 10 cent (e costa di piu') avrebbe avuto un costo totale di 200k 
euro. In casi come questo si preferisce pagare un team di sviluppatori 
per un mese piuttosto che dire: ma si aggiungiamo un po' di memoria.
 
Ora immagina solo un garbage collector che gira in uno dei casi sopra e 
che parte quando vuole lui...

 che parte quando vuole lui...
 
Beh, un GC per definizione non dovrebbe MAI partire quando vuole lui, al più dovrebbe partire quando vede inattività da parte dell'applicazione. E in effetti, chi ha sviluppato applicazioni critiche - a me non è mai capitato - mi ha spiegato che in quel caso si progettano anche le finestre in cui far girare il GC.
 
Quando però parlavo di ambito applicativo non parlavo solo di firmware, in cui il C ci sta che è uno spettacolo, ma tante altre cose per le quali proprio il C non è fatto o non è più adatto. Io l'ho tagliata con l'accetta, ovvio, ma secondo me l'idea dell' "Assembly amichevole" non è così peregrina.
 
-- 
Ciao!
Luca
 


 
Sono d'accordo che il C sia assembly amichevole. In realta' ha un 
vantaggio... il compilatore ti genera codice piu' efficiente di quello 
che scriverebbe in assembler uno che NON sviluppa compilatori :)

 linux ti killa il processo...
 
Mi sono spiegato male (una costante, a quanto pare, ultimamente). Se ho letto bene, il GC è un processo a priorità piuttosto bassa che viene fatto partire quando altri processi sono inattivi (tagliata anche questa con l'accetta, passamela). Il rischio che hai, mi spiegavano, è proprio quello che paventavi tu: si può essere in presenza di processi talmente impegnativi che de facto il processo di garbage collection non viene mai avviato, o viene avviato in modo erratico. Ecco allora come sia conveniente, proprio per quel che dicevi tu, progettare delle finestre in cui la GC venga fatta eseguire (in C# ci sono addirittura direttive specifiche che ne invocano l'esecuzione, non so in altri linguaggi).
 
-- 
Ciao!
Luca

 problemi di performance dove anche piccoli overhead pesano sul budget. 
 
Ovviamente hai ragione a dire che a seconda degli ambiti bisogna sfruttare l'hardware nel modo più opportuno. Però francamente mi sembra folle pretendere che una libreria di crittografia (come tale particolarmente critica) debba girare più o meno tale e quale dal microcontroller al supercomputer. E pertanto debba essere scritta prendendo come parametro l'hardware meno potente!
Alla fine il discorso tecnico conta fino ad un certo punto, contano molto anche considerazioni sugli sforzi (ed i soldi) necessari a riscrivere da zero.
 
 

 specifiche che ne invocano l'esecuzione, non so in altri linguaggi).
 
esiste anche in java l'invocazione esplicita ma è ovunque sconsigliata. 
non lo può sapere il programmatore a compile time quando è il momento di 
raccogliere il garbage.  
se uno vuole mantenerne il controllo ne ha di che smanettare:
http://goo.gl/2Rplp
 

 finestre in cui far girare il GC.
 
non so cosa intendi per "applicazioni critiche" ma quello che ti posso 
dire è che anche nel real-time java i cicli gc *non* vengono decisi in 
alcun modo da programma. certo usa un modello diverso rispetto alle 
applicazioni tradizionali ma sempre e comunque pilotato dalla vm. 

 finestre in cui far girare il GC.
 



 
1) a) Non ho mai programmato in ADA (pur avendone studiate alcune 
caratteristiche a livello universitario) per cui non so bene quanto sia 
efficiente (ma ho seri dubbi che non lo sia).
 
   1b) Il titolo del thread e' "Internet will never be secure", non 
"internet will never be safe". Per quanto ne so io ADA e' un linguaggio 
pensato per avere sistemi ad elevata "safety", piu' che "security".
 
Anche se in italiano puoi tradurre entrambi i termini con
"sicurezza", dal punto di vista informatica hanno significati diversi.
 
Quando dicevo piu' attenti alle performance che alla security, 
indirettamente intendevo anche piu' attenti alla safety che alla
security (visto che, come risulta dalle basi della teoria dei sistemi,
se tu introduci un ritardo in un sistema di controllo reazionato rischi
di farlo diventare instabile [o, in altre parole, rischi di far
precipiare l'aereo, deragliare il treno, ecc.])
 
2) posso testimoniare per esperienza diretta che ad un colloquio a 
Bologna nel 2004 mi proposero di andare a scrivere softtware in C/C++ 
per controllo di treni ad alta velocita' per conto di Ansaldo o una 
societa' ad essa collegata. Uno dei motivi per cui
non se ne fece niente e' che richiedevano di conoscere alcuni standard
(appunto relativi alla safety) dei quali standard  in questo momento non 
ricordo il nome, ma di cui  in passato ho anche scritto sul newsgroup.
 
3)In ogni caso, a mio modo di vedere, se queste aziende scrivono in ADA 
anziche' in C/C++ allora le "tonnellate di software", che secondo me 
erano gia' poche, allora diminuiscono ancora.
 
 
 
 >> In ogni caso la parte interessante dal mio punto di vista era quella che
 >>
 >> hai tagliato, ovvero: quali aziende continuano a sviluppare condice
 >>
 >> in C/C++ a tonnellate ?
 >
 > Magari tutte quelle che sviluppano parti di sistemi operativi, come 
drivers?
 
Puo' essere. Ho modificato anch'io in passato (1998-2000) dei driver in 
C di una rete FDDI.Non erano per un SO ma per un simulatore 
motociclistico. E li ho modificati per eliminare dallo stack 
protocollare il livello TCP, cioe' per evitare ritrasmissioni che 
implicavano appunto il peggioramente dei tempi di risposta con rischio 
di sforamento della deadline, che era di 1 ms in alcuni sottosistemi, 10 
ms in altri . Cioe' li ho modificati per aumentare la safety del 
sistema, tramite il miglioramento delle performace . Della security 
invece mi sono relativamente disinteressato anche perche' il sistema era 
comunque isolato dal mondo: collegarlo a internet avrebbe significato 
avere collisioni sulla rete che connetteva i vari sottosistemi del 
simulatore con possibile instabilita' del sistema e una tonnellata di 
ferraglia che teoricamente poteva cadere addosso al collaudatore del 
simulatore [l'instabilita' era dovuta al ritardo tra l'acquisizione dei 
dati dai sensori e l'invio dei comandi agli attuatori: sono stato tutta 
l'estate di uno di quegli anni, non ricordo se era il 1999 o il 2000, a 
fare test per verificare i ritardi introdotti dal collegamento in rete : 
ti posso garantire che collegando l'accrocchio alla ethernet, anziche' 
ai drivere FDDI modificati, quindi rendendo la trasmissione dei dati 
soggetta a collisioni, si aveva un 20% di sforamento della deadline, 
cioe' 12 ms invece di 10, con rischio non trascurabile per la salute di 
chi saliva sul trespolo ].
 
 >O versioni speciali di Linux/Unix?
 
Ma scusa, driver e versioni speciali di Linux sarebbero "montagne di 
codice", in confronto a tutto il software che viene prodotto ?
E sarebbero questi i punti in cui internet e' vulnerabile ? I driver ?
Comunque se in Italia esistono aziende che fanno queste cose  posso 
sempre provare a mandagli un CV.
 
 
 > O magari DBMS?
 
Puo' darsi , ma in ogni caso anche aziende che producono questi in 
italia non ne ho viste molte.
 
 > Ma forse ti riferivi a software gestionale, in quel caso ti dò 
ragione, si usa altro.
 
Mi riferivo a tutto il software che non sia hard real time. Anche 
software "soft real time", come quello che si usa in ambito 
telecomunicazioni (tipo per spedire SMS e simili), mi risulta essere
ormati tutto (o quasi) in java, cosi' come quello per l'accesso
ai sistemi bancari (quello si' security-critical [ma non safety 
critical]). E proprio uno che lavorava alla parte web Bancoposta mi 
disse all'epoca che il maggiore problema della security non era
affatto legato al linguaggio di programmazione, ma semplicemente
al fatto che la gente sceglieva come password "pippo" o simili e
come username il porprio nome e/o cognome. Per cui se io sapevo
che tu avevi un conto bancoposta, magari accedevo al sito con il tuo
cognome poi digitavo pippo come password, entravo e potevo magari fare
anche operazioni dispositive. E proprio per questo tipo di problemi gli
ultimi anni che ho lavorato da quelle parti midicevano di aver dotato 
tutti i propri clienti di apposito dicendo loro: o usi questo o non puoi 
fare operazioni online.
 
Ciao,
Marco.
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---


 
era:
  tutti i propri clienti di apposito lettore di smart card dicendo loro: 
o usi questo o non puoi
 
 
---
Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus.
http://www.avast.com
 
 

 Prendo popcorn.
 
   Letto oggi: sarà che il linguaggio di per sé non implica una maggiore 
sicurezza, però la statistica dice che...
 
http://developers-beta.slashdot.org/story/14/04/16/2021227/code-quality-open-source-vs-proprietary
 
 
"C/C++ developers fixed more high-impact defects. Analysis found that 
developers contributing to open source Java projects are not fixing as many 
high-impact defects as developers contributing to open source C/C++ projects."
 
 
   Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 high-impact defects as developers contributing to open source C/C++ projects."
 
La risposta ovvia è che ne generano anche una infinità di meno, del resto dalla citazione sembra 
che il confronto sia prettamente numerico, quindi un progetto con 100 bug critici di cui ne vengono
corretti 80 ha una valutazione inferiore di uno con 10 bug critici di cui ne vengono corretti 9, il che
è abbastanza folle
 
  ngw

 � abbastanza folle
 
   Nell'articolo si parla chiaramente di "Defect density (defects per 1,000 
lines of software code)".


 high-impact defects as developers contributing to open source C/C++ projects."
 
Non dice molto. Sposta l'arbitrarietà e l'indeterminatezza dal conteggio statistico dei difetti alla classificazione di ciò che è "high impact" e ciò che non lo è.
Chi lo stabilisce? I classici "esperti"?


   Ci sono dei criteri, sensibili al contesto, alla clientela di riferimento 
e al tipo di dati trattati. Tra quelli più generici, da usarsi come linea 
guida in casi in cui non si che pesci prendere, sono organizzati secondo 
questa scala (a memoria):
 
1) diffusione dati sensibili utenti;
2) perdita dati sensibili utenti;
2) perdita continuità servizi primari;
3) autenticazione illecita;
4) perdita dati critici per l'erogazione del servizio;
5) diffusione informazioni attività utenti;
6) diffusione informazioni attività infrastruttura telematica;
7) prestazioni non ottimali infrastruttura telematica.
 
   In tutte le trattazioni delle falle di vulnerabilità o di perdita di 
funzionalità/prestazioni si fa sempre riferimento ad una scala di gravità. 
Certamente qualunque scala si scelga c'è sempre del dibattito su quanto sia 
oggettiva o applicabile al caso in questione, ma a filosofeggiare nulla è un 
bug, sono tutte ficiùr.  Resta il fatto che i difetti vanno scoperti, 
analizzati e priorizzati per urgenza di risoluzione.  E poi magari anche 
risolti ;-)
 
   Non escluderei poi che alla classificazione dei difetti partecipino gli 
stessi autori/aziende che lo producono.  Scrivono infatti nel report che il 
software proprietario che analizzano è fornito dagli stessi autori/aziende 
che si servono dei servizi di analisi qualità della Coverity, il Coverity 
Scan service.


 � abbastanza folle
 
   Folle?  Quale software � migliore, quello che ha 20 bug critici, o quello 
che ne ha uno?


 Scan service.
 
 
Il che richiede ancor più di stare attenti e critici.  

 che ne ha uno?
 
Quello che ne ha uno. Per questo si fa fatica a dare un valore all'affermazione "i programmatori C++ stanno fixando piu' bug dei programmatori Java". 
 
  ngw

 Quello che ne ha uno.
 
   Quindi sono migliori i programmi che hanno un defect density inferiore.
