[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 15 Sep 2012 13:47:02 -0400
From: "Robert B. Harris" <rs904c@...scape.net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Static analysis of John using Coverity
We'll I think there should be a plan to work on the jumbo and magnum's
bleeding and magnum's stable code and increase the quality of it.
This program can test for code quality, memory leaks, and many other code
issues.
Is anyone on list interested and have the time for this?
I'm willing to take the lead and see if the Coverity static analysis scanner
helps us find and fix issues. Or maybe magnum might want to do this?
We would need a group from this list to help on deciding if and how the code
should be fixed. Do we have any volunteers?
There are other analyzers as well... Coverity is supposed to have a low
false positive rate, so I think that might be a good program to start with
-Robert B. Harris from VA
-----Original Message-----
From: Solar Designer [mailto:solar@...nwall.com]
Sent: Thursday, September 13, 2012 7:15 PM
To: john-dev@...ts.openwall.com
Subject: Re: [john-dev] Static analysis of John using Coverity
Robert,
On Thu, Sep 13, 2012 at 03:44:48PM -0400, Robert B. Harris wrote:
> What do you think about taking advantage of the free (since we are Open
source) static analysis of John using Coverity software? This software
seems to have a pretty good reputation. It appears that Alex or someone he
designates, would submit the source code to their website below, and they
would generate a report that could be view by again, the people Alex
designates.
Personally, I don't need this at this time, except maybe to get a feel of
Coverity's current capabilities for its possible other uses. Maybe we
should run it on other/smaller Openwall programs, where, unlike in JtR, it
is more obvious what constitutes untrusted input. BTW, for JtR it could be
nice to specify this in some documentation file - after we decide on it, of
course.
Also, for JtR, I feel that only the core tree is worth such analysis
currently. Jumbo's code quality is too low. (The core tree's could be
improved as well, to be fair.) Well, maybe some of the positives will make
us identify and patch specific bugs... while keeping the overall quality
almost as low.
Overall, I don't mind someone else in here looking into this, indeed.
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
