git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Markus Vervier <markus.vervier@x41-dsec.de>
Cc: git@vger.kernel.org
Subject: Re: Covierty Integration / Improvement
Date: Wed, 6 Apr 2022 00:17:12 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2204052352030.379@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <10fd679a-eb94-5380-2070-699f1b56a7b1@x41-dsec.de>

[-- 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
>

  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.7.76.6.2204052352030.379@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=markus.vervier@x41-dsec.de \
    --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).