Re: [COMPRESS] OSS-Fuzz integration
For the record: there is now a private mailing list fuzz-testing@commons On Fri, 12 Mar 2021 at 14:00, sebb 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 > 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 > > wrote: > > > > > > > > On Tue, Mar 9, 2021 at 11:16 PM sebb 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 wrote: > > > > > > > > > > > > > > > > On Tue, 9 Mar 2021 at 21:38, Gary Gregory > > > > > > > > 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 > > > > > > > > > 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 > > > > > > > > > > > > >
Re: [COMPRESS] OSS-Fuzz integration
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 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 > wrote: > > > > > > On Tue, Mar 9, 2021 at 11:16 PM sebb 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 wrote: > > > > > > > > > > > > > > On Tue, 9 Mar 2021 at 21:38, Gary Gregory > > > > > > > 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 > > > > > > > > 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
Re: [COMPRESS] OSS-Fuzz integration
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 wrote: > > > > On Tue, Mar 9, 2021 at 11:16 PM sebb 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 wrote: > > > > > > > > > > > > On Tue, 9 Mar 2021 at 21:38, Gary Gregory > > > > > > 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 > > > > > > > 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
Re: [COMPRESS] OSS-Fuzz integration
> > On Tue, Mar 9, 2021 at 11:16 PM sebb 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 wrote: > > > > > > > > > > On Tue, 9 Mar 2021 at 21:38, Gary Gregory > > > > > 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 > > > > > > 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
Re: [COMPRESS] OSS-Fuzz integration
On Wed, 10 Mar 2021 at 07:13, Fabian Meumertzheim wrote: > > On Tue, Mar 9, 2021 at 11:16 PM sebb 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. > > > > On Tue, 9 Mar 2021 at 22:01, Matt Sicker wrote: > > > > > > Perhaps the output of this tool won't have nearly as much spam as > > > Dependabot et al? If so, we could just use the security list. > > > > > 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? > > > On Tue, 9 Mar 2021 at 15:48, sebb wrote: > > > > > > > > On Tue, 9 Mar 2021 at 21:38, Gary Gregory > > > > 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 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
Re: [COMPRESS] OSS-Fuzz integration
On Tue, Mar 9, 2021 at 11:16 PM sebb 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. > > On Tue, 9 Mar 2021 at 22:01, Matt Sicker wrote: > > > > Perhaps the output of this tool won't have nearly as much spam as > > Dependabot et al? If so, we could just use the security list. > > 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. > > On Tue, 9 Mar 2021 at 15:48, sebb wrote: > > > > > > On Tue, 9 Mar 2021 at 21:38, Gary Gregory 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 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
Re: [COMPRESS] OSS-Fuzz integration
How often will the tool be run? How often does it need to be run? On Tue, 9 Mar 2021 at 22:01, Matt Sicker wrote: > > Perhaps the output of this tool won't have nearly as much spam as > Dependabot et al? If so, we could just use the security list. > > On Tue, 9 Mar 2021 at 15:48, sebb wrote: > > > > On Tue, 9 Mar 2021 at 21:38, Gary Gregory 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 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
Re: [COMPRESS] OSS-Fuzz integration
Perhaps the output of this tool won't have nearly as much spam as Dependabot et al? If so, we could just use the security list. On Tue, 9 Mar 2021 at 15:48, sebb wrote: > > On Tue, 9 Mar 2021 at 21:38, Gary Gregory 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 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
Re: [COMPRESS] OSS-Fuzz integration
On Tue, 9 Mar 2021 at 21:38, Gary Gregory 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 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
Re: [COMPRESS] OSS-Fuzz integration
What if we make the existing notification list private? Who uses that one and for what? G On Tue, Mar 9, 2021 at 3:41 PM Torsten Curdt 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
Re: [COMPRESS] OSS-Fuzz integration
> 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.
Re: [COMPRESS] OSS-Fuzz integration
On 2021-03-09, Gary Gregory wrote: > A reminder that we can break our own builds by configuring maven plugins > like spotbugs, pmd, and so on. If we need to configure another plugin to > run in our builds to check for different errors, then let's consider that. Fuzz testing need compute power beyond what you want to provide via a local build. So I understand you prefer not to join OSS-Fuzz as a project. IMHO personal emails will not scale. What if I subscribe with my email address and disappear for six months? At least for Compress I see value in Fuzz testing. Any other opniions? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COMPRESS] OSS-Fuzz integration
A reminder that we can break our own builds by configuring maven plugins like spotbugs, pmd, and so on. If we need to configure another plugin to run in our builds to check for different errors, then let's consider that. Or any dev is free to do whatever outside of builds, but, that only leaves room for regressions from commit to commit unless a plugin fails a build. Gary On Tue, Mar 9, 2021, 13:27 Gary Gregory wrote: > > On Tue, Mar 9, 2021, 13:10 Stefan Bodewig wrote: > >> On 2021-03-08, Gary Gregory wrote: >> >> > Note that we already have FIVE mailing lists: >> >> > commits >> > dev >> > issues >> > notifications >> > user >> >> which are all public >> >> > PLUS, private and security. >> >> subscribers of which will probably not like to receive automated emails. >> >> > Do we really want a SIXTH? Can't this fit in one of the above? >> >> Which one do you suggest? >> > > None. A human should review this data and email security when appropriate. > I don't see why we have to be on the receiving of this; there a so many of > these types of tools out there, I don't why we need to focus on this one. > > Gary > > >> Cheers >> >> StefanOP >> >
Re: [COMPRESS] OSS-Fuzz integration
On Tue, Mar 9, 2021, 13:10 Stefan Bodewig wrote: > On 2021-03-08, Gary Gregory wrote: > > > Note that we already have FIVE mailing lists: > > > commits > > dev > > issues > > notifications > > user > > which are all public > > > PLUS, private and security. > > subscribers of which will probably not like to receive automated emails. > > > Do we really want a SIXTH? Can't this fit in one of the above? > > Which one do you suggest? > None. A human should review this data and email security when appropriate. I don't see why we have to be on the receiving of this; there a so many of these types of tools out there, I don't why we need to focus on this one. Gary > Cheers > > StefanOP >
Re: [COMPRESS] OSS-Fuzz integration
On 2021-03-08, Gary Gregory wrote: > Note that we already have FIVE mailing lists: > commits > dev > issues > notifications > user which are all public > PLUS, private and security. subscribers of which will probably not like to receive automated emails. > Do we really want a SIXTH? Can't this fit in one of the above? Which one do you suggest? Cheers Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COMPRESS] OSS-Fuzz integration
Note that we already have FIVE mailing lists: commits dev issues notifications user PLUS, private and security. Do we really want a SIXTH? Can't this fit in one of the above? Gary On Mon, Mar 8, 2021 at 12:43 PM Stefan Bodewig wrote: > > On 2021-03-08, Gary Gregory wrote: > > > Are we talking about a human sending emails to the security list or letting > > the actual tool loose on the list to possibly spam it with false positives? > > We are talking about a tool sending mails that (currently) is unable to > identify whether an issue it detects is security critical or not. > > I propose a new subscription moderated list so people can decide whether > they want to see the mails - and we don't leak sensitive information by > accident. Human beings subscribed to said list can then escalate to > security@ as necessary. > > Stefan > > - > 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
Re: [COMPRESS] OSS-Fuzz integration
On 2021-03-08, Gary Gregory wrote: > Are we talking about a human sending emails to the security list or letting > the actual tool loose on the list to possibly spam it with false positives? We are talking about a tool sending mails that (currently) is unable to identify whether an issue it detects is security critical or not. I propose a new subscription moderated list so people can decide whether they want to see the mails - and we don't leak sensitive information by accident. Human beings subscribed to said list can then escalate to security@ as necessary. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COMPRESS] OSS-Fuzz integration
Are we talking about a human sending emails to the security list or letting the actual tool loose on the list to possibly spam it with false positives? Gary On Mon, Mar 8, 2021, 02:56 Peter Lee wrote: > I think the security list is a good choice. > > Lee > On 3 8 2021, at 2:55, Stefan Bodewig wrote: > > On 2021-03-07, Gary Gregory wrote: > > > > > This issue has popped as well WRT GitHub emails from Dependabot. > > I don't think this is comparable. > > The fuzzer may find issues that can be exploited as DoS attacks, so the > > results probably should go to a subscription-moderated list IMHO. > > > > Stefan > > > Gary > > > On Sun, Mar 7, 2021, 12:45 Matt Sicker wrote: > > >> We could create another private list for static analysis alerts > perhaps? > > >> On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig > wrote: > > >>> On 2021-03-07, Fabian Meumertzheim wrote: > > On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig > > >> wrote: > > > > > OTOH I'm not sure I understand the requirements of OSS-Fuzz. I > haven't > > > read the docs only looked at the image of the process. Seeing a > > > Sheriffbot tracking deadlines makes the me very uncomfortable. I'm > a > > > volunteer and so are most others around here. > > > > The disclosure policy for OSS-Fuzz is detailed here: > > >> > https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/ > > Reports will become public after 90 days (plus a 14 day grace period > > if a patch is close to being released). > > > > >>> Well, 90 days would work for me. Let's hear whether others object. > > >>> Extending the deadline if it ends on a wekeend is the opposite of > what > > >>> I'd personally need, though :-) > > > > >> All I would need from you is a list of emails to which the > automated > > >> bug reports should go. The reports are usually directly > actionable as > > >> they include stack traces and minimized reproducers. > > > > > In general I'd think the notifications list of the Commons project > > >> would > > > be a the best fit. Of course the nature of the issues detected > could > > > lead to the fuzzer uncovering security critical bugs that we may > not > > > want to become public before a release fixing it has become > available. > > > > I am currently working on improving the automatic security/severity > > analysis of Java findings in OSS-Fuzz, which should help prioritize > > the security-relevant bugs (e.g. OoM, infinite loops) over the less > > important ones (e.g. undeclared exception). > > > > However, afaik the list of email recipients for a bug currently > can't > > depend on the security content of the bug, so it might be better to > > choose a private mailing list here. > > > > >>> I see. But I really wouldn't want to use the security list for > > >>> everything. Maybe somebody else got a good idea where to send > results? > > > > >>> Stefan > > >>> - > > >>> 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 > > > >
Re: [COMPRESS] OSS-Fuzz integration
I think the security list is a good choice. Lee On 3 8 2021, at 2:55, Stefan Bodewig wrote: > On 2021-03-07, Gary Gregory wrote: > > > This issue has popped as well WRT GitHub emails from Dependabot. > I don't think this is comparable. > The fuzzer may find issues that can be exploited as DoS attacks, so the > results probably should go to a subscription-moderated list IMHO. > > Stefan > > Gary > > On Sun, Mar 7, 2021, 12:45 Matt Sicker wrote: > >> We could create another private list for static analysis alerts perhaps? > >> On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig wrote: > >>> On 2021-03-07, Fabian Meumertzheim wrote: > On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig > >> wrote: > > > OTOH I'm not sure I understand the requirements of OSS-Fuzz. I haven't > > read the docs only looked at the image of the process. Seeing a > > Sheriffbot tracking deadlines makes the me very uncomfortable. I'm a > > volunteer and so are most others around here. > > The disclosure policy for OSS-Fuzz is detailed here: > >> https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/ > Reports will become public after 90 days (plus a 14 day grace period > if a patch is close to being released). > > >>> Well, 90 days would work for me. Let's hear whether others object. > >>> Extending the deadline if it ends on a wekeend is the opposite of what > >>> I'd personally need, though :-) > > >> All I would need from you is a list of emails to which the automated > >> bug reports should go. The reports are usually directly actionable as > >> they include stack traces and minimized reproducers. > > > In general I'd think the notifications list of the Commons project > >> would > > be a the best fit. Of course the nature of the issues detected could > > lead to the fuzzer uncovering security critical bugs that we may not > > want to become public before a release fixing it has become available. > > I am currently working on improving the automatic security/severity > analysis of Java findings in OSS-Fuzz, which should help prioritize > the security-relevant bugs (e.g. OoM, infinite loops) over the less > important ones (e.g. undeclared exception). > > However, afaik the list of email recipients for a bug currently can't > depend on the security content of the bug, so it might be better to > choose a private mailing list here. > > >>> I see. But I really wouldn't want to use the security list for > >>> everything. Maybe somebody else got a good idea where to send results? > > >>> Stefan > >>> - > >>> 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 >
Re: [COMPRESS] OSS-Fuzz integration
On 2021-03-07, Gary Gregory wrote: > This issue has popped as well WRT GitHub emails from Dependabot. I don't think this is comparable. The fuzzer may find issues that can be exploited as DoS attacks, so the results probably should go to a subscription-moderated list IMHO. Stefan > Gary > On Sun, Mar 7, 2021, 12:45 Matt Sicker wrote: >> We could create another private list for static analysis alerts perhaps? >> On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig wrote: >>> On 2021-03-07, Fabian Meumertzheim wrote: On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig >> wrote: > OTOH I'm not sure I understand the requirements of OSS-Fuzz. I haven't > read the docs only looked at the image of the process. Seeing a > Sheriffbot tracking deadlines makes the me very uncomfortable. I'm a > volunteer and so are most others around here. The disclosure policy for OSS-Fuzz is detailed here: >> https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/ Reports will become public after 90 days (plus a 14 day grace period if a patch is close to being released). >>> Well, 90 days would work for me. Let's hear whether others object. >>> Extending the deadline if it ends on a wekeend is the opposite of what >>> I'd personally need, though :-) >> All I would need from you is a list of emails to which the automated >> bug reports should go. The reports are usually directly actionable as >> they include stack traces and minimized reproducers. > In general I'd think the notifications list of the Commons project >> would > be a the best fit. Of course the nature of the issues detected could > lead to the fuzzer uncovering security critical bugs that we may not > want to become public before a release fixing it has become available. I am currently working on improving the automatic security/severity analysis of Java findings in OSS-Fuzz, which should help prioritize the security-relevant bugs (e.g. OoM, infinite loops) over the less important ones (e.g. undeclared exception). However, afaik the list of email recipients for a bug currently can't depend on the security content of the bug, so it might be better to choose a private mailing list here. >>> I see. But I really wouldn't want to use the security list for >>> everything. Maybe somebody else got a good idea where to send results? >>> Stefan >>> - >>> 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
Re: [COMPRESS] OSS-Fuzz integration
This issue has popped as well WRT GitHub emails from Dependabot. Gary On Sun, Mar 7, 2021, 12:45 Matt Sicker wrote: > We could create another private list for static analysis alerts perhaps? > > On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig wrote: > > > > On 2021-03-07, Fabian Meumertzheim wrote: > > > > > On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig > wrote: > > > > >> OTOH I'm not sure I understand the requirements of OSS-Fuzz. I haven't > > >> read the docs only looked at the image of the process. Seeing a > > >> Sheriffbot tracking deadlines makes the me very uncomfortable. I'm a > > >> volunteer and so are most others around here. > > > > > The disclosure policy for OSS-Fuzz is detailed here: > > > > https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/ > > > Reports will become public after 90 days (plus a 14 day grace period > > > if a patch is close to being released). > > > > Well, 90 days would work for me. Let's hear whether others object. > > > > Extending the deadline if it ends on a wekeend is the opposite of what > > I'd personally need, though :-) > > > > >>> All I would need from you is a list of emails to which the automated > > >>> bug reports should go. The reports are usually directly actionable as > > >>> they include stack traces and minimized reproducers. > > > > >> In general I'd think the notifications list of the Commons project > would > > >> be a the best fit. Of course the nature of the issues detected could > > >> lead to the fuzzer uncovering security critical bugs that we may not > > >> want to become public before a release fixing it has become available. > > > > > I am currently working on improving the automatic security/severity > > > analysis of Java findings in OSS-Fuzz, which should help prioritize > > > the security-relevant bugs (e.g. OoM, infinite loops) over the less > > > important ones (e.g. undeclared exception). > > > > > However, afaik the list of email recipients for a bug currently can't > > > depend on the security content of the bug, so it might be better to > > > choose a private mailing list here. > > > > I see. But I really wouldn't want to use the security list for > > everything. Maybe somebody else got a good idea where to send results? > > > > Stefan > > > > - > > 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 > >
Re: [COMPRESS] OSS-Fuzz integration
We could create another private list for static analysis alerts perhaps? On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig wrote: > > On 2021-03-07, Fabian Meumertzheim wrote: > > > On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig wrote: > > >> OTOH I'm not sure I understand the requirements of OSS-Fuzz. I haven't > >> read the docs only looked at the image of the process. Seeing a > >> Sheriffbot tracking deadlines makes the me very uncomfortable. I'm a > >> volunteer and so are most others around here. > > > The disclosure policy for OSS-Fuzz is detailed here: > > https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/ > > Reports will become public after 90 days (plus a 14 day grace period > > if a patch is close to being released). > > Well, 90 days would work for me. Let's hear whether others object. > > Extending the deadline if it ends on a wekeend is the opposite of what > I'd personally need, though :-) > > >>> All I would need from you is a list of emails to which the automated > >>> bug reports should go. The reports are usually directly actionable as > >>> they include stack traces and minimized reproducers. > > >> In general I'd think the notifications list of the Commons project would > >> be a the best fit. Of course the nature of the issues detected could > >> lead to the fuzzer uncovering security critical bugs that we may not > >> want to become public before a release fixing it has become available. > > > I am currently working on improving the automatic security/severity > > analysis of Java findings in OSS-Fuzz, which should help prioritize > > the security-relevant bugs (e.g. OoM, infinite loops) over the less > > important ones (e.g. undeclared exception). > > > However, afaik the list of email recipients for a bug currently can't > > depend on the security content of the bug, so it might be better to > > choose a private mailing list here. > > I see. But I really wouldn't want to use the security list for > everything. Maybe somebody else got a good idea where to send results? > > Stefan > > - > 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
Re: [COMPRESS] OSS-Fuzz integration
On 2021-03-07, Fabian Meumertzheim wrote: > On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig wrote: >> OTOH I'm not sure I understand the requirements of OSS-Fuzz. I haven't >> read the docs only looked at the image of the process. Seeing a >> Sheriffbot tracking deadlines makes the me very uncomfortable. I'm a >> volunteer and so are most others around here. > The disclosure policy for OSS-Fuzz is detailed here: > https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/ > Reports will become public after 90 days (plus a 14 day grace period > if a patch is close to being released). Well, 90 days would work for me. Let's hear whether others object. Extending the deadline if it ends on a wekeend is the opposite of what I'd personally need, though :-) >>> All I would need from you is a list of emails to which the automated >>> bug reports should go. The reports are usually directly actionable as >>> they include stack traces and minimized reproducers. >> In general I'd think the notifications list of the Commons project would >> be a the best fit. Of course the nature of the issues detected could >> lead to the fuzzer uncovering security critical bugs that we may not >> want to become public before a release fixing it has become available. > I am currently working on improving the automatic security/severity > analysis of Java findings in OSS-Fuzz, which should help prioritize > the security-relevant bugs (e.g. OoM, infinite loops) over the less > important ones (e.g. undeclared exception). > However, afaik the list of email recipients for a bug currently can't > depend on the security content of the bug, so it might be better to > choose a private mailing list here. I see. But I really wouldn't want to use the security list for everything. Maybe somebody else got a good idea where to send results? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COMPRESS] OSS-Fuzz integration
On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig wrote: > OTOH I'm not sure I understand the requirements of OSS-Fuzz. I haven't > read the docs only looked at the image of the process. Seeing a > Sheriffbot tracking deadlines makes the me very uncomfortable. I'm a > volunteer and so are most others around here. The disclosure policy for OSS-Fuzz is detailed here: https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/ Reports will become public after 90 days (plus a 14 day grace period if a patch is close to being released). > > > All I would need from you is a list of emails to which the automated > > bug reports should go. The reports are usually directly actionable as > > they include stack traces and minimized reproducers. > > In general I'd think the notifications list of the Commons project would > be a the best fit. Of course the nature of the issues detected could > lead to the fuzzer uncovering security critical bugs that we may not > want to become public before a release fixing it has become available. I am currently working on improving the automatic security/severity analysis of Java findings in OSS-Fuzz, which should help prioritize the security-relevant bugs (e.g. OoM, infinite loops) over the less important ones (e.g. undeclared exception). However, afaik the list of email recipients for a bug currently can't depend on the security content of the bug, so it might be better to choose a private mailing list here. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COMPRESS] OSS-Fuzz integration
On 2021-03-05, Fabian Meumertzheim wrote: > I am one of the maintainers of Jazzer > (https://github.com/CodeIntelligenceTesting/jazzer), a new open-source > fuzzer for JVM projects based on libFuzzer. > I have set up a few Commons projects for local fuzzing with Jazzer, > which lead to quite a few bug reports in Compress and other projects > (https://issues.apache.org/jira/browse/COMPRESS-569?jql=reporter%20%3D%20Meumertzheim). > While the majority of the bugs found are undeclared exceptions, this > approach also caught an infinite loop on a crafted 0.5KB .tar before > it could make it into a release (see COMPRESS-569). Yes, many thanks for that. > Jazzer is in the process of being integrated into OSS-Fuzz > (https://github.com/google/oss-fuzz) for continuous fuzzing on > Google-provided infrastructure (ClusterFuzz). > If you agree this is a good idea, I could set up Compress for fuzzing > on OSS-Fuzz. Also I'd like to point out issues detected by Maksim Zuev last spring and summer who used a different fuzzing tool. When reading archives or compressed streams, Compress consumes a lot of input and we are obviously not validating it in all cases as good as we should. Much of the code assumes it will only ever encounter valid archives. I believe fuzzing can help us finding places where we trust input too much. commons-codec or commons-imaging likely are in similar places. OTOH I'm not sure I understand the requirements of OSS-Fuzz. I haven't read the docs only looked at the image of the process. Seeing a Sheriffbot tracking deadlines makes the me very uncomfortable. I'm a volunteer and so are most others around here. > All I would need from you is a list of emails to which the automated > bug reports should go. The reports are usually directly actionable as > they include stack traces and minimized reproducers. In general I'd think the notifications list of the Commons project would be a the best fit. Of course the nature of the issues detected could lead to the fuzzer uncovering security critical bugs that we may not want to become public before a release fixing it has become available. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
