Re: [jxpath] reported CVE and path forward

[Roman Wagner]

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

Re: [jxpath] reported CVE and path forward

[Eric Bresie]

https://www.apache.org/security/

Get Outlook for iOS

From: Roman Wagner 
Sent: Monday, October 10, 2022 4:44:58 PM
To: dev@commons.apache.org 
Subject: RE: Re: [jxpath] reported CVE and path forward

Hi all,

I am working for Code Intelligence and we did our best to find a maintainer
for the oss-fuzz project Unfortunately, we've have failed and 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? We would like to support the fix process.

Best regards
Roman

Re: [jxpath] reported CVE and path forward

[Bruno Kinoshita]

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  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  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  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  wrote:
> > >
> > >> Or is that this
> > >>
> https://issues.apache.org/jira/projects/JXPATH/issues/JXPATH-200?filter=allopenissues
> > >>
> > >> Get Outlook for iOS
> > >> 
> > >> From: Eric Bresie 
> > >> Sent: Monday, October 10, 2022 4:22:42 PM
> > >> To: Commons Developers List 
> > >> 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.
> 

Re: [jxpath] reported CVE and path forward

[Matt Sicker]

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  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  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  wrote:
> >
> >> Or is that this
> >> https://issues.apache.org/jira/projects/JXPATH/issues/JXPATH-200?filter=allopenissues
> >>
> >> Get Outlook for iOS
> >> 
> >> From: Eric Bresie 
> >> Sent: Monday, October 10, 2022 4:22:42 PM
> >> To: Commons Developers List 
> >> 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
> >> 
> >> From: Bruno Kinoshita 
> >> Sent: Monday, October 10, 2022 4:15:03 PM
> >> To: Commons Developers List 
> >> 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?
> >> >
> >>
> >> 

RE: Re: [jxpath] reported CVE and path forward

[Roman Wagner]

Hi all,

I am working for Code Intelligence and we did our best to find a maintainer
for the oss-fuzz project Unfortunately, we've have failed and 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? We would like to support the fix process.

Best regards
Roman

Re: [jxpath] reported CVE and path forward

[Bruno Kinoshita]

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  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  wrote:
>
>> Or is that this
>> https://issues.apache.org/jira/projects/JXPATH/issues/JXPATH-200?filter=allopenissues
>>
>> Get Outlook for iOS
>> 
>> From: Eric Bresie 
>> Sent: Monday, October 10, 2022 4:22:42 PM
>> To: Commons Developers List 
>> 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
>> 
>> From: Bruno Kinoshita 
>> Sent: Monday, October 10, 2022 4:15:03 PM
>> To: Commons Developers List 
>> 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 

Re: [jxpath] reported CVE and path forward

[Bruno Kinoshita]

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  wrote:

> Or is that this
> https://issues.apache.org/jira/projects/JXPATH/issues/JXPATH-200?filter=allopenissues
>
> Get Outlook for iOS
> 
> From: Eric Bresie 
> Sent: Monday, October 10, 2022 4:22:42 PM
> To: Commons Developers List 
> 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
> 
> From: Bruno Kinoshita 
> Sent: Monday, October 10, 2022 4:15:03 PM
> To: Commons Developers List 
> 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  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 

Re: [jxpath] reported CVE and path forward

[Eric Bresie]

Or is that this 
https://issues.apache.org/jira/projects/JXPATH/issues/JXPATH-200?filter=allopenissues

Get Outlook for iOS

From: Eric Bresie 
Sent: Monday, October 10, 2022 4:22:42 PM
To: Commons Developers List 
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

From: Bruno Kinoshita 
Sent: Monday, October 10, 2022 4:15:03 PM
To: Commons Developers List 
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  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
> 
> From: Bruno Kinoshita 
> Sent: Monday, October 10, 2022 3:51:30 PM
> To: Commons Developers List 
> 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  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
> >  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 

Re: [jxpath] reported CVE and path forward

[Eric Bresie]

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

From: Bruno Kinoshita 
Sent: Monday, October 10, 2022 4:15:03 PM
To: Commons Developers List 
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  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
> 
> From: Bruno Kinoshita 
> Sent: Monday, October 10, 2022 3:51:30 PM
> To: Commons Developers List 
> 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  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
> >  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
> > 

Re: [jxpath] reported CVE and path forward

[Bruno Kinoshita]

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  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
> 
> From: Bruno Kinoshita 
> Sent: Monday, October 10, 2022 3:51:30 PM
> To: Commons Developers List 
> 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  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
> >  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
> >
> >
>

Re: [jxpath] reported CVE and path forward

[Eric Bresie]

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

From: Bruno Kinoshita 
Sent: Monday, October 10, 2022 3:51:30 PM
To: Commons Developers List 
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  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
>  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
>
>

Re: [jxpath] reported CVE and path forward

[Bruno Kinoshita]

Hi,

I commented in another thread about oss-fuzz and new components, maybe that
could be part of the issue here.

See that thread in the archives, or TL;DR: someone is adding more Commons
Components to oss-fuzz, directly as components instead of using the shared
apache-commons project. This latter project in oss-fuzz has a custom policy
for reporting issues that is aligned with the ASF process. No idea what is
the policy of these new oss-fuzz components, who created them, nor if
anyone in ASF is being notified (I monitor the project-commons issues,
especially those for imaging).

https://github.com/google/oss-fuzz/tree/master/projects/ (see
apache-commons)

I **think** the only people being notified of issues are those in the
project.yaml file, e.g.
https://github.com/google/oss-fuzz/blob/master/projects/apache-commons-jxpath/project.yaml

It looks like whoever set up that project in oss-fuzz decided to send
notifications only to @code-intelligence emails, which is not very
practical.

-Bruno

On Tue, 11 Oct 2022 at 04:40, Mark Thomas  wrote:

> Hmm.
>
> There are various red flags here that suggest to me that this issue is
> likely not valid.
>
> 1. The source is oss-fuzz. I have been dealing with oss-fuzz issues for
> Apache Tomcat and so far out of the 30+ issues raised (the majority
> marked as security relevant) not one of the issues was a vulnerability.
>
> 2. The CNA is Google. Google is not authorised to issue CVEs for ASF
> projects accept in strictly limited circumstances that do not apply here.
>
> 3. There is no record of CVE-2022-41852 on *ANY* ASF security list.
>
> The next steps are:
>
> - Identify the current JXPath maintainers (or some volunteers to clean
>up this mess)
>
> - Gain access to the details of the reports
>
> - Assess the reports
>
> - Invalidate / update the CVEs as required
>
> I don't see meaningful commits to the repo after 2015 so I suspect we'll
> be looking for volunteers.
>
> Mark
>
>
>
> On 10/10/2022 16:19, Mike Drob wrote:
> > Howdy folks,
> >
> > I recently saw that there was a reported CVE[1] for Apache JXPath that
> became public due to no response to the reporter over 90 days. I am
> uncertain if the reporter had tried reaching out to the appropriate
> security lists before-hand and was ignored, or failed to follow our
> established procedures. Regardless, the issue is now public.
> >
> > I have not personally verified the vulnerability, nor assessed the
> impact. NIST thinks it is a Big Deal, though, scoring it 9.8/10 [2]
> >
> > It is hard to assess impact since the project does not publish artifacts
> to maven central, but I'm also taking that as an indicator of low adoption
> at this point in time. Further, the project has not had a release since
> 2015. There has been very limited mailing list activity, and the last 5
> years of commits have only been typo/comment fixes.
> >
> > If there is no community around it, is there a path to retirement? What
> are the next steps?
> >
> > Thanks,
> > Mike
> >
> > [1]: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47133
> > [2]: https://nvd.nist.gov/vuln/detail/CVE-2022-41852
> >
> > -
> > 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: Re: [jxpath] reported CVE and path forward

[Bruno Kinoshita]

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

Re: [VOTE][RC1] Release Commons RNG 1.5

[Bruno Kinoshita]

(I mean, to customize RNG's CONTRIBUTING.md to add that info, not the
templated file from the parent or release-plugin)

On Tue, 11 Oct 2022 at 09:37, Bruno Kinoshita  wrote:

> Hi Alex,
>
> The updated changes report looks great!
>
> The Unit Tests [2] looks really useful to new contributors. I think our
> CONTRIBUTING.md files are generated automatically, but perhaps there's a
> way to add a link there to the developers.html page some day?
>
> Cheers
> Bruno
>
> On Tue, 11 Oct 2022 at 01:53, Alex Herbert 
> wrote:
>
>> On Mon, 10 Oct 2022 at 09:22, Alex Herbert 
>> wrote:
>> >
>> >
>> > On Mon, 10 Oct 2022 at 08:26, Bruno Kinoshita  wrote:
>> >>
>> >>
>> >> Changes report
>> >> look OK too, confirmed the Java version in the description. The text
>> could
>> >> be probably trimmed a little (see the changes-report.html in the parent
>> >> site), but not a blocker.
>> >>
>>
>> I have updated the changes.xml to simplify the description. The new
>> changes report is now live here [1].
>>
>> A new paragraph has been added to the developer guide to capture the
>> previous text regarding the configuration of the surefire plugin
>> (under 'Unit Tests' [2]).
>>
>> The user guide contains all the other information about the various
>> modules: the lack of compatibility for the examples, and the potential
>> to block direct usage of the core module using JPMS [3]; and the
>> behavioural compatibility of number generation [4].
>>
>> Alex
>>
>> [1] https://commons.apache.org/proper/commons-rng/changes-report.html
>> [2]
>> https://commons.apache.org/proper/commons-rng/developers.html#Unit_Tests
>> [3]
>> https://commons.apache.org/proper/commons-rng/userguide/rng.html#a1._Purpose
>> [4]
>> https://commons.apache.org/proper/commons-rng/userguide/rng.html#a7._Release_compatibility
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [VOTE][RC1] Release Commons RNG 1.5

[Bruno Kinoshita]

Hi Alex,

The updated changes report looks great!

The Unit Tests [2] looks really useful to new contributors. I think our
CONTRIBUTING.md files are generated automatically, but perhaps there's a
way to add a link there to the developers.html page some day?

Cheers
Bruno

On Tue, 11 Oct 2022 at 01:53, Alex Herbert  wrote:

> On Mon, 10 Oct 2022 at 09:22, Alex Herbert 
> wrote:
> >
> >
> > On Mon, 10 Oct 2022 at 08:26, Bruno Kinoshita  wrote:
> >>
> >>
> >> Changes report
> >> look OK too, confirmed the Java version in the description. The text
> could
> >> be probably trimmed a little (see the changes-report.html in the parent
> >> site), but not a blocker.
> >>
>
> I have updated the changes.xml to simplify the description. The new
> changes report is now live here [1].
>
> A new paragraph has been added to the developer guide to capture the
> previous text regarding the configuration of the surefire plugin
> (under 'Unit Tests' [2]).
>
> The user guide contains all the other information about the various
> modules: the lack of compatibility for the examples, and the potential
> to block direct usage of the core module using JPMS [3]; and the
> behavioural compatibility of number generation [4].
>
> Alex
>
> [1] https://commons.apache.org/proper/commons-rng/changes-report.html
> [2]
> https://commons.apache.org/proper/commons-rng/developers.html#Unit_Tests
> [3]
> https://commons.apache.org/proper/commons-rng/userguide/rng.html#a1._Purpose
> [4]
> https://commons.apache.org/proper/commons-rng/userguide/rng.html#a7._Release_compatibility
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Re: [jxpath] reported CVE and path forward

[Matt Sicker]

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

RE: Re: [jxpath] reported CVE and path forward

[Roman Wagner]

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

Re: [jxpath] reported CVE and path forward

[Mark Thomas]

Hmm.

There are various red flags here that suggest to me that this issue is 
likely not valid.


1. The source is oss-fuzz. I have been dealing with oss-fuzz issues for 
Apache Tomcat and so far out of the 30+ issues raised (the majority 
marked as security relevant) not one of the issues was a vulnerability.


2. The CNA is Google. Google is not authorised to issue CVEs for ASF 
projects accept in strictly limited circumstances that do not apply here.


3. There is no record of CVE-2022-41852 on *ANY* ASF security list.

The next steps are:

- Identify the current JXPath maintainers (or some volunteers to clean
  up this mess)

- Gain access to the details of the reports

- Assess the reports

- Invalidate / update the CVEs as required

I don't see meaningful commits to the repo after 2015 so I suspect we'll 
be looking for volunteers.


Mark



On 10/10/2022 16:19, Mike Drob wrote:

Howdy folks,

I recently saw that there was a reported CVE[1] for Apache JXPath that became 
public due to no response to the reporter over 90 days. I am uncertain if the 
reporter had tried reaching out to the appropriate security lists before-hand 
and was ignored, or failed to follow our established procedures. Regardless, 
the issue is now public.

I have not personally verified the vulnerability, nor assessed the impact. NIST 
thinks it is a Big Deal, though, scoring it 9.8/10 [2]

It is hard to assess impact since the project does not publish artifacts to 
maven central, but I'm also taking that as an indicator of low adoption at this 
point in time. Further, the project has not had a release since 2015. There has 
been very limited mailing list activity, and the last 5 years of commits have 
only been typo/comment fixes.

If there is no community around it, is there a path to retirement? What are the 
next steps?

Thanks,
Mike

[1]: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47133
[2]: https://nvd.nist.gov/vuln/detail/CVE-2022-41852

-
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

[jxpath] reported CVE and path forward

[Mike Drob]

Howdy folks,

I recently saw that there was a reported CVE[1] for Apache JXPath that became 
public due to no response to the reporter over 90 days. I am uncertain if the 
reporter had tried reaching out to the appropriate security lists before-hand 
and was ignored, or failed to follow our established procedures. Regardless, 
the issue is now public.

I have not personally verified the vulnerability, nor assessed the impact. NIST 
thinks it is a Big Deal, though, scoring it 9.8/10 [2]

It is hard to assess impact since the project does not publish artifacts to 
maven central, but I'm also taking that as an indicator of low adoption at this 
point in time. Further, the project has not had a release since 2015. There has 
been very limited mailing list activity, and the last 5 years of commits have 
only been typo/comment fixes.

If there is no community around it, is there a path to retirement? What are the 
next steps?

Thanks,
Mike

[1]: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47133
[2]: https://nvd.nist.gov/vuln/detail/CVE-2022-41852

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

[ANNOUNCEMENT] Commons Daemon 1.3.2 Released

[Mark Thomas]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Daemon 1.3.2.

The Apache Commons Daemon software library provides a generic Daemon
(unix) or Service (Windows) wrapper for Java code.

Version 1.3.2 is a bugfix release.

A full list of changes can be found at
https://commons.apache.org/proper/commons-daemon/changes-report.html

Source and binary distributions are available for download from the
Apache Commons download site:

https://commons.apache.org/proper/commons-daemon/download_daemon.cgi

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on Commons Daemon, including
instructions on how to submit bug reports, patches, or suggestions for
improvement, see the Apache Commons Daemon website:

https://commons.apache.org/proper/commons-daemon/

Mark
on behalf of the Apache Commons community

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

Re: [VOTE][RC1] Release Commons RNG 1.5

[Alex Herbert]

On Mon, 10 Oct 2022 at 09:22, Alex Herbert  wrote:
>
>
> On Mon, 10 Oct 2022 at 08:26, Bruno Kinoshita  wrote:
>>
>>
>> Changes report
>> look OK too, confirmed the Java version in the description. The text could
>> be probably trimmed a little (see the changes-report.html in the parent
>> site), but not a blocker.
>>

I have updated the changes.xml to simplify the description. The new
changes report is now live here [1].

A new paragraph has been added to the developer guide to capture the
previous text regarding the configuration of the surefire plugin
(under 'Unit Tests' [2]).

The user guide contains all the other information about the various
modules: the lack of compatibility for the examples, and the potential
to block direct usage of the core module using JPMS [3]; and the
behavioural compatibility of number generation [4].

Alex

[1] https://commons.apache.org/proper/commons-rng/changes-report.html
[2] https://commons.apache.org/proper/commons-rng/developers.html#Unit_Tests
[3] https://commons.apache.org/proper/commons-rng/userguide/rng.html#a1._Purpose
[4] 
https://commons.apache.org/proper/commons-rng/userguide/rng.html#a7._Release_compatibility

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

[VOTE][RESULT] Release Apache Commons Daemon 1.3.2 based on RC1

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, linow, ggregory

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


On 05/10/2022 15:36, Mark Thomas wrote:
We have fixed a few bugs since Apache Commons Daemon 1.3.1 was released, 
so I would like to release Apache Commons Daemon 1.3.2.


Apache Commons Daemon 1.3.2 RC1 is available for review here:
     https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.2-RC1 
(svn revision 57178)


The Git tag commons-daemon-1.3.2-RC1 commit for this RC is 
4189f2798f20180ea9f36c00bb5a05702971ba95 which you can browse here:


https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=4189f2798f20180ea9f36c00bb5a05702971ba95
You may checkout this tag using:
     git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.2-RC1 commons-daemon-1.3.2-RC1


Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1598/commons-daemon/commons-daemon/1.3.2/

These are the artifacts and their hashes:
commons-dameon-1.3.2-bin-windows.zip=4a4779629b76e5c7fb7885af51f0468c26ca958e6a243b60787c1576529fed48f0ec5b257ef5fcd71e48de8625d384aa27391e74e0ae4b43b0e7b3dbe8ca3d78
commons-daemon-1.3.2-bin.tar.gz=be2677b352cfff99ba4447468757136416a9477eadb61ec8b35e2fb72fadd40e7405f0dfc57e265957a938ff4e37f8814d731b1bf5893191f1104b0101017eb5
commons-daemon-1.3.2-bin.zip=130d658e09cd5a4eb82a175354ae18ad2ddd62e74fc48a661e6ce2fa08c294ae8d0cbc42ae11708284c46feae600e9c10989723035308d4dfa458bd919bfb1ec
commons-daemon-1.3.2-cyclonedx.json=c75beb453a4930367ce29d621bcf16a7e23f8c5f19bd6ff2f6515a0d27650424e03fdd4340a50e1bb4bfd17a2e62b8005367add17a384f2c2a7d282c20695797
commons-daemon-1.3.2-cyclonedx.xml=d407f88a5321297712e5d35554808caba4b9818cb7d22cd5996cc984b22146df02506814d03434e8afafbdc4e4a578c7075257c39d7d97b526811454c6bf0cf7
commons-daemon-1.3.2-javadoc.jar=7921b2bc5bf200c25506c5f57920322c29f7a60b8568dc7ab858cb952f2a21179720a8428d4ee3a752bceb8b9ac5096c6de8953aafac9b01e7c9832e46495861
commons-daemon-1.3.2-native-src.tar.gz=9908858ebe7e08873a0d1a83c88f78ca6eccacab24bf5fd2980f91df128d0c3407fd68351ea0736214f6dc758f8451b0e0b1fa7ccaf593479659c7c1d3acbf95
commons-daemon-1.3.2-native-src.zip=264f0ae6378afb1ec78cd518dde054f26c03a10ac3330c4da8829c5774c521a4ca4b1981e068a98913c73dc8396210062985fdcc55bd8415238afb2d5ab515af
commons-daemon-1.3.2-sources.jar=5f23cec53458818ea55572f83d93ebe1573de3371707090a5ff42e3dda60cd81387fa74d8fbc3999cab8a2394a0d1aadf5023377dffab1e5c1a9fa1b4de78b36
commons-daemon-1.3.2-src.tar.gz=241f3b15ef2a5e11cf802adef8c5e07d417a0c614188123db197b76154ed6ef6fc5dfaa7acff3bfac067b1b7978c3e0674bba2efc776305a2ab28a23be1c7f89
commons-daemon-1.3.2-src.zip=0f15f9277691cc259171ef20139fcfd8d4039da1ddc9a45aed0870d6ed6e3c78aacc10a535cc05c28ac50c9beb1b47280435b0ab339915e28f4aeda5087e5f0a
commons-dameon-1.3.2.spdx.rdf.xml=b80766a716e02d53b1a1a674653280bb4bf516b111ab760819ed5bc240562d66161299bca2533ccfd20ab97560da8f6de55387b5ef94cac9cbf259b1765e3b90




Details of changes since 1.3.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.2-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/daemon/1.3.2-RC1/site/changes-report.html


KEYS:
   https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

Thank you,

Mark Thomas,
Release Manager (using key 10C01C5A2F6059E7)




For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-daemon.git 
--branch commons-daemon-1.3.2-RC1 commons-daemon-1.3.2-RC1

cd commons-daemon-1.3.2-RC1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which 
you then must check.


mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page which 
you then must check.


mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page 
which you then must check.


mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the Maven and Java version produced by -V in your VOTE 
reply.

To gather OS information from a command line:
Windows: ver
Linux: uname -a

5) Build the site for a single module project

Note: Some plugins require the components to be installed instead of 
packaged.


mvn site
Check the 

[VOTE][RESULT] Release Commons RNG 1.5 based on RC1

[Alex Herbert]

This vote passes with the following votes:

+1: Gilles Sadowski (binding)
+1: Bruno Kinoshita (binding)
+1: Alex Herbert (binding)

Thank you to the reviewers. I will proceed with the release promotion.

Alex

Re: [VOTE][RC1] Release Commons RNG 1.5

[Alex Herbert]

On Mon, 10 Oct 2022 at 08:26, Bruno Kinoshita  wrote:

>
> Changes report
> look OK too, confirmed the Java version in the description. The text could
> be probably trimmed a little (see the changes-report.html in the parent
> site), but not a blocker.
>
>
Thanks Bruno.

For the description there is a lot of detail there. Note it does read
better in the release notes as it is formatted. In the changes report the
new lines are lost and the text is a single paragraph that is hard to read.

If this text is reduced then we should capture it elsewhere.
The description of the module architecture is duplicated in the user guide;
the configuration of the surefire plugin is not recorded anywhere else but
this is something to concern developers and not end users. I can move this
to the 'Developer guide' (see /commons-rng/developers.html).

Thus the changes description would be more like:

"This is a minor release of Apache Commons RNG, containing a few new
features and performance improvements (requires java 8)"

Alex

Re: [VOTE][RC1] Release Commons RNG 1.5

[Bruno Kinoshita]

   [x] +1 Release these artifacts

Built from tag successfully running `mvn clean install site` on

Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
Maven home: /opt/apache-maven-3.8.5
Java version: 17.0.4, vendor: Private Build, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-48-generic", arch: "amd64", family:
"unix"

Manually inspected tar.gz/zip files from binaries and source folders, in
the dist area. Everything looks OK. Signatures look OK too. Changes report
look OK too, confirmed the Java version in the description. The text could
be probably trimmed a little (see the changes-report.html in the parent
site), but not a blocker.

Forgot that it was a multi-module, so built it again with `mvn clean
package site site:stage -Pcommons-rng-examples'`. Site reports look good
(first time seeing a revapi report I think? It looks nice! Maybe they could
use a color that was not read for changes like adding a static field to a
class and leave removals and backward incompatible in a warmer color).
Impressed by the Jacoco reports too, great coverage.

Also had a very brief look at the Maven repository and everything seems to
be OK (expected files are present, non-empty; didn't have time to check
signatures of maven staged repo, sorry).

Thanks!
Bruno

On Mon, 10 Oct 2022 at 19:42, Bruno Kinoshita  wrote:

> I have 20 mins before a quick dinner and meeting. Cloning the repository
> now.
>
> On Mon, 10 Oct 2022 at 19:38, Alex Herbert  wrote:
>
>> Can I get another PMC vote for this please?
>>
>> Thanks,
>>
>> Alex
>>
>> On Wed, 5 Oct 2022 at 11:25, Alex Herbert  wrote:
>>
>> > We have fixed quite a few bugs and added some significant enhancements
>> > since Apache Commons RNG 1.4 was released, so I would like to release
>> > Apache Commons RNG 1.5.
>> >
>> > Apache Commons RNG 1.5 RC1 is available for review here:
>> > https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1 (svn
>> > revision 57177)
>> > https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/
>> >
>> > The Git tag commit for this RC is commons-rng-1.5-RC1 which you can
>> browse
>> > here:
>> >
>> >
>> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=commons-rng-1.5-RC1
>> >
>> > You may checkout this tag using:
>> > git clone https://gitbox.apache.org/repos/asf/commons-rng.git
>> > --branch commons-rng-1.5-RC1 commons-rng-1.5-RC1
>> > (signature can be checked from git using 'git tag -v
>> commons-rng-1.5-RC1')
>> >
>> > Maven artifacts are here:
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapachecommons-1596/org/apache/commons/
>> >
>> > These are the artifacts and their hashes:
>> >
>> > #Release SHA-512s
>> > #Tue Oct 04 13:00:24 BST 2022
>> >
>> >
>> commons-rng-1.5-bin.tar.gz=9e98092cb123a1873cc4ab05ebd87681b9f5fe171ad53cd00488c33e0ab2c7fb8a0bdd9c903a3bde7bc2e4f4035b07cf223b0d921e35d00fcea226ec16f86b5c
>> >
>> >
>> commons-rng-1.5-bin.zip=ad01629da0ef089641c4a7a8fed8e2dd9f1ed0fec3e9cc6fd19df22e0516bc8c1a4699a8d2104b5878a13ad9fbec724b85ca0a71c1e3027673cbcab8a5911b30
>> >
>> >
>> commons-rng-1.5-src.tar.gz=7fdfcd9ee43ac51f73eb6781d8fae7f313bf20658af84383ff791779def56c690458b99f2e996ce7fec8588db3218f23eea6dc6c2ff7d692f4209b78eb4b4dd8
>> >
>> >
>> commons-rng-1.5-src.zip=e1624601d449eecca660839b592c4deb7386ef77a09d613002e8220149f244cbb5bc70c08100fe27eb0d448efea7aef8ac1ebe26f416d846ba3bccd4f43d82e5
>> >
>> > Signatures may be validated on a system supporting a bash unix shell by
>> > executing:
>> > svn co https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1/
>> > cd 1.5-RC1
>> > chmod +x ./signature-validator.sh
>> > for m in client-api core simple sampling bom; do
>> > ./signature-validator.sh
>> >
>> https://repository.apache.org/content/repositories/orgapachecommons-1596/org/apache/commons/commons-rng-${m}/1.5/
>> ;
>> > done
>> >
>> > The source code contains examples that are not part of the public API.
>> > These examples contain Java 11 modules and are enabled using a profile
>> (see
>> > below).
>> >
>> > Note: Testing randomness using statistical thresholds results in
>> failures
>> > at a given probability. The 'maven-surefire-plugin' is configured to
>> re-run
>> > tests that fail, and pass the build if they succeed within the allotted
>> > number of reruns (the test will be marked as 'flaky' in the report).
>> >
>> > I have tested this with 'mvn clean install' using:
>> >
>> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
>> > Maven home: /usr/local/apache-maven-3
>> > Java version: 1.8.0_333, vendor: Oracle Corporation, runtime:
>> > /usr/lib/jvm/jdk1.8.0_333/jre
>> > Default locale: en_GB, platform encoding: UTF-8
>> > OS name: "linux", version: "4.15.0-193-generic", arch: "amd64", family:
>> > "unix"
>> >
>> > I have tested this with 'mvn clean package site site:stage
>> > -Pcommons-rng-examples' using:
>> >
>> > Apache Maven 3.8.6 

Re: [VOTE][RC1] Release Commons RNG 1.5

[Bruno Kinoshita]

I have 20 mins before a quick dinner and meeting. Cloning the repository
now.

On Mon, 10 Oct 2022 at 19:38, Alex Herbert  wrote:

> Can I get another PMC vote for this please?
>
> Thanks,
>
> Alex
>
> On Wed, 5 Oct 2022 at 11:25, Alex Herbert  wrote:
>
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons RNG 1.4 was released, so I would like to release
> > Apache Commons RNG 1.5.
> >
> > Apache Commons RNG 1.5 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1 (svn
> > revision 57177)
> > https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/
> >
> > The Git tag commit for this RC is commons-rng-1.5-RC1 which you can
> browse
> > here:
> >
> >
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=commons-rng-1.5-RC1
> >
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-rng.git
> > --branch commons-rng-1.5-RC1 commons-rng-1.5-RC1
> > (signature can be checked from git using 'git tag -v
> commons-rng-1.5-RC1')
> >
> > Maven artifacts are here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1596/org/apache/commons/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Tue Oct 04 13:00:24 BST 2022
> >
> >
> commons-rng-1.5-bin.tar.gz=9e98092cb123a1873cc4ab05ebd87681b9f5fe171ad53cd00488c33e0ab2c7fb8a0bdd9c903a3bde7bc2e4f4035b07cf223b0d921e35d00fcea226ec16f86b5c
> >
> >
> commons-rng-1.5-bin.zip=ad01629da0ef089641c4a7a8fed8e2dd9f1ed0fec3e9cc6fd19df22e0516bc8c1a4699a8d2104b5878a13ad9fbec724b85ca0a71c1e3027673cbcab8a5911b30
> >
> >
> commons-rng-1.5-src.tar.gz=7fdfcd9ee43ac51f73eb6781d8fae7f313bf20658af84383ff791779def56c690458b99f2e996ce7fec8588db3218f23eea6dc6c2ff7d692f4209b78eb4b4dd8
> >
> >
> commons-rng-1.5-src.zip=e1624601d449eecca660839b592c4deb7386ef77a09d613002e8220149f244cbb5bc70c08100fe27eb0d448efea7aef8ac1ebe26f416d846ba3bccd4f43d82e5
> >
> > Signatures may be validated on a system supporting a bash unix shell by
> > executing:
> > svn co https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1/
> > cd 1.5-RC1
> > chmod +x ./signature-validator.sh
> > for m in client-api core simple sampling bom; do
> > ./signature-validator.sh
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1596/org/apache/commons/commons-rng-${m}/1.5/
> ;
> > done
> >
> > The source code contains examples that are not part of the public API.
> > These examples contain Java 11 modules and are enabled using a profile
> (see
> > below).
> >
> > Note: Testing randomness using statistical thresholds results in failures
> > at a given probability. The 'maven-surefire-plugin' is configured to
> re-run
> > tests that fail, and pass the build if they succeed within the allotted
> > number of reruns (the test will be marked as 'flaky' in the report).
> >
> > I have tested this with 'mvn clean install' using:
> >
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/apache-maven-3
> > Java version: 1.8.0_333, vendor: Oracle Corporation, runtime:
> > /usr/lib/jvm/jdk1.8.0_333/jre
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "linux", version: "4.15.0-193-generic", arch: "amd64", family:
> > "unix"
> >
> > I have tested this with 'mvn clean package site site:stage
> > -Pcommons-rng-examples' using:
> >
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/apache-maven-3
> > Java version: 11.0.16, vendor: Ubuntu, runtime:
> > /usr/lib/jvm/java-11-openjdk-amd64
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "linux", version: "4.15.0-193-generic", arch: "amd64", family:
> > "unix"
> >
> > Details of changes since 1.4 are in the release notes:
> >
> >
> https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1/RELEASE-NOTES.txt
> >
> >
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/changes-report.html
> >
> > Site:
> >
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/index.html
> > (note some *relative* links are broken and the 1.5 directories are
> not
> > yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report (compared to 1.4):
> >
> >
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-client-api/japicmp.html
> >
> >
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-core/japicmp.html
> >
> >
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-simple/japicmp.html
> >
> >
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-sampling/japicmp.html
> >
> > RevApi Report (compared to 1.4):
> >
> >
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-client-api/revapi-report.html
> >
> >
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-core/revapi-report.html
> >
> >
> 

Re: [VOTE][RC1] Release Commons RNG 1.5

[Alex Herbert]

My +1

Alex

On Wed, 5 Oct 2022 at 11:25, Alex Herbert  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons RNG 1.4 was released, so I would like to release
> Apache Commons RNG 1.5.
>
> Apache Commons RNG 1.5 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1 (svn
> revision 57177)
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/
>
> The Git tag commit for this RC is commons-rng-1.5-RC1 which you can browse
> here:
>
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=commons-rng-1.5-RC1
>
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-rng.git
> --branch commons-rng-1.5-RC1 commons-rng-1.5-RC1
> (signature can be checked from git using 'git tag -v commons-rng-1.5-RC1')
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1596/org/apache/commons/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Tue Oct 04 13:00:24 BST 2022
>
> commons-rng-1.5-bin.tar.gz=9e98092cb123a1873cc4ab05ebd87681b9f5fe171ad53cd00488c33e0ab2c7fb8a0bdd9c903a3bde7bc2e4f4035b07cf223b0d921e35d00fcea226ec16f86b5c
>
> commons-rng-1.5-bin.zip=ad01629da0ef089641c4a7a8fed8e2dd9f1ed0fec3e9cc6fd19df22e0516bc8c1a4699a8d2104b5878a13ad9fbec724b85ca0a71c1e3027673cbcab8a5911b30
>
> commons-rng-1.5-src.tar.gz=7fdfcd9ee43ac51f73eb6781d8fae7f313bf20658af84383ff791779def56c690458b99f2e996ce7fec8588db3218f23eea6dc6c2ff7d692f4209b78eb4b4dd8
>
> commons-rng-1.5-src.zip=e1624601d449eecca660839b592c4deb7386ef77a09d613002e8220149f244cbb5bc70c08100fe27eb0d448efea7aef8ac1ebe26f416d846ba3bccd4f43d82e5
>
> Signatures may be validated on a system supporting a bash unix shell by
> executing:
> svn co https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1/
> cd 1.5-RC1
> chmod +x ./signature-validator.sh
> for m in client-api core simple sampling bom; do
> ./signature-validator.sh
> https://repository.apache.org/content/repositories/orgapachecommons-1596/org/apache/commons/commons-rng-${m}/1.5/;
> done
>
> The source code contains examples that are not part of the public API.
> These examples contain Java 11 modules and are enabled using a profile (see
> below).
>
> Note: Testing randomness using statistical thresholds results in failures
> at a given probability. The 'maven-surefire-plugin' is configured to re-run
> tests that fail, and pass the build if they succeed within the allotted
> number of reruns (the test will be marked as 'flaky' in the report).
>
> I have tested this with 'mvn clean install' using:
>
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/apache-maven-3
> Java version: 1.8.0_333, vendor: Oracle Corporation, runtime:
> /usr/lib/jvm/jdk1.8.0_333/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-193-generic", arch: "amd64", family:
> "unix"
>
> I have tested this with 'mvn clean package site site:stage
> -Pcommons-rng-examples' using:
>
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/apache-maven-3
> Java version: 11.0.16, vendor: Ubuntu, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-193-generic", arch: "amd64", family:
> "unix"
>
> Details of changes since 1.4 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1/RELEASE-NOTES.txt
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/changes-report.html
>
> Site:
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/index.html
> (note some *relative* links are broken and the 1.5 directories are not
> yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.4):
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-client-api/japicmp.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-core/japicmp.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-simple/japicmp.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-sampling/japicmp.html
>
> RevApi Report (compared to 1.4):
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-client-api/revapi-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-core/revapi-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-simple/revapi-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-sampling/revapi-report.html
>
> RAT Report:
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   

Re: [VOTE][RC1] Release Commons RNG 1.5

[Alex Herbert]

Can I get another PMC vote for this please?

Thanks,

Alex

On Wed, 5 Oct 2022 at 11:25, Alex Herbert  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons RNG 1.4 was released, so I would like to release
> Apache Commons RNG 1.5.
>
> Apache Commons RNG 1.5 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1 (svn
> revision 57177)
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/
>
> The Git tag commit for this RC is commons-rng-1.5-RC1 which you can browse
> here:
>
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=commons-rng-1.5-RC1
>
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-rng.git
> --branch commons-rng-1.5-RC1 commons-rng-1.5-RC1
> (signature can be checked from git using 'git tag -v commons-rng-1.5-RC1')
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1596/org/apache/commons/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Tue Oct 04 13:00:24 BST 2022
>
> commons-rng-1.5-bin.tar.gz=9e98092cb123a1873cc4ab05ebd87681b9f5fe171ad53cd00488c33e0ab2c7fb8a0bdd9c903a3bde7bc2e4f4035b07cf223b0d921e35d00fcea226ec16f86b5c
>
> commons-rng-1.5-bin.zip=ad01629da0ef089641c4a7a8fed8e2dd9f1ed0fec3e9cc6fd19df22e0516bc8c1a4699a8d2104b5878a13ad9fbec724b85ca0a71c1e3027673cbcab8a5911b30
>
> commons-rng-1.5-src.tar.gz=7fdfcd9ee43ac51f73eb6781d8fae7f313bf20658af84383ff791779def56c690458b99f2e996ce7fec8588db3218f23eea6dc6c2ff7d692f4209b78eb4b4dd8
>
> commons-rng-1.5-src.zip=e1624601d449eecca660839b592c4deb7386ef77a09d613002e8220149f244cbb5bc70c08100fe27eb0d448efea7aef8ac1ebe26f416d846ba3bccd4f43d82e5
>
> Signatures may be validated on a system supporting a bash unix shell by
> executing:
> svn co https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1/
> cd 1.5-RC1
> chmod +x ./signature-validator.sh
> for m in client-api core simple sampling bom; do
> ./signature-validator.sh
> https://repository.apache.org/content/repositories/orgapachecommons-1596/org/apache/commons/commons-rng-${m}/1.5/;
> done
>
> The source code contains examples that are not part of the public API.
> These examples contain Java 11 modules and are enabled using a profile (see
> below).
>
> Note: Testing randomness using statistical thresholds results in failures
> at a given probability. The 'maven-surefire-plugin' is configured to re-run
> tests that fail, and pass the build if they succeed within the allotted
> number of reruns (the test will be marked as 'flaky' in the report).
>
> I have tested this with 'mvn clean install' using:
>
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/apache-maven-3
> Java version: 1.8.0_333, vendor: Oracle Corporation, runtime:
> /usr/lib/jvm/jdk1.8.0_333/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-193-generic", arch: "amd64", family:
> "unix"
>
> I have tested this with 'mvn clean package site site:stage
> -Pcommons-rng-examples' using:
>
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/apache-maven-3
> Java version: 11.0.16, vendor: Ubuntu, runtime:
> /usr/lib/jvm/java-11-openjdk-amd64
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-193-generic", arch: "amd64", family:
> "unix"
>
> Details of changes since 1.4 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/rng/1.5-RC1/RELEASE-NOTES.txt
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/changes-report.html
>
> Site:
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/index.html
> (note some *relative* links are broken and the 1.5 directories are not
> yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 1.4):
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-client-api/japicmp.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-core/japicmp.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-simple/japicmp.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-sampling/japicmp.html
>
> RevApi Report (compared to 1.4):
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-client-api/revapi-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-core/revapi-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-simple/revapi-report.html
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/commons-rng-sampling/revapi-report.html
>
> RAT Report:
>
> https://home.apache.org/~aherbert/commons-rng-1.5-RC1-site/rat-report.html
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will