From: Johannes Schindelin <Johannes.Schindelin@gmx.de> To: Markus Vervier <firstname.lastname@example.org> Cc: email@example.com Subject: Re: Covierty Integration / Improvement Date: Wed, 6 Apr 2022 00:17:12 +0200 (CEST) [thread overview] Message-ID: <nycvar.QRO.firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 2987 bytes --] Hi Markus, On Fri, 1 Apr 2022, Markus Vervier wrote: > Dear git developer team, > > X41 is processing the current RfP would you kindly provide a bit more context? This seems to come right out of left field. Is "RfP" a "Request for Proposals"? If so, I am not aware that the git developer team submitted one... > and some questions came up regarding the > improvement / integration of Coverity Scans for git and the estimation of the > required work: > > - Was there a special purpose for the Coverity integration (e.g. custom > queries for variant analysis or regression testing?) or did you try to > integrate it as a best practice / general security hygiene tool? There has been talk about integrating Coverity into our regular CI builds, but nothing actionable has materialized yet. Git for Windows has such a CI build, but it is currently broken due to a backwards-incompatible change in Coverity that will require a human to adjust the CI definition, which has not yet happened due to lack of time. > - Could you tell us more about the amount and types of false positives and > problems you've faced trying to eliminate them? This will help us to > understand the expectations / requirements for a successful integration of > Coverity. From the top of my head, I would estimate about 60-70% of the results to be false positives. As Junio pointed out, we do not consider memory to be leaked in one-shot processes where memory is allocated, once, in the equivalent of a `main()` function. Sure, we could add a slew of `free()` calls right before exiting the process, but that's kind of pointless. Another major source of false positives is our string data structure, which offers a small-ish static, read-only buffer to get started, but replaces that with something `malloc()`ed/`realloc()`ed as soon as the string is about to be manipulated. Yet Coverity insists that we're writing into a read-only buffer, and get out of bounds, which is simply not true. Similar issues are reported with our `strvec` data structure that has the same allocation pattern. Since the false positives outnumber the valid issues reported by Coverity, we have not been very eager to sift through new reports. The list of categories of false positives listed above is not exhaustive, of course, but combined with how cumbersome it is to get access to the reports (they cannot be viewed anonymously), you get an idea why we do not pay all that much attention to Coverity. > - Could we get access to a sample of the scan results? Sure, if you direct your web browser to https://scan.coverity.com/projects/git, there is a button "Add me to project". Ciao, Johannes > > Many Thanks > > Markus > -- > Markus Vervier (Managing Director) > X41 D-Sec GmbH, Dennewartstr. 25-27, D-52068 Aachen > T: +49 241 9809418-0, Fax: -9 > Unternehmenssitz: Aachen, Amtsgericht Aachen: HRB19989 > Geschäftsführer: Markus Vervier >
next prev parent reply other threads:[~2022-04-06 6:48 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-01 20:49 Markus Vervier 2022-04-03 21:36 ` Junio C Hamano 2022-04-03 23:16 ` Theodore Ts'o 2022-04-04 10:14 ` Ævar Arnfjörð Bjarmason 2022-04-05 22:22 ` Johannes Schindelin 2022-04-05 22:17 ` Johannes Schindelin [this message] 2022-04-06 15:08 ` Johannes Schindelin 2022-04-06 17:55 ` Theodore Ts'o 2022-04-06 20:20 ` Junio C Hamano 2022-04-07 11:49 ` Johannes Schindelin 2022-04-07 7:21 ` Markus Vervier 2022-04-07 11:58 ` Johannes Schindelin [not found] ` <CAJY0qZLwQJ_6Me1em4X6M=YJb0O2+7rSYeKisLFOGH7_BW3Lww@mail.gmail.com> [not found] ` <CAJY0qZJaBvwA19PN=Gm4c5gSVqYYBOoVwgF=1mZTNEjmXFSc7A@mail.gmail.com> 2022-05-10 17:46 ` Derek Zimmer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=nycvar.QRO.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Covierty Integration / Improvement' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).