Am 03.09.2012 16:27, schrieb Antoine Pitrou:

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).

Thanks Antoine! I've contacted the infrastructure team. Christian

On Wed, Sep 5, 2012 at 8:43 AM, Christian Heimes wrote:

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?

I have not for no other reason than I had not thought about it.

Christian Heimes wrote:

I try to get everything in place by tomorrow so we have some time to check for bugs before the next RC is deployed.

Fantastic. Thanks for pushing this forward!

Stefan: Has Brett already requested an account for you or shall I request one for you?

Not yet, please do if it's no problem. Stefan Krah

Christian Heimes wrote:

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/

Thanks Christian, works perfectly! Stefan Krah

Am 05.09.2012 18:56, schrieb Brett Cannon:

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.

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

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

Zitat von Stefan Krah :

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.

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:

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.

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