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 <meumertzh...@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 > <meumertzh...@code-intelligence.com> wrote: > > > > > > On Tue, Mar 9, 2021 at 11:16 PM sebb <seb...@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 <seb...@gmail.com> wrote: > > > > > > > > > > > > > > On Tue, 9 Mar 2021 at 21:38, Gary Gregory > > > > > > > <garydgreg...@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 <tcu...@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-unsubscr...@commons.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
