Hello everybody, two weeks ago Stefan Krah asked for a current Coverity scan report. Coverity has updated us to a new version with a new workflow. Before the update Coverity pulled the code from our version control system. However the latest version doesn't work that way. The code must be compiled with the Coverity tool chain, published to a public web server and then downloaded by Coverity. http://mail.python.org/pipermail/python-committers/2012-August/002134.html It's easy, doesn't take much effort and can easily be automated, but somebody has to do it. The process should also be placed on the Python infrastructure and I don't have access. Secondly somebody has to contact Coverity to apply for an upload account. I tried my user account without success. It be nice if we get Coverity scans up and running this week to check the upcoming release candidate for issues. Christian
On Mon, 03 Sep 2012 15:59:59 +0200 Christian Heimes <lists@cheimes.de> wrote:
You could ask infrastructure@python.org for an account on an existing machine (dinsdale perhaps, it looks much less loaded now that some services have been migrated). Regards Antoine. -- Software development and contracting: http://pro.pitrou.net
Am 03.09.2012 15:59, schrieb Christian Heimes:
It be nice if we get Coverity scans up and running this week to check the upcoming release candidate for issues.
Updates: - Noah has set up a VM for me on the PSF infrastructure. I've installed the Coverity tools, build dependencies of Python and a hg clone of the default branch. The instrumented coverage builds are working, too. - Brett has contacted Coverity to establish me as a second administrative contact besides him. Once it's done I'll request an upload account to submit the coverage data. I try to get everything in place by tomorrow so we have some time to check for bugs before the next RC is deployed. Stefan: Has Brett already requested an account for you or shall I request one for you? Christian
Am 05.09.2012 14:43, schrieb Christian Heimes:
I try to get everything in place by tomorrow so we have some time to check for bugs before the next RC is deployed.
The people at Coverity are even faster than I hoped. I'm now in the possession of the Project password which mean I can upload the builds and add new users. I've already added Stefan and uploaded an instrumented build successfully: Your request for analysis of Python has been completed. The results should be available now in the database: http://scan5.coverity.com:8080/ Have fun! Christian
And a thanks to Christian and Stefan for picking this up and running with it. I have not been the best keeper of this stuff as of late, but now that Christian, Stefan, and I all have admin access to the data we can spread the load so that none of us become a bottleneck. On Wed, Sep 5, 2012 at 12:50 PM, Stefan Krah <stefan@bytereef.org> wrote:
Am 05.09.2012 18:56, schrieb Brett Cannon:
You are welcome! Sharing is caring (or so) *g* Coverity has some new features like notification of new possible issue and build steps. We could create a new mailing list for coverity scan builds and results, The mailing list should be exclusive to core devs as the issues may be security relevant. Christian
Christian Heimes <lists@cheimes.de> wrote:
The mailing list would be nice especially if we could get the results in verbose text form, but I don't know if that's possible. BTW, do we keep all buffer overruns secret or can we post them on the tracker if it's an off-by-one and unlikely to be exploitable? Stefan Krah
Am 06.09.2012 10:59, schrieb Stefan Krah:
The mailing list would be nice especially if we could get the results in verbose text form, but I don't know if that's possible.
I've added my account to the notification list but I've not yet received a mail as no new issue was introduced. Coverity also sends an email for every successful or failed build. So far the mails end up in my inbox.
BTW, do we keep all buffer overruns secret or can we post them on the tracker if it's an off-by-one and unlikely to be exploitable?
I'd say use your best discretion. In the unlikely case that Coverity finds a buffer overflow that can be abused remotely we have to go through PSRT and publish security fix releases. At a first glance no bug looked that severe to me. IMHO it makes sense to define a workflow how we are going to handle Coverity issues. Each coverity issue has an identifier and can have information like an external reference and an action. I've seen that you have started to create bugs in our tracker. How about we mention the Coverity # in the bug and add a link to the bug in the "Ext. Reference" field of the Coverity issue and set the Action to "Claimed, being worked on". In case you got curious about Coverity I've created a screenshot for you http://imm.io/Duel . Christian
Christian Heimes <lists@cheimes.de> wrote:
That sounds good in principle. I'm only worried that for casual readers of either the commit messages or the tracker issues the importance of the Coverity tool might be overstated. After all, 99.99% of issues are either found by developers themselves or by gcc, Visual Studio, Valgrind, etc. It just occurred to me that for example we don't credit other tools in commit messages. That said, for users of the Coverity web interface it's clearly useful. Stefan Krah
Zitat von Stefan Krah <stefan@bytereef.org>:
I agree that Coverity doesn't need to be mentioned in commit message. We do cite tools occasionally, but in a negative way, such as "silence gcc warning", where the commit message and/or comment explains why some code is ugly for some non-obvious reason. Regards, Martin
Am 08.09.2012 11:35, schrieb Stefan Krah:
I'd like to avoid that two people create two bug tracker entries or work on the same issue at the same time. The CID (coverity id) also makes it easier to find the entry on the Coverity site. IMHO it's sufficient to mention the CID in the tracker entry. As Brett has said it's also nice to give credits, too. By the way I've automated the build and upload process. Every six hours the default branch is pulled from hg and a build is triggere when changes are detected. Christian
participants (5)
-
Antoine Pitrou
-
Brett Cannon
-
Christian Heimes
-
martin@v.loewis.de
-
Stefan Krah