Re: [COMPRESS] OSS-Fuzz integration

[sebb <se...@gmail.com>]

For the record: there is now a private mailing list fuzz-testing@commons

On Fri, 12 Mar 2021 at 14:00, sebb <se...@gmail.com> wrote:
>
> It might be possible to set up a dedicated mailing list just for these
> reports, privately archived.
> RMs could then be encouraged to check the list in the run-up to a
> release (or they could subscribe).
>
> If it turns out that the mail traffic is not too onerous, the mails
> could be redirected to security@.
>
> On Fri, 12 Mar 2021 at 07:26, Fabian Meumertzheim
> <me...@code-intelligence.com> wrote:
> >
> > If you don't want reports to get lost, but there is no suitable
> > mailing list, there is also the option to add multiple email addresses
> > (possibly private ones of individual contributors).
> > See https://google.github.io/oss-fuzz/getting-started/new-project-guide/#primary
> > for the details.
> > Changing the list of recipients requires a pull request to the
> > OSS-Fuzz repo, but the folks there are very responsive.
> >
> > On Wed, Mar 10, 2021 at 2:00 PM Fabian Meumertzheim
> > <me...@code-intelligence.com> wrote:
> > >
> > > > > On Tue, Mar 9, 2021 at 11:16 PM sebb <se...@gmail.com> wrote:
> > > > > >
> > > > > > How often will the tool be run?
> > > > > > How often does it need to be run?
> > > > >
> > > > > OSS-Fuzz runs its fuzzers continuously and will automatically pick up
> > > > > new project commits. I don't know its precise schedule, but I expect
> > > > > every project to be fuzzed at least a couple of hours a day.
> > > >
> > > > In which case, IMO we definitely do not want the reports automatically
> > > > appearing on any mailing list.
> > > >
> > > > Seems to me this is something that would be more appropriate to be
> > > > activated only in the run-up to a formal release.
> > >
> > > Note that fuzzing can take a lot of time (days) before it finds bugs.
> > > While most OSS-Fuzz projects don't do this, the integration for
> > > Commons Compress could be configured so that it only fuzzes e.g. the
> > > latest release candidate.
> > >
> > > > > Due to the nature of fuzzing, Jazzer findings will always at least be
> > > > > valid, reproducible bug reports (with details comparable to the
> > > > > manually filed https://issues.apache.org/jira/projects/COMPRESS/issues/COMPRESS-567).
> > > > > Of course, these could still be for a non-security issue such as an
> > > > > unexpected RuntimeException.
> > > >
> > > > What if there is a commit that does not fix the detected issue?
> > > > Will the same report be re-generated?
> > > >
> > > > If not, how do we know when the issue has been fixed?
> > >
> > > The infrastructure behind OSS-Fuzz, ClusterFuzz, automatically retests
> > > new revisions and verifies that a particular bug has been fixed before
> > > closing it. For more details, see:
> > > https://google.github.io/clusterfuzz/using-clusterfuzz/workflows/fixing-a-bug/
> > >
> > > > > > > On Tue, 9 Mar 2021 at 15:48, sebb <se...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, 9 Mar 2021 at 21:38, Gary Gregory <ga...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > What if we make the existing notification list private? Who uses that
> > > > > > > > > one and for what?
> > > > > > > >
> > > > > > > > Not a good idea, as the contents are appropriate to developers not on the PMC.
> > > > > > > >
> > > > > > > > > G
> > > > > > > > >
> > > > > > > > > On Tue, Mar 9, 2021 at 3:41 PM Torsten Curdt <tc...@vafer.org> wrote:
> > > > > > > > > >
> > > > > > > > > > > At least for Compress I see value in Fuzz testing.
> > > > > > > > > > > Any other opniions?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I totally see the value and it should go to a private list.
> > > > > > > > >
> > > > > > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org