[sldev] Static code analysis

[Gareth Nelson]

> a. the good people at coverity want the "official contact" of the open
> source project to setup the account for this process. I'm guessing this
> probably means Rob or Soft. Speak nicely to Rob about it, he's already got a
> bunch on his plate.
Ideally, this would only involve releasing the report from coverity to devs

> b. the SL Viewer makes use of a number of other libraries. for a "proper"
> security experience, we should try to get these libraries put in the scan
> queue as well.
I believe that getting the SL codebase audited is a good major step forward

> c. believe it or not, there are bugs that static analysis won't find. Don't
> get me wrong, doing a static analysis is a good first step. But once you do
> a static analysis and fix the bugs you find, there are still a large class
> of vulnerabilities that could be present in the code. just keep in mind that
> the idea behind automated tools is not that they find every vulnerability,
> but that the free people to track down the really bad ones.
Of course automated tools won't find bugs (personally I think only a
singularity-level AI could come close to that.......) but it's a major
help

> d. there are other static code analysis tools, some of which are free as in
> beer. fortify and coverity will tell you they're not as good, and it's true
> to a point.. flawfinder definitely looks for fewer things than fortify. but
> it's free. hmm... free tool meets open source repository... hmm...
> interested parties can find more than enough to keep them busy for a while
> at https://samate.nist.gov/index.php/Source_Code_Security_Analyzers .
A free solution is always better of course as regards community participation :)

> e. it is characteristic of these tools that there is some give and take
> between the tool and the tool using mammal behind the keyboard. many static
> analysis tools are quite configurable and allow the user to perform invasive
> scans that produce an ox-stunning amount of output or to perform a light
> scan, which gives little of value. there's a lot of finesse required to use
> these tools effectively. this has led some to consider these tools thinly
> veiled professional services sales vehicles.
As someone who's not used these tools personally, how comparable are
they to paranoid compiler options that produce 10 billion warnings?
Running through build.log and using compiler warnings as a checklist
in my own projects is almost a hobby for me.....

>
> -cheers
> -infinity
>
> On Jan 11, 2009, at 9:09 PM, Gareth Nelson wrote:
>
>> I see no reason why in the meantime the community can't use this tool
>> using the free trial
>>
>> On Mon, Jan 12, 2009 at 4:13 AM, Soft <soft at lindenlab.com> wrote:
>>>
>>> On Sun, Jan 11, 2009 at 7:57 PM, Jason Giglio <gigstaggart at gmail.com>
>>> wrote:
>>>>
>>>> Sheet Spotter wrote:
>>>>>
>>>>> I stumbled into a code analysis tool from Coverity that claims to
>>>>> identify source code flaws through an elaborate static code analysis
>>>>> with a lower "false positive" rate than similar tools. Coverity seems
>>>>> to
>>>>> offer their tool (or their services?) free of charge to open source
>>>>> projects.
>>>>
>>>> I went through this a couple years ago.
>>>>
>>>> The conclusion of the thread was that Linden Lab already licensed
>>>> Coverity internally, and they weren't going to release the results of
>>>> the report to us.  There were some vague excuses about security or
>>>> something, and that the open source community can't really help fix
>>>> those kinds of bugs anyway.
>>>
>>> The problem is that the Coverity report is generated against the full
>>> build, including server components and things where we don't have a
>>> license to redistribute code. If we renew our Coverity license (that's
>>> up in the air - I'd heard that it's hugely expensive), the plan is to
>>> get a separate analysis running against the very same code that's
>>> exported, and to export that routinely.
>>> _______________________________________________
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/SLDev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>
>>
>>
>> --
>> Please avoid sending me Word or PowerPoint attachments.
>> See http://www.gnu.org/philosophy/no-word-attachments.html
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>
>



-- 
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html