This is a discussion on Re: Coverity Open Source Defect Scan of NetSNMP - SNMP ; >>>>> On Sun, 05 Mar 2006 22:51:32 -0800, Ben Chelf said: Ben> I'm the CTO of Coverity, Inc., a company that does static source Ben> code analysis to look for defects in code. Hi Ben, I'm the founder and lead-developer ...
>>>>> On Sun, 05 Mar 2006 22:51:32 -0800, Ben Chelf
Ben> I'm the CTO of Coverity, Inc., a company that does static source
Ben> code analysis to look for defects in code.
I'm the founder and lead-developer of Net-SNMP. I've registered with
your site to look at your results... I can't offer much more help
until my registration is approved. We certainly do appreciate being
able to look at the results of your analysis and would certainly like
to fix as many bugs as possible that you've found.
Ben> Because of this second point, I'd ask that if you are interested
Ben> in really digging into the results a bit further for your
Ben> project, please have a couple of core maintainers (or group
Ben> nominated individuals) reach out to me to request access.
I don't mind being the funneling point to the rest of the developers
here on this project if that would help. It's unclear what the
re-distribution policy is for your results at this time (I haven't
looked for release information). Your rational for limiting the
initial access certainly contains valid general reasons. What I'm not
sure of is whether if I want to open the results to a greater
audience (but channel the results back through me to you to limit your
needed work load), would that be acceptable or not?
Ben> Many thanks for reading this far...
You're the one that's doing a lot of good work. Thanks for keeping us
I'm not surprised that Net-SNMP contains a number of bugs. I'm aware
of a lot in the low-level MIB code and they're even difficult to fix
at times. What I want to make absolutely sure of first and foremost
is that the path to get to those low level MIB objects is as secure as
possible. My first priority is always from the network down to the
authentication and authorization stack. Beyond that it is important
to try and maintain good solid code as well, but it's not *as*
important as ensuring that packets are authorized to even get to the
more touchy points in the code.
One of the other thing that makes our stack hard is that there is a
huge amount of ifdef'ed architecture-specific code. The end result is
that there is likely less bugs per 1000 lines on any given real
instance of the software than there is in the whole package, because I
believe the core routines are safer than the lower level
per-architecture code. The ifdef structures also make automated
scanning likely difficult. SNMP agents are a very architecture
specific piece of work. That being said, I hope you found a bunch of
valid bugs! I only hope that they're easy to analyze ;-)
[Also on a side note: we've actually confirmed a few cases of other
security detectors falsely interpreting some of our code as being bad
because we use a large number of fairly, um, interesting structures
and techniques to achieve some of our goals. The sad thing is that
when some of these reports come in we take a lot of time analyzing it
to end up agreeing that it's not really a problem. I'm sure your
report will contain many real points of interest, of course, and look
forward to reading it]
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
Net-snmp-coders mailing list