On 4/13/2011 4:04 PM, Roger Binns wrote: > On 04/12/2011 08:25 AM, Stephen Blessing wrote: > > It appears that your SQLite3.6.23.1 software may have some security > issues > > that need to be addressed: > > The tool you used is pathetic. It is about as helpful as saying your > house > has "High" security risks because it found scissors. What is important is > context - how are they used, by whom and can unintended people get access. > The tool is "rough" because it doesn't bother with that context. > > Far better tools are Coverity and one included with Clang. You can see > Coverity's opinion here: > > http://scan.coverity.com/rung1.html As coverity corp runs their tool on sqlite, doesn't this mean the developers have access to the results?
And yes those source code checkers do test if a room has no doors or that there are no bricks stacked straight. Nothing a good programmer w(c)ouldn't see himself - if he spent the hours of digging n-levels deep into the call chain.... They are a great tool ensuring programs have fewer memory leaks, thread issues and the like and if one has access to their results, please USE it and judge the false positives with human eyes - strcpy & fprintf are not security risks by themselves but only in an application context. Reviews (human & automated) are always a good step towards a stable codebase! - my 5 cent thilo > > And because Clang is open source the SQLite authors were able to run it > themselves and fix anything it showed up. > > Note that in the vast majority of cases these tools come up with false > positives. The styling of the SQLite code is changed to keep them happy. > See also: > > http://www.sqlite.org/faq.html#q17 > > Roger _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
