On 04/25/2014 03:11 PM, Justin Clift wrote:
> On 25/04/2014, at 7:45 PM, Lalatendu Mohanty wrote:
>> On 04/25/2014 09:44 PM, Joe Julian wrote:
>>> GlusterFS was rejected during the security analysis with these comments:
>>>> here's just a list of what I found while reading the code:
>>>> - cppcheck reports ~20 real coding mistakes, perhaps a few false positives
>>>> - get_uuid_via_daemon() doesn't check fork() for error return
>>>> - rdd_valid_config() buffer overflow rdd_config.out_file.path
>>>> - gf_cli_print_limit_list() doesn't check sprintf(abspath) return value
>>>> - rb_malloc() and rb_free() ignore their allocator argument
>>>> Not a security problem, but might be very surprising
>>>> - int_to_data() data_from_[u]int{64,32,16,8}() data_from_double()
>>>> all re-calculate the length rather than use the return value from
>>>> gf_asprintf(). (Not a security problem, just redundant.)
>>> Should we add cppcheck to Jenkins?
>> Yes, we must. There is a Jenkins plug-in present for Cppcheck[1]. Also we should update the page for Cppcheck in gluster wiki[2]
>>
>> [1] https://wiki.jenkins-ci.org/display/JENKINS/Cppcheck+Plugin
>> [2] http://www.gluster.org/community/documentation/index.php/Fixing_Issues_Reported_By_Tools_For_Static_Code_Analysis
> Cppcheck home page:
>
> http://cppcheck.sourceforge.net
>
> It's in EPEL, so I've just yum installed it on build.gluster.org in
> case someone has the time/inclination to get the Jenkins integration
> happening. (I don't)
>
> + Justin
>
Just to keep all this discussion in one place:
#gluster [10:01] <kkeithley> JoeJulian: I'll try running cppcheck to see
how long it takes. I'm setting up a bunch of machines to do things like
routinely run things like coverity, cppcheck, valgrind, etc. If cppcheck
takes to long perhaps we just want a daily run instead of a run every
time someone commits
