Das ist sicherlich gut für die OSS, da es Fehler reduziert. Aber man darf nicht vergessen, dass dieses automatisierte Tool nicht annähernd alle Fehler findet.
Also nicht in falscher Sicherheit wiegen!
Am meisten profitiert wohl Coverty, da sie dafür bezahlt werden.
> Aber man darf nicht vergessen, dass dieses > automatisierte Tool nicht annähernd alle > Fehler findet.
Natürlich nicht. Aber Menschen finden auch nicht annähernd alle Fehler (außer sie haben eine wirklich korrekte Spezifikation und beweisen jede Zeile Code mathematisch). So what. Ich sehe so ein Tool als einen weiteren Reviewer, der sich auf bestimmte Fehlersorten spezialisiert hat und andere prinzipbedingt nie finden wird.
> Am meisten profitiert wohl Coverty, da sie > dafür bezahlt werden.
Von wem? Ich würde es eher als Imagepflege und PR sehen (wogegen ich per se erstmal nichts habe).
> Von wem? Ich würde es eher als Imagepflege und PR sehen (wogegen ich per se erstmal nichts habe).
Vom DHS (Department of Homeland Security). Siehe http://www.pro-linux.de/news/2006/9388.html
Ich habe ja bereits gesagt, dass es schön ist wenn Fehler reduziert werden, aber ich wehre mich gegen diese "Scheinsicherheit" die da produziert wird. Es wird suggeriert, dass nach der Fehlerbehebung von Coverty gefundenen Fehlern, die Software sicher und fehlerfrei ist. Das ist sie aber nicht.
Auch dass Marketinggeschrei: "... Analysetechnik von Coverity wirke, als hätte man einen Entwickler mit übermenschlicher Konzentration auf das Detail im Team" finde ich eher irreführend. Jeder real existierende Entwickler ist da wertvoller.
Von Markus Fleck-Graffe am Di, 4. April 2006 um 07:26 #
Bei dem Blog-Skandal in der vergangenen Woche um die Verschiebung von Microsofts neuem "Windows Vista" (minimsft.blogspot.com) ging es unter anderem darum, dass durch die Einführung von Tools zur automatisierten Suche von C/C++-Bugs ("PREFIX"/"PREFAST") die Microsoft-Programmierer nicht mehr zum Programmieren kämen, weil sie den halben Tag lang nur damit beschäftigt wären, vermeintliche oder tatsächliche C/C++-Fehler zu beheben, die von dem Tool gemeldet würden.
Dass die Fehlerbehebung bei Freier Software unkomplizierter ist, freut mich zu hören; es mag auch daran liegen, dass das Win32-API sowohl bei den Funktionsnamen als auch bei den diversen Varianten zur Übergabe von Parametern eher an "Kraut und Rüben" erinnert als eine durchdachte Programmierschnittstelle. [1]
Man muß aber erfahrungsgemäß damit rechnen, dass durch Anpassungen auch (zumindest vorübergehend) eine Reihe neuer Fehler in die genannten Programme kommen kann; sei es, weil etliche der gemeldeten Fehler lediglich mechanisch (d.h. per Suchen/Ersetzen-Funktion) "korrigiert" wurden, was nicht immer korrekt sein muss, sei es, weil der bisherige Code in subtilen Details (z.B. bei Samba auf der SMB-Protokollebene) etwas anderes gemacht hat als die "korrigierte" Version. Solche Fehler können sehr tückisch und schwer zu finden sein, und (z.B. auf Protokollebene) auch schnell mal neue Sicherheitslücken aufreissen.
Als unterhaltsames Beispiel in diesem Zusammenhang sei auf das Computerspiel verwiesen, das sich nur mittwochs beenden liess:
(der Bug, der beginnt mit "U29 - I once had a program that only worked properly on Wednesdays.")
Insofern: Maschinelle Codeanalyse ist wichtig, aber auch nicht ohne Risiken. Es wäre sehr hilfreich, wenn der GCC (GNU Compiler) bei Bedarf noch deutlich mehr und bessere Warnungen ausspucken würde, damit potenzielle Fehler gleich vom ursprünglichen Entwickler behoben werden könnten, oder wenn es zumindest ein besseres freies "lint(1)" gäbe.
Grüße, MFG.
[1] Als Beispiel für eine besonders haarsträubende Win32-Funktion sei auf NetUserSetInfo() verwiesen: http://tinyurl.com/ockaa
"...weil sie den halben Tag lang nur damit beschäftigt wären, vermeintliche oder tatsächliche C/C++-Fehler zu beheben, die von dem Tool gemeldet würden."
Tja, an Fehlerbehebung sind die Leute aus Redmond nicht wirklich gewöhnt.
Firefox hat laut der Ergebnisse von Coverity 84843 Code-Zeilen. Das erscheint mir doch etwas wenig. Beim Nachzählen in FF 1.5.0.1 komme ich alleine in den *.{c,cpp,h}-Dateien auf ca. 4,8 Mio Zeilen. Ok, darin sind auch Leerzeilen und Kommentare enthalten. Aber die werden doch nicht mehr als 98% des Gesamtcodes ausmachen.
Hat Coverity nur Ausschnitte geprüft, oder wie ist die Diskrepanz sonst zu erklären?
Da hast du wahrlich Recht. Auch Linux 2.6 hat offiziell 6M SLOC und nicht 3M, das gleiche bei gcc der eher aus 1,5M SLOC als den angegebenen 750k besteht. Das kann ich mir auch nicht so recht erklären.
Das weiß wohl Coverty allein, die ihre Analysetools nicht veröffentlichen und die Vorgehensweise nicht bekannt machen.
Jo finde ich auch komisch. Bei NetBSD steht z.B mehr als 5 Mill. Zeilen. Da haben die wohl das komplette Userland und GCC mitgemessen Oder hat NetBSD wegen den vielen unterstützen Platformen wirklich so viel?
Also nicht in falscher Sicherheit wiegen!
Am meisten profitiert wohl Coverty, da sie dafür bezahlt werden.
> automatisierte Tool nicht annähernd alle
> Fehler findet.
Natürlich nicht. Aber Menschen finden auch nicht annähernd alle Fehler (außer sie haben eine wirklich korrekte Spezifikation und beweisen jede Zeile Code mathematisch). So what. Ich sehe so ein Tool als einen weiteren Reviewer, der sich auf bestimmte Fehlersorten spezialisiert hat und andere prinzipbedingt nie finden wird.
> Am meisten profitiert wohl Coverty, da sie
> dafür bezahlt werden.
Von wem? Ich würde es eher als Imagepflege und PR sehen (wogegen ich per se erstmal nichts habe).
Vom DHS (Department of Homeland Security). Siehe http://www.pro-linux.de/news/2006/9388.html
Ich habe ja bereits gesagt, dass es schön ist wenn Fehler reduziert werden, aber ich wehre mich gegen diese "Scheinsicherheit" die da produziert wird. Es wird suggeriert, dass nach der Fehlerbehebung von Coverty gefundenen Fehlern, die Software sicher und fehlerfrei ist. Das ist sie aber nicht.
Auch dass Marketinggeschrei: "... Analysetechnik von Coverity wirke, als hätte man einen Entwickler mit übermenschlicher Konzentration auf das Detail im Team" finde ich eher irreführend. Jeder real existierende Entwickler ist da wertvoller.
Außerdem habe ich letztens per Zufall gesehen, das einige Coverity NetBSD Fixes auch von OpenBSD übernommen wurden.
http://www.securityfocus.com/columnists/380
na, ob Theo endlich eingelenkt und die Lücke geschlossen hat?
Ich befürchte ja nein.
Dass die Fehlerbehebung bei Freier Software unkomplizierter ist, freut mich zu hören; es mag auch daran liegen, dass das Win32-API sowohl bei den Funktionsnamen als auch bei den diversen Varianten zur Übergabe von Parametern eher an "Kraut und Rüben" erinnert als eine durchdachte Programmierschnittstelle. [1]
Man muß aber erfahrungsgemäß damit rechnen, dass durch Anpassungen auch (zumindest vorübergehend) eine Reihe neuer Fehler in die genannten Programme kommen kann; sei es, weil etliche der gemeldeten Fehler lediglich mechanisch (d.h. per Suchen/Ersetzen-Funktion) "korrigiert" wurden, was nicht immer korrekt sein muss, sei es, weil der bisherige Code in subtilen Details (z.B. bei Samba auf der SMB-Protokollebene) etwas anderes gemacht hat als die "korrigierte" Version. Solche Fehler können sehr tückisch und schwer zu finden sein, und (z.B. auf Protokollebene) auch schnell mal neue Sicherheitslücken aufreissen.
Als unterhaltsames Beispiel in diesem Zusammenhang sei auf das Computerspiel verwiesen, das sich nur mittwochs beenden liess:
http://www.adahome.com/articles/1997-05/bugtales/bugtales.3o4
(der Bug, der beginnt mit "U29 - I once had a program that only worked properly on Wednesdays.")
Insofern: Maschinelle Codeanalyse ist wichtig, aber auch nicht ohne Risiken. Es wäre sehr hilfreich, wenn der GCC (GNU Compiler) bei Bedarf noch deutlich mehr und bessere Warnungen ausspucken würde, damit potenzielle Fehler gleich vom ursprünglichen Entwickler behoben werden könnten, oder wenn es zumindest ein besseres freies "lint(1)" gäbe.
Grüße, MFG.
[1] Als Beispiel für eine besonders haarsträubende Win32-Funktion sei auf NetUserSetInfo() verwiesen: http://tinyurl.com/ockaa
Tja, an Fehlerbehebung sind die Leute aus Redmond nicht wirklich gewöhnt.
Hat Coverity nur Ausschnitte geprüft, oder wie ist die Diskrepanz sonst zu erklären?
Das weiß wohl Coverty allein, die ihre Analysetools nicht veröffentlichen und die Vorgehensweise nicht bekannt machen.