Thanks for this outline, Mark. Some questions in line.

Mike

On Tue, Oct 11, 2022 at 6:13 AM Mark Thomas <ma...@apache.org> wrote:

> Roman - don't do anything yet.
>
> Commons folk, I suggest the following which is based on how we have
> oss-fuzz setup on Tomcat.
>
> 1. Create a Google account for fuzz-testing@c.a.o
> 2. Put the password for the account in the PMC private shared repo so
> any PMC member can access these reports.
>

If the dashboard doesn't support groups then maybe this is the only way.
Otherwise I think it would be very nice if we could use ASF committer info
or possibly github info since that often has mirrored groups of our
internal organizational structure.


> 3. Get Roman to add this account to the JXPath oss-fuzz project and the
> projects for any other Commons components they have set up
>

Maybe it makes sense to group all of the apache-commons-* projects under
the general apache-commons module at
https://github.com/google/oss-fuzz/tree/master/projects/
That module is the one that was initially set up, including compress and
imaging as mentioned by Matt S upthread.


> 4. Review the reports once we have access via fuzz-testing@c.a.o (I'll
> volunteer to help with this as I have some experience from Tomcat which
> should speed things up)
>

I would be happy to volunteer.


> 5. Ask the ASF security to get all CVEs allocated by Google to Apache
> Commons components transferred to the ASF (we can edit them once we have
> ownership)
> 6. Ask the ASF security team to contact Google to make sure that Google
> follows the CNA rules and stops allocating CVEs for projects outside of
> its scope.
>
> If there is agreement to this approach, I'll volunteer to get the things
> on the list above done. Depending on the number of issues, I may be
> asking for help with 4.
>
> Given this is all public, I don't see any need to use the security@c.a.o
> list unless we come across a valid, non-public issue.
>
> Mark
>
>
>
> On 11/10/2022 00:29, Roman Wagner wrote:
> > Hi Bruno, hi Eric,
> >
> > I think we've just missed the discussion that you want to get
> notifications
> > about Bug reports for all apache-commons projects integrated in oss-fuzz.
> > For that reason, we have tried to reach to the projects maintainers via
> > public issues for every new project during the onboarding. Since we are
> not
> > focusing only on apache commons software we are not familiar with your
> > internal process, however we are flexible to adopt. We are very
> interested
> > in any collaboration with maintainers if we are able to reach them. From
> > your discussion I suggest that we first of all give you access to all
> those
> > projects and later on merge those different oss-fuzz projects into one
> > project. Which email addresses should we add? In appache-commons there
> are
> > the following four:
> >
> > - fuzz-test...@commons.apache.org
> > - brunodepau...@gmail.com
> > - peteralfred...@gmail.com
> > - boa...@gmail.com
> >
> > Should I add all of them? Should I add any additional mail address?
> >
> > Best regards
> > Roman
> >
> > On Tue, Oct 11, 2022 at 12:13 AM Bruno Kinoshita <ki...@apache.org>
> wrote:
> >
> >> Hi Matt,
> >>
> >> I don't think this fuzz project should be making any of these issues
> >>> public unless they plan to donate some developers to fix the issues,
> >>> too. This is an ASF project, not some Google-sponsored OSS project
> >>> staffed with Google employees.
> >>>
> >>
> >> I agree. This was the reason for the apache-commons project with a
> >> different policy.
> >>
> >> In my opinion, the issue here is a company that profits from security
> >> testing services/software-as-service setting up oss-fuzz to send
> >> notifications to their internal team. Even though they say they tried to
> >> communicate with us, a delay in having a response should not mean they
> must
> >> make it public anyway.
> >>
> >> It would be fine (again, IMO) to bring those Commons components under
> the
> >> apache-commons oss-fuzz project, and remove the existing projects that
> do
> >> not notify anyone from the ASF. That way we would receive notifications
> and
> >> could take some action to fix it.
> >>
> >> Bruno
> >>
> >> On Tue, 11 Oct 2022 at 10:57, Matt Sicker <boa...@gmail.com> wrote:
> >>
> >>> I don't think this fuzz project should be making any of these issues
> >>> public unless they plan to donate some developers to fix the issues,
> >>> too. This is an ASF project, not some Google-sponsored OSS project
> >>> staffed with Google employees.
> >>>
> >>> On Mon, Oct 10, 2022 at 4:41 PM Bruno Kinoshita <ki...@apache.org>
> >> wrote:
> >>>>
> >>>> The JIRA issue linked appears to be one of those reported based on the
> >>>> existing CVE's that were generated for jxpath.
> >>>>
> >>>> I opened the CVE, and the link is to an oss-fuzz bug indeed:
> >>>> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47133
> >>>>
> >>>> If you look at the left side bar, there is a list of people notified
> of
> >>>> this issue. It should match what's in the project.yaml file I linked
> >>> above
> >>>> in GitHub oss-fuzz repository. As far as I know, that OSS Fuzz fuzzing
> >>>> issue was reported to those parties, but unfortunately didn't reach a
> >>>> developer in commons able to work following our security process to
> >>> tackle
> >>>> the issue and release a new version.
> >>>>
> >>>> -Bruno
> >>>>
> >>>> On Tue, 11 Oct 2022 at 10:36, Bruno Kinoshita <ki...@apache.org>
> >> wrote:
> >>>>
> >>>>> Hi Eric,
> >>>>>
> >>>>> As far as I know, there is no integration between issues found in OSS
> >>> Fuzz
> >>>>> and our JIRA. Issues reported in OSS Fuzz exist only there. And
> >>> security
> >>>>> issues shouldn't go to JIRA if possible (according to ASF's security
> >>>>> policies, I believe?).
> >>>>>
> >>>>> Here's the workflow I have been using for Commons Imaging:
> >>>>>
> >>>>>
> >>>>>     1. View issues
> >>>>>        1. Log in to oss-fuzz.com with my GitHub log in (there's a
> >>> Google
> >>>>>        one too). It recognizes that my email is authorized to view
> >>> oss-fuzz issues
> >>>>>        for the apache-commons project, so it shows the “Testcases”
> >> with
> >>> crashes
> >>>>>        for the fuzzer. OR
> >>>>>        2. Get the direct link to a Testcase from an email from
> >>>>>        2. Expand a Testcase
> >>>>>     3. Read the Stacktrace
> >>>>>     4. Download the Unminimized Testcase - this is the payload used
> >> for
> >>>>>     testing, in the case of Imaging this is normally a PNG, GIF, etc.
> >>> image
> >>>>>     file that was automatically generated by the fuzzer
> >>>>>     5. Test with Commons Imaging and other tools to validate the
> issue
> >>>>>     (e.g. GIMP, exiftool, etc)
> >>>>>        1. If I reproduce it locally, and identify as something that
> >>>>>        doesn't need to be fixed (e.g. a file with a thumbnail that
> >>> wants to
> >>>>>        allocate 10GB of memory in a 2GB JVM/server) then I can mark
> >> the
> >>> testcase
> >>>>>        as not security or fixed
> >>>>>        2. If I reproduce it locally and the issue is indeed a
> security
> >>>>>        issue, then I prepare a fix and work following the Apache
> >>> Commons Security
> >>>>>        guidelines: https://commons.apache.org/security.html
> >>>>>
> >>>>> This way OSS Fuzz issues contribute positively to the project,
> >>> identifying
> >>>>> issues I or other maintainers wouldn't have picked otherwise. We
> >>> follow the
> >>>>> Commons and ASF security process as best as we can as volunteers
> >> (i.e.
> >>>>> within a time frame we can allocate to work on this issue) to fix the
> >>> issue
> >>>>> and prepare a CVE if needed, cutting a new release.
> >>>>>
> >>>>> This is the complete process that I've used in Imaging. Not sure if
> >>> jxpath
> >>>>> must follow the same process, but I guess it would be something
> >>> similar, or
> >>>>> at least according to Commons & ASF security guidelines and
> >> processes.
> >>>>>
> >>>>> -Bruno
> >>>>>
> >>>>>
> >>>>> On Tue, 11 Oct 2022 at 10:25, Eric Bresie <ebre...@gmail.com> wrote:
> >>>>>
> >>>>>> Or is that this
> >>>>>>
> >>>
> >>
> https://issues.apache.org/jira/projects/JXPATH/issues/JXPATH-200?filter=allopenissues
> >>>>>>
> >>>>>> Get Outlook for iOS<https://aka.ms/o0ukef>
> >>>>>> ________________________________
> >>>>>> From: Eric Bresie <ebre...@gmail.com>
> >>>>>> Sent: Monday, October 10, 2022 4:22:42 PM
> >>>>>> To: Commons Developers List <dev@commons.apache.org>
> >>>>>> Subject: Re: [jxpath] reported CVE and path forward
> >>>>>>
> >>>>>> So then discussed here (1) (which assume is what’s being done here)
> >>> and
> >>>>>> bugs raised here (2)?  Has (2) been done yet?
> >>>>>>
> >>>>>>    1.
> >>> https://commons.apache.org/proper/commons-jxpath/mail-lists.html
> >>>>>>    2.
> >>>>>>
> >> https://commons.apache.org/proper/commons-jxpath/issue-tracking.html
> >>>>>>
> >>>>>>
> >>>>>> Get Outlook for iOS<https://aka.ms/o0ukef>
> >>>>>> ________________________________
> >>>>>> From: Bruno Kinoshita <ki...@apache.org>
> >>>>>> Sent: Monday, October 10, 2022 4:15:03 PM
> >>>>>> To: Commons Developers List <dev@commons.apache.org>
> >>>>>> Subject: Re: [jxpath] reported CVE and path forward
> >>>>>>
> >>>>>> Hi Eric,
> >>>>>>
> >>>>>> For my understanding, is oss-fuzz an open source project that is
> >>>>>> maintained
> >>>>>>> and managed by Google (and is not an Apache project) but is for
> >>> “fuzz
> >>>>>>> testing” with portion focused on Apache common products?
> >>>>>>>
> >>>>>>
> >>>>>> That's my understanding too, although I am not sure if it is
> >>> maintained
> >>>>>> and
> >>>>>> managed solely by Google. But you are correct in that oss-fuzz is
> >> not
> >>> an
> >>>>>> Apache project. It is an external service similar to GitHub Actions,
> >>>>>> Dependabot, Codecov, etc.
> >>>>>>
> >>>>>> So am I correct in saying run oss-fuzz against Apache-common, which
> >>> may
> >>>>>>> find problems in commons.  So any findings would be identified as
> >> a
> >>> bug
> >>>>>> and
> >>>>>>> fix as applicable?
> >>>>>>>
> >>>>>>
> >>>>>> That sounds correct to me.
> >>>>>>
> >>>>>> There is an apache-commons oss-fuzz project created in the oss-fuzz
> >>> GitHub
> >>>>>> repository. That becomes a project in the oss-fuzz web system which
> >> I
> >>> and
> >>>>>> other ASF members have access to - anyone from ASF can request
> >> access:
> >>>>>> https://oss-fuzz.com
> >>>>>>
> >>>>>> It was created some time ago, and Commons Imaging was one of the
> >> first
> >>>>>> included. We (ASF Commons) were involved in setting up that project,
> >>> so
> >>>>>> that someone from ASF would receive notifications (by being CC'ed in
> >>>>>> oss-fuzz notifications). We decided against using the dev-list, so
> >>> only
> >>>>>> those that volunteered at the time receive emails.
> >>>>>>
> >>>>>> I checked the GitHub repository today, and found other Commons
> >>> Components,
> >>>>>> that are not part of the apache-commons project, and that have the
> >>>>>> notifications configured to emails of a security company. So in this
> >>> case
> >>>>>> the findings in Commons repositories would be identified as a bug
> >> and
> >>>>>> report to that company, without - as far as I can tell - involvement
> >>> of
> >>>>>> ASF
> >>>>>> Commons devs.
> >>>>>>
> >>>>>> Hope that clarifies,
> >>>>>>
> >>>>>> Bruno
> >>>>>>
> >>>>>>
> >>>>>> On Tue, 11 Oct 2022 at 10:06, Eric Bresie <ebre...@gmail.com>
> >> wrote:
> >>>>>>
> >>>>>>> For my understanding, is oss-fuzz an open source project that is
> >>>>>>> maintained and managed by Google (and is not an Apache project)
> >> but
> >>> is
> >>>>>> for
> >>>>>>> “fuzz testing” with portion focused on Apache common products?
> >>>>>>>
> >>>>>>> So am I correct in saying run oss-fuzz against Apache-common,
> >> which
> >>> may
> >>>>>>> find problems in commons.  So any findings would be identified as
> >> a
> >>> bug
> >>>>>> and
> >>>>>>> fix as applicable?
> >>>>>>>
> >>>>>>>
> >>>>>>> Get Outlook for iOS<https://aka.ms/o0ukef>
> >>>>>>> ________________________________
> >>>>>>> From: Bruno Kinoshita <ki...@apache.org>
> >>>>>>> Sent: Monday, October 10, 2022 3:51:30 PM
> >>>>>>> To: Commons Developers List <dev@commons.apache.org>
> >>>>>>> Subject: Re: Re: [jxpath] reported CVE and path forward
> >>>>>>>
> >>>>>>> Hi Matt,
> >>>>>>>
> >>>>>>> I am also subscribed to oss-fuzz for Imaging.
> >>>>>>>
> >>>>>>> Looks like someone added jxpath to oss-fuzz here:
> >>>>>>> https://github.com/google/oss-fuzz/pull/7582
> >>>>>>>
> >>>>>>> The initial oss-fuzz for ASF was, if I recall correctly, all put
> >>> under a
> >>>>>>> single project:
> >>>>>>>
> >>> https://github.com/google/oss-fuzz/tree/master/projects/apache-commons
> >>>>>>>
> >>>>>>> If you go one level higher in that repository link, you will see
> >>> there
> >>>>>> are
> >>>>>>> now other projects in oss-fuzz for other Commons components.
> >>>>>>>
> >>>>>>> The apache-commons project (that contains Imaging, Compress, and
> >>>>>> Geometry)
> >>>>>>> had a custom policy, agreed in the mailing list and later with
> >>> someone
> >>>>>> that
> >>>>>>> maintained oss-fuzz, where ASF issues were not disclosed in 90
> >>> days, but
> >>>>>>> instead gave us more time to align the issues with our ASF
> >> process.
> >>>>>>>
> >>>>>>> I am not sure if these other projects follow similar policy, nor
> >> if
> >>> the
> >>>>>> ASF
> >>>>>>> developers are aware of the integration (I only keep an eye on
> >>>>>>> compress/imaging/geometry notifications from the apache-commons
> >>>>>> project).
> >>>>>>> Also not sure whether it's better to have everything in a single
> >>>>>> project in
> >>>>>>> oss-fuzz or in separate projects. I'm happy with Imaging being a
> >>> single
> >>>>>>> oss-fuzz project if needed, but I prefer to keep the policy of
> >>> giving a
> >>>>>>> longer time to review the issues. I try to review important issues
> >>>>>> quickly,
> >>>>>>> but the ones that I know are very low priority or won't be fixed
> >>> (e.g.
> >>>>>> OOM)
> >>>>>>> I leave for later.
> >>>>>>>
> >>>>>>> Cheers
> >>>>>>> Bruno
> >>>>>>>
> >>>>>>> On Tue, 11 Oct 2022 at 09:01, Matt Sicker <boa...@gmail.com>
> >> wrote:
> >>>>>>>
> >>>>>>>> I get emails about some of the Commons fuzzing things, but I was
> >>> only
> >>>>>>>> aware of it being enabled for compress and imaging.
> >>>>>>>>
> >>>>>>>> On Mon, Oct 10, 2022 at 1:37 PM Roman Wagner
> >>>>>>>> <wag...@code-intelligence.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Hi all,
> >>>>>>>>>
> >>>>>>>>> I am working for Code Intelligence we did our best to find a
> >>>>>> maintainer
> >>>>>>>> for
> >>>>>>>>> the oss-fuzz project. Unfortunately we've got no feedback
> >> until
> >>> now,
> >>>>>>> but
> >>>>>>>> It
> >>>>>>>>> seems to be an unmaintained project except for some typo fixes
> >>> since
> >>>>>>> some
> >>>>>>>>> years. I am not sure yet to which mailing list the bug report
> >>> was
> >>>>>> send
> >>>>>>>> to,
> >>>>>>>>> but I will check that information with the team.
> >>>>>>>>>
> >>>>>>>>> However, I am really happy that there is some interest in
> >>> fixing the
> >>>>>>>> RCE. I
> >>>>>>>>> have verified the vulnerability and for me it seems to be a
> >>> valid
> >>>>>>>>> RCE. @Mark Thomas should we continue to discuss further
> >> details
> >>> via
> >>>>>>>>> secur...@apache.org?
> >>>>>>>>>
> >>>>>>>>> Best regards
> >>>>>>>>> Roman
> >>>>>>>>
> >>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>> 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
>
>

Reply via email to