[COMPRESS] OSS-Fuzz integration

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[COMPRESS] OSS-Fuzz integration

Fabian Meumertzheim
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).

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

Fabian
https://code-intelligence.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Stefan Bodewig
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Fabian Meumertzheim
On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Stefan Bodewig
On 2021-03-07, Fabian Meumertzheim wrote:

> On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Matt Sicker
We could create another private list for static analysis alerts perhaps?

On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig <[hidden email]> wrote:

>
> On 2021-03-07, Fabian Meumertzheim wrote:
>
> > On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

garydgregory
This issue has popped as well WRT GitHub emails from Dependabot.

Gary

On Sun, Mar 7, 2021, 12:45 Matt Sicker <[hidden email]> wrote:

> We could create another private list for static analysis alerts perhaps?
>
> On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig <[hidden email]> wrote:
> >
> > On 2021-03-07, Fabian Meumertzheim wrote:
> >
> > > On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Stefan Bodewig
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 <[hidden email]> wrote:

>> We could create another private list for static analysis alerts perhaps?

>> On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig <[hidden email]> wrote:

>>> On 2021-03-07, Fabian Meumertzheim wrote:

>>>> On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig <[hidden email]>
>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]


>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Peter Lee-2
I think the security list is a good choice.

Lee
On 3 8 2021, at 2:55, Stefan Bodewig <[hidden email]> 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 <[hidden email]> wrote:
> >> We could create another private list for static analysis alerts perhaps?
> >> On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig <[hidden email]> wrote:
> >>> On 2021-03-07, Fabian Meumertzheim wrote:
> >>>> On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig <[hidden email]>
> >> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
>
>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

garydgregory
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 <[hidden email]> wrote:

> I think the security list is a good choice.
>
> Lee
> On 3 8 2021, at 2:55, Stefan Bodewig <[hidden email]> 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 <[hidden email]> wrote:
> > >> We could create another private list for static analysis alerts
> perhaps?
> > >> On Sun, 7 Mar 2021 at 03:51, Stefan Bodewig <[hidden email]>
> wrote:
> > >>> On 2021-03-07, Fabian Meumertzheim wrote:
> > >>>> On Sat, Mar 6, 2021 at 10:08 PM Stefan Bodewig <[hidden email]>
> > >> 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: [hidden email]
> > >>> For additional commands, e-mail: [hidden email]
> >
> >
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Stefan Bodewig
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

garydgregory
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Stefan Bodewig
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

garydgregory
On Tue, Mar 9, 2021, 13:10 Stefan Bodewig <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

garydgregory
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 <[hidden email]> wrote:

>
> On Tue, Mar 9, 2021, 13:10 Stefan Bodewig <[hidden email]> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Stefan Bodewig
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Torsten Curdt-3
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

garydgregory
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

sebb-2-2
On Tue, 9 Mar 2021 at 21:38, Gary Gregory <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

Matt Sicker
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 <[hidden email]> wrote:

>
> On Tue, 9 Mar 2021 at 21:38, Gary Gregory <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COMPRESS] OSS-Fuzz integration

sebb-2-2
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 <[hidden email]> 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 <[hidden email]> wrote:
> >
> > On Tue, 9 Mar 2021 at 21:38, Gary Gregory <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12