automated cppcheck for gnupg

[Leo Gaspard]

On Tue, Apr 15, 2014 at 05:23:16PM -0400, Hans-Christoph Steiner wrote:
> 
> 
> On 04/15/2014 03:22 PM, Leo Gaspard wrote:
> > On Tue, Apr 15, 2014 at 03:05:55PM -0400, Hans-Christoph Steiner wrote:
> >> As part of all the C/C++ jobs that we run on our jenkins build server, I set
> >> up cppcheck on them.  It is a static code analyzer that has caught some of our
> >> mistakes (a kin to heartbleed, they are easy to make in C).
> >>
> >> I have cppcheck running on the gnupg jobs that are already running there.  It
> >> does not seem to be pointing to anything too alarming, but it does claim a
> >> number of memory leaks:
> > 
> > Given that you report errors such as 
> >> 	deallocDealloc	Deallocating a deallocated pointer: hd
> > (and others, including null dereferences), that could possibly be security flaws
> > (don't know, didn't look at the code), I suggest that, next time, you report it
> > to Werner by private email instead of using a public mailing list.
> > 
> > Just my two cents !
> > 
> > Leo
> 
> If I had discovered flaws on my own accord that cppcheck had missed, then I
> agree it would make sense to keep it private.  Since its really not hard to
> run cppcheck, I think it doesn't need to be kept private since anyone looking
> for exploits would start with automatic tools like cppcheck.


Well, it might be that noone ever tried ccpcheck, and other tools do not report
the same mistakes. There are a number of static analysis tools available, and
keeping it private costs virtually nothing. (The null dereference in libassuan
that Werner said he would fix tomorrow might be specially important, given it's
in actively used code -- or did I misunderstand Werner's message?). Proof anyone
looking for exploits do not use cppcheck: you are the first to report these.

Anyway, that's off-topic and I'm most likely wrong, given there seems to be
nothing serious enough to damage gnupg's security.

Cheers,

Leo