On Wed, 4 Nov 2020 at 15:26, Alexander Bulekov <alx...@bu.edu> wrote: > If I understand correctly, this is analogous to what happens with > Coverity reports. Access to Coverity is closed (not sure if there is a > process to apply for access). It also seems that there is a push to fix > CID issues prior to new releases. Maybe a similar process can be used for > fuzzing?
Coverity is only closed in the sense that you have to request an account on the website. Anybody who's a QEMU developer can look at the reports. The attempt to fix CID issues works because: * Coverity reports a fairly small number of issues, so "fix them all" is relatively tractable, and then once you get down to "no outstanding issues" the only new ones that get found are for new changes to QEMU (not entirely true, but close enough) * Mostly issues are reported soon after the offending code goes into the tree, so it's often possible to quickly identify the patch that introduced the issue and ask the person who wrote that patch to fix the bug * Coverity reports are categorized by kind-of-failure, so it's easy to prioritize important stuff (buffer overflows) and leave less significant stuff (dead code) for later * Coverity's reports include the automated analysis of why Coverity thinks there's an issue -- this is not always right but it's a solid head start on "what's the bug here" compared to just having a repro case and an assertion-failure message * There's a set of people who care enough about Coverity reports to put the time in to fixing them... thanks -- PMM
