RE: Re: Publish statement on Commons Text CVE

2022-10-24 Thread Wolfgang Jung
Dear Gary,

I’ve sent this exact problem on Dec. 11 2021 to the mail-address mentioned on 
the above change security page: secur...@commons.apache.org
But never received a response… Therefore my question: Is this mail-address 
still correct?

Best regards (and glad, that the default behaviour will be changed as 
suggested),
  Wolfgang Jung

On 2022/10/19 21:28:59 Gary Gregory wrote:
> Fixed! The Apache Commons Configuration Security page is now live:
> https://commons.apache.org/proper/commons-configuration/security.html
>
> Gary
>
> On Wed, Oct 19, 2022 at 4:45 PM Gary Gregory  wrote:
> >
> > Thank you for the brilliant detective work Bruno!
> >
> > Gary
> >
> > On Wed, Oct 19, 2022, 16:16 Bruno Kinoshita  wrote:
> >>
> >> I had a look at the browser network tab, and saw an HTTP 302 location
> >> redirect from Varnish. These redirects normally need to be configured in
> >> Varnish with some sort of rule.
> >>
> >> I went back to your email, grabbed the SVN URL, stepped up a few
> >> directories and saw an .htaccess at a parent level, that has a redirect
> >> rule for some commons components (it has for [configuration], not for
> >> [text]). I think we just need to remove the configuration entry.
> >>
> >> https://svn.apache.org/repos/infra/websites/production/commons/content/.htaccess
> >>
> >> HTH,
> >> Bruno
> >>
> >> On Thu, 20 Oct 2022 at 08:22, Gary Gregory  wrote:
> >>
> >> > Well, I published the Configuration site to the usual svn:
> >> >
> >> >
> >> > https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-configuration/
> >> >
> >> > which should be end up at:
> >> >
> >> > https://commons.apache.org/proper/commons-configuration/index.html
> >> >
> >> > but for me clicking on the "Security" (in the top left menu) does not
> >> > take me to
> >> > https://commons.apache.org/proper/commons-configuration/security.html,
> >> > instead it redirects magically to
> >> > https://commons.apache.org/security.html
> >> >
> >> > Commons Text is fine in this area. What gives?
> >> >
> >> > Gary
> >> >
> >> > On Wed, Oct 19, 2022 at 12:48 PM Gary Gregory 
> >> > wrote:
> >> > >
> >> > > TY and merged. I'll publish later today.
> >> > >
> >> > > Gary
> >> > >
> >> > > On Wed, Oct 19, 2022 at 11:13 AM Arnout Engelen 
> >> > wrote:
> >> > > >
> >> > > > On Wed, Oct 19, 2022 at 12:23 PM Gary Gregory 
> >> > wrote:
> >> > > >>
> >> > > >> Would you be available to update the Commons Configuration page
> >> > > >>
> >> > https://github.com/apache/commons-configuration/blob/master/src/site/xdoc/security.xml
> >> > > >> in the same way you did for Commons Text? The CVE is basically the
> >> > > >> same: https://nvd.nist.gov/vuln/detail/CVE-2022-33980
> >> > > >
> >> > > >
> >> > > > Happy to! Proposed
> >> > https://github.com/apache/commons-configuration/pull/230
> >> > > >
> >> > > >
> >> > > > Kind regards,
> >> > > >
> >> > > > Arnout
> >> > > >
> >> > > >> On Tue, Oct 18, 2022 at 11:20 PM Gary Gregory 
> >> > wrote:
> >> > > >> >
> >> > > >> > FYI: I updated the security page
> >> > > >> > https://commons.apache.org/proper/commons-text/security.html
> >> > > >> >
> >> > > >> > Gary
> >> > > >> >
> >> > > >> > On Tue, Oct 18, 2022 at 4:25 PM Gary Gregory <
> >> > garydgreg...@gmail.com> wrote:
> >> > > >> > >
> >> > > >> > > I have an unpublished security page in the repo already. Let's
> >> > not duplicate information like this PR does please. Publishing a
> >> > non-snapshot site is a pain and I don't want to do more than I have to.
> >> > There is no need to buy in and promote the FUD on the front page IMO. 
> >> > This
> >> > component will soon publish a security page and you can PR that page (
> >> > https://github.com/apache/commons-text/blob/master/src/site/xdoc/security.xml)
> >> > if you want to update the details.
> >> > > >> > >
> >> > > >> > > TY!
> >> > > >> > >
> >> > > >> > > On Tue, Oct 18, 2022, 09:52 Arnout Engelen 
> >> > wrote:
> >> > > >> > >>
> >> > > >> > >> Hello Commons,
> >> > > >> > >>
> >> > > >> > >> As you might know Commons Text recently published a CVE. It
> >> > seems there is
> >> > > >> > >> a fair bit of confusion about its severity online, so it seems
> >> > like a good
> >> > > >> > >> idea to publish a statement around that on the website.
> >> > > >> > >>
> >> > > >> > >> I've proposed one at
> >> > https://github.com/apache/commons-text/pull/374 and
> >> > > >> > >> I'd like to ask for your review & help publishing. Given the
> >> > issue is
> >> > > >> > >> getting some attention it might be nice to publish something
> >> > soon and maybe
> >> > > >> > >> refine it later ;). I'll also publish it at
> >> > > >> > >> https://blogs.apache.org/security .
> >> > > >> > >>
> >> > > >> > >> I think what would need to happen is:
> >> > > >> > >> * review and merge
> >> > https://github.com/apache/commons-text/pull/374
> >> > > >> > >> * check out the commit before the merge commit (since that one
> >> > still has
> >> > > >> > >> 1.10.0 as the 

Re: [VOTE] Release Apache Commons CSV 1.10.0 based on RC1

2022-10-24 Thread Alex Herbert
On Sun, 23 Oct 2022 at 14:09, Gary D. Gregory  wrote:
>
> Ah, well, let's have you review git master now and feel free to refactor. I 
> think we are close if not done for another RC. WDYT?

Since this thread was for the RC1 vote I started a new thread titled:

[csv] validation of duplicate headers (was [VOTE] Release Apache
Commons CSV 1.10.0 based on RC1)

I found one bug in the implementation is master which I fixed for
CSVFormat. There is still some inconsistent behaviour by CSVParser
that I discuss in the new thread that should be fixed, or current
behaviour documented, before an RC2.

Alex

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



Re: Re: Publish statement on Commons Text CVE

2022-10-24 Thread Gary Gregory
Wow, the email issue with the .invalid email address is on the Apache side
(DMARC).

Gary

On Mon, Oct 24, 2022, 14:54 Gary Gregory  wrote:

> The problem is that you sent your message from what I assume is a bogus
> email reply address: p...@wolfgang-jung.net.invalid
>
> To reply to this email I had to hand edit the reply to and am guessing
> that maybe p...@wolfgang-jung.net will reach you, but, who knows... I
> usually don't bother fiddling with this type of email address hassle.
>
> WRT to the CVE, the issue was originally reported in Commons Configuration
> where the code is basically the same (in a different package obviously). It
> was decided that Commons Configuration warranted a CVE and we pushed a
> release out. Since Text and Configuration are pretty much the same in this
> area, it seemed consistent to issue a CVE and a new version for Text as
> well.
>
> Gary
>
> On Mon, Oct 24, 2022, 11:45 Wolfgang Jung 
> wrote:
>
>> Dear Gary,
>>
>> I’ve sent this exact problem on Dec. 11 2021 to the mail-address
>> mentioned on the above changed security page: secur...@commons.apache.org
>> But never received a response… Therefore my question: Is this
>> mail-address still correct?
>>
>> Best regards (and glad, that the default behaviour will be changed as
>> suggested),
>>  Wolfgang Jung
>>
>> On 2022/10/19 21:28:59 Gary Gregory wrote:
>> > Fixed! The Apache Commons Configuration Security page is now live:
>> > https://commons.apache.org/proper/commons-configuration/security.html
>> >
>> > Gary
>> >
>> > On Wed, Oct 19, 2022 at 4:45 PM Gary Gregory  wrote:
>> > >
>> > > Thank you for the brilliant detective work Bruno!
>> > >
>> > > Gary
>> > >
>> > > On Wed, Oct 19, 2022, 16:16 Bruno Kinoshita  wrote:
>> > >>
>> > >> I had a look at the browser network tab, and saw an HTTP 302 location
>> > >> redirect from Varnish. These redirects normally need to be
>> configured in
>> > >> Varnish with some sort of rule.
>> > >>
>> > >> I went back to your email, grabbed the SVN URL, stepped up a few
>> > >> directories and saw an .htaccess at a parent level, that has a
>> redirect
>> > >> rule for some commons components (it has for [configuration], not for
>> > >> [text]). I think we just need to remove the configuration entry.
>> > >>
>> > >>
>> https://svn.apache.org/repos/infra/websites/production/commons/content/.htaccess
>> > >>
>> > >> HTH,
>> > >> Bruno
>> > >>
>> > >> On Thu, 20 Oct 2022 at 08:22, Gary Gregory  wrote:
>> > >>
>> > >> > Well, I published the Configuration site to the usual svn:
>> > >> >
>> > >> >
>> > >> >
>> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-configuration/
>> > >> >
>> > >> > which should be end up at:
>> > >> >
>> > >> > https://commons.apache.org/proper/commons-configuration/index.html
>> > >> >
>> > >> > but for me clicking on the "Security" (in the top left menu) does
>> not
>> > >> > take me to
>> > >> >
>> https://commons.apache.org/proper/commons-configuration/security.html,
>> > >> > instead it redirects magically to
>> > >> > https://commons.apache.org/security.html
>> > >> >
>> > >> > Commons Text is fine in this area. What gives?
>> > >> >
>> > >> > Gary
>> > >> >
>> > >> > On Wed, Oct 19, 2022 at 12:48 PM Gary Gregory 
>> > >> > wrote:
>> > >> > >
>> > >> > > TY and merged. I'll publish later today.
>> > >> > >
>> > >> > > Gary
>> > >> > >
>> > >> > > On Wed, Oct 19, 2022 at 11:13 AM Arnout Engelen <
>> en...@apache.org>
>> > >> > wrote:
>> > >> > > >
>> > >> > > > On Wed, Oct 19, 2022 at 12:23 PM Gary Gregory > >
>> > >> > wrote:
>> > >> > > >>
>> > >> > > >> Would you be available to update the Commons Configuration
>> page
>> > >> > > >>
>> > >> >
>> https://github.com/apache/commons-configuration/blob/master/src/site/xdoc/security.xml
>> > >> > > >> in the same way you did for Commons Text? The CVE is
>> basically the
>> > >> > > >> same: https://nvd.nist.gov/vuln/detail/CVE-2022-33980
>> > >> > > >
>> > >> > > >
>> > >> > > > Happy to! Proposed
>> > >> > https://github.com/apache/commons-configuration/pull/230
>> > >> > > >
>> > >> > > >
>> > >> > > > Kind regards,
>> > >> > > >
>> > >> > > > Arnout
>> > >> > > >
>> > >> > > >> On Tue, Oct 18, 2022 at 11:20 PM Gary Gregory <
>> ga...@gmail.com>
>> > >> > wrote:
>> > >> > > >> >
>> > >> > > >> > FYI: I updated the security page
>> > >> > > >> >
>> https://commons.apache.org/proper/commons-text/security.html
>> > >> > > >> >
>> > >> > > >> > Gary
>> > >> > > >> >
>> > >> > > >> > On Tue, Oct 18, 2022 at 4:25 PM Gary Gregory <
>> > >> > garydgreg...@gmail.com> wrote:
>> > >> > > >> > >
>> > >> > > >> > > I have an unpublished security page in the repo already.
>> Let's
>> > >> > not duplicate information like this PR does please. Publishing a
>> > >> > non-snapshot site is a pain and I don't want to do more than I
>> have to.
>> > >> > There is no need to buy in and promote the FUD on the front page
>> IMO. This
>> > >> > component will soon publish a security page and you 

Re: Publish statement on Commons Text CVE

2022-10-24 Thread Gary Gregory
Wow, I had no idea we did this, sure is painful to deal with :-(

Gary

On Mon, Oct 24, 2022, 15:10 Mark Thomas  wrote:

> On 24/10/2022 19:54, Gary Gregory wrote:
> > The problem is that you sent your message from what I assume is a bogus
> > email reply address: p...@wolfgang-jung.net.invalid
>
> No, the ".invalid" was added by the ASF mail servers.
>
> See: https://blogs.apache.org/infra/entry/dmarc_filtering_on_lists_that
>
> We can ask infra to change this behaviour but it requires disbaling all
> forms of message munging. For Commons, I think this is limited to the
> help message added as a footer.
>
> > To reply to this email I had to hand edit the reply to and am guessing
> that
> > maybe p...@wolfgang-jung.net will reach you, but, who knows... I usually
> > don't bother fiddling with this type of email address hassle.
>
> That is the price we (the ASF) have to pay for avoiding DMARC issues. Or
> we change the list configuration.
>
> Mark
>
>
> > WRT to the CVE, the issue was originally reported in Commons
> Configuration
> > where the code is basically the same (in a different package obviously).
> It
> > was decided that Commons Configuration warranted a CVE and we pushed a
> > release out. Since Text and Configuration are pretty much the same in
> this
> > area, it seemed consistent to issue a CVE and a new version for Text as
> > well.
> >
> > Gary
> >
> > On Mon, Oct 24, 2022, 11:45 Wolfgang Jung  .invalid>
> > wrote:
> >
> >> Dear Gary,
> >>
> >> I’ve sent this exact problem on Dec. 11 2021 to the mail-address
> mentioned
> >> on the above changed security page: secur...@commons.apache.org
> >> But never received a response… Therefore my question: Is this
> mail-address
> >> still correct?
> >>
> >> Best regards (and glad, that the default behaviour will be changed as
> >> suggested),
> >>   Wolfgang Jung
> >>
> >> On 2022/10/19 21:28:59 Gary Gregory wrote:
> >>> Fixed! The Apache Commons Configuration Security page is now live:
> >>> https://commons.apache.org/proper/commons-configuration/security.html
> >>>
> >>> Gary
> >>>
> >>> On Wed, Oct 19, 2022 at 4:45 PM Gary Gregory  wrote:
> 
>  Thank you for the brilliant detective work Bruno!
> 
>  Gary
> 
>  On Wed, Oct 19, 2022, 16:16 Bruno Kinoshita  wrote:
> >
> > I had a look at the browser network tab, and saw an HTTP 302 location
> > redirect from Varnish. These redirects normally need to be configured
> >> in
> > Varnish with some sort of rule.
> >
> > I went back to your email, grabbed the SVN URL, stepped up a few
> > directories and saw an .htaccess at a parent level, that has a
> >> redirect
> > rule for some commons components (it has for [configuration], not for
> > [text]). I think we just need to remove the configuration entry.
> >
> >
> >>
> https://svn.apache.org/repos/infra/websites/production/commons/content/.htaccess
> >
> > HTH,
> > Bruno
> >
> > On Thu, 20 Oct 2022 at 08:22, Gary Gregory  wrote:
> >
> >> Well, I published the Configuration site to the usual svn:
> >>
> >>
> >>
> >>
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-configuration/
> >>
> >> which should be end up at:
> >>
> >> https://commons.apache.org/proper/commons-configuration/index.html
> >>
> >> but for me clicking on the "Security" (in the top left menu) does
> >> not
> >> take me to
> >>
> >> https://commons.apache.org/proper/commons-configuration/security.html,
> >> instead it redirects magically to
> >> https://commons.apache.org/security.html
> >>
> >> Commons Text is fine in this area. What gives?
> >>
> >> Gary
> >>
> >> On Wed, Oct 19, 2022 at 12:48 PM Gary Gregory 
> >> wrote:
> >>>
> >>> TY and merged. I'll publish later today.
> >>>
> >>> Gary
> >>>
> >>> On Wed, Oct 19, 2022 at 11:13 AM Arnout Engelen  >>>
> >> wrote:
> 
>  On Wed, Oct 19, 2022 at 12:23 PM Gary Gregory 
> >> wrote:
> >
> > Would you be available to update the Commons Configuration page
> >
> >>
> >>
> https://github.com/apache/commons-configuration/blob/master/src/site/xdoc/security.xml
> > in the same way you did for Commons Text? The CVE is basically
> >> the
> > same: https://nvd.nist.gov/vuln/detail/CVE-2022-33980
> 
> 
>  Happy to! Proposed
> >> https://github.com/apache/commons-configuration/pull/230
> 
> 
>  Kind regards,
> 
>  Arnout
> 
> > On Tue, Oct 18, 2022 at 11:20 PM Gary Gregory  >>>
> >> wrote:
> >>
> >> FYI: I updated the security page
> >> https://commons.apache.org/proper/commons-text/security.html
> >>
> >> Gary
> >>
> >> On Tue, Oct 18, 2022 at 4:25 PM Gary Gregory <
> >> garydgreg...@gmail.com> wrote:
> 

Re: Publish statement on Commons Text CVE

2022-10-24 Thread Mark Thomas

On 24/10/2022 19:54, Gary Gregory wrote:

The problem is that you sent your message from what I assume is a bogus
email reply address: p...@wolfgang-jung.net.invalid


No, the ".invalid" was added by the ASF mail servers.

See: https://blogs.apache.org/infra/entry/dmarc_filtering_on_lists_that

We can ask infra to change this behaviour but it requires disbaling all 
forms of message munging. For Commons, I think this is limited to the 
help message added as a footer.



To reply to this email I had to hand edit the reply to and am guessing that
maybe p...@wolfgang-jung.net will reach you, but, who knows... I usually
don't bother fiddling with this type of email address hassle.


That is the price we (the ASF) have to pay for avoiding DMARC issues. Or 
we change the list configuration.


Mark



WRT to the CVE, the issue was originally reported in Commons Configuration
where the code is basically the same (in a different package obviously). It
was decided that Commons Configuration warranted a CVE and we pushed a
release out. Since Text and Configuration are pretty much the same in this
area, it seemed consistent to issue a CVE and a new version for Text as
well.

Gary

On Mon, Oct 24, 2022, 11:45 Wolfgang Jung 
wrote:


Dear Gary,

I’ve sent this exact problem on Dec. 11 2021 to the mail-address mentioned
on the above changed security page: secur...@commons.apache.org
But never received a response… Therefore my question: Is this mail-address
still correct?

Best regards (and glad, that the default behaviour will be changed as
suggested),
  Wolfgang Jung

On 2022/10/19 21:28:59 Gary Gregory wrote:

Fixed! The Apache Commons Configuration Security page is now live:
https://commons.apache.org/proper/commons-configuration/security.html

Gary

On Wed, Oct 19, 2022 at 4:45 PM Gary Gregory  wrote:


Thank you for the brilliant detective work Bruno!

Gary

On Wed, Oct 19, 2022, 16:16 Bruno Kinoshita  wrote:


I had a look at the browser network tab, and saw an HTTP 302 location
redirect from Varnish. These redirects normally need to be configured

in

Varnish with some sort of rule.

I went back to your email, grabbed the SVN URL, stepped up a few
directories and saw an .htaccess at a parent level, that has a

redirect

rule for some commons components (it has for [configuration], not for
[text]). I think we just need to remove the configuration entry.



https://svn.apache.org/repos/infra/websites/production/commons/content/.htaccess


HTH,
Bruno

On Thu, 20 Oct 2022 at 08:22, Gary Gregory  wrote:


Well, I published the Configuration site to the usual svn:




https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-configuration/


which should be end up at:

https://commons.apache.org/proper/commons-configuration/index.html

but for me clicking on the "Security" (in the top left menu) does

not

take me to


https://commons.apache.org/proper/commons-configuration/security.html,

instead it redirects magically to
https://commons.apache.org/security.html

Commons Text is fine in this area. What gives?

Gary

On Wed, Oct 19, 2022 at 12:48 PM Gary Gregory 
wrote:


TY and merged. I'll publish later today.

Gary

On Wed, Oct 19, 2022 at 11:13 AM Arnout Engelen 


wrote:


On Wed, Oct 19, 2022 at 12:23 PM Gary Gregory 

wrote:


Would you be available to update the Commons Configuration page




https://github.com/apache/commons-configuration/blob/master/src/site/xdoc/security.xml

in the same way you did for Commons Text? The CVE is basically

the

same: https://nvd.nist.gov/vuln/detail/CVE-2022-33980



Happy to! Proposed

https://github.com/apache/commons-configuration/pull/230



Kind regards,

Arnout


On Tue, Oct 18, 2022 at 11:20 PM Gary Gregory 


wrote:


FYI: I updated the security page
https://commons.apache.org/proper/commons-text/security.html

Gary

On Tue, Oct 18, 2022 at 4:25 PM Gary Gregory <

garydgreg...@gmail.com> wrote:


I have an unpublished security page in the repo already.

Let's

not duplicate information like this PR does please. Publishing a
non-snapshot site is a pain and I don't want to do more than I have

to.

There is no need to buy in and promote the FUD on the front page

IMO. This

component will soon publish a security page and you can PR that

page (



https://github.com/apache/commons-text/blob/master/src/site/xdoc/security.xml
)

if you want to update the details.


TY!

On Tue, Oct 18, 2022, 09:52 Arnout Engelen <

en...@apache.org>

wrote:


Hello Commons,

As you might know Commons Text recently published a CVE.

It

seems there is

a fair bit of confusion about its severity online, so it

seems

like a good

idea to publish a statement around that on the website.

I've proposed one at

https://github.com/apache/commons-text/pull/374 and

I'd like to ask for your review & help publishing. Given

the

issue is

getting some attention it might be nice to publish

something

soon and maybe

refine it later ;). I'll also publish it at

Re: Re: Publish statement on Commons Text CVE

2022-10-24 Thread Gary Gregory
The problem is that you sent your message from what I assume is a bogus
email reply address: p...@wolfgang-jung.net.invalid

To reply to this email I had to hand edit the reply to and am guessing that
maybe p...@wolfgang-jung.net will reach you, but, who knows... I usually
don't bother fiddling with this type of email address hassle.

WRT to the CVE, the issue was originally reported in Commons Configuration
where the code is basically the same (in a different package obviously). It
was decided that Commons Configuration warranted a CVE and we pushed a
release out. Since Text and Configuration are pretty much the same in this
area, it seemed consistent to issue a CVE and a new version for Text as
well.

Gary

On Mon, Oct 24, 2022, 11:45 Wolfgang Jung 
wrote:

> Dear Gary,
>
> I’ve sent this exact problem on Dec. 11 2021 to the mail-address mentioned
> on the above changed security page: secur...@commons.apache.org
> But never received a response… Therefore my question: Is this mail-address
> still correct?
>
> Best regards (and glad, that the default behaviour will be changed as
> suggested),
>  Wolfgang Jung
>
> On 2022/10/19 21:28:59 Gary Gregory wrote:
> > Fixed! The Apache Commons Configuration Security page is now live:
> > https://commons.apache.org/proper/commons-configuration/security.html
> >
> > Gary
> >
> > On Wed, Oct 19, 2022 at 4:45 PM Gary Gregory  wrote:
> > >
> > > Thank you for the brilliant detective work Bruno!
> > >
> > > Gary
> > >
> > > On Wed, Oct 19, 2022, 16:16 Bruno Kinoshita  wrote:
> > >>
> > >> I had a look at the browser network tab, and saw an HTTP 302 location
> > >> redirect from Varnish. These redirects normally need to be configured
> in
> > >> Varnish with some sort of rule.
> > >>
> > >> I went back to your email, grabbed the SVN URL, stepped up a few
> > >> directories and saw an .htaccess at a parent level, that has a
> redirect
> > >> rule for some commons components (it has for [configuration], not for
> > >> [text]). I think we just need to remove the configuration entry.
> > >>
> > >>
> https://svn.apache.org/repos/infra/websites/production/commons/content/.htaccess
> > >>
> > >> HTH,
> > >> Bruno
> > >>
> > >> On Thu, 20 Oct 2022 at 08:22, Gary Gregory  wrote:
> > >>
> > >> > Well, I published the Configuration site to the usual svn:
> > >> >
> > >> >
> > >> >
> https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-configuration/
> > >> >
> > >> > which should be end up at:
> > >> >
> > >> > https://commons.apache.org/proper/commons-configuration/index.html
> > >> >
> > >> > but for me clicking on the "Security" (in the top left menu) does
> not
> > >> > take me to
> > >> >
> https://commons.apache.org/proper/commons-configuration/security.html,
> > >> > instead it redirects magically to
> > >> > https://commons.apache.org/security.html
> > >> >
> > >> > Commons Text is fine in this area. What gives?
> > >> >
> > >> > Gary
> > >> >
> > >> > On Wed, Oct 19, 2022 at 12:48 PM Gary Gregory 
> > >> > wrote:
> > >> > >
> > >> > > TY and merged. I'll publish later today.
> > >> > >
> > >> > > Gary
> > >> > >
> > >> > > On Wed, Oct 19, 2022 at 11:13 AM Arnout Engelen  >
> > >> > wrote:
> > >> > > >
> > >> > > > On Wed, Oct 19, 2022 at 12:23 PM Gary Gregory 
> > >> > wrote:
> > >> > > >>
> > >> > > >> Would you be available to update the Commons Configuration page
> > >> > > >>
> > >> >
> https://github.com/apache/commons-configuration/blob/master/src/site/xdoc/security.xml
> > >> > > >> in the same way you did for Commons Text? The CVE is basically
> the
> > >> > > >> same: https://nvd.nist.gov/vuln/detail/CVE-2022-33980
> > >> > > >
> > >> > > >
> > >> > > > Happy to! Proposed
> > >> > https://github.com/apache/commons-configuration/pull/230
> > >> > > >
> > >> > > >
> > >> > > > Kind regards,
> > >> > > >
> > >> > > > Arnout
> > >> > > >
> > >> > > >> On Tue, Oct 18, 2022 at 11:20 PM Gary Gregory  >
> > >> > wrote:
> > >> > > >> >
> > >> > > >> > FYI: I updated the security page
> > >> > > >> > https://commons.apache.org/proper/commons-text/security.html
> > >> > > >> >
> > >> > > >> > Gary
> > >> > > >> >
> > >> > > >> > On Tue, Oct 18, 2022 at 4:25 PM Gary Gregory <
> > >> > garydgreg...@gmail.com> wrote:
> > >> > > >> > >
> > >> > > >> > > I have an unpublished security page in the repo already.
> Let's
> > >> > not duplicate information like this PR does please. Publishing a
> > >> > non-snapshot site is a pain and I don't want to do more than I have
> to.
> > >> > There is no need to buy in and promote the FUD on the front page
> IMO. This
> > >> > component will soon publish a security page and you can PR that
> page (
> > >> >
> https://github.com/apache/commons-text/blob/master/src/site/xdoc/security.xml
> )
> > >> > if you want to update the details.
> > >> > > >> > >
> > >> > > >> > > TY!
> > >> > > >> > >
> > >> > > >> > > On Tue, Oct 18, 2022, 09:52 Arnout Engelen <
> en...@apache.org>
> > >> > wrote:
> > >> > > >> > >>
> > 

Re: JEXL Security

2022-10-24 Thread Mark Thomas

On 24/10/2022 17:02, Henri Biestro (Apache) wrote:

Hello Commons;

JEXL-381 is an attempt at making JEXL's default more secure or at least
less 'permeable' wrt to the application/platform/JVM/file-system/host that
runs it. Based on JexlPermissions - a crude security visibility manager -,
this restricts the *default* behavior of what is visible to JEXL scripts to
the basics (lang, math, text, collection,...).
This does prevent a future crude test of some kind leading to a CVE stating
that JEXL poses a security risk since it can create processes or read the
whole file-system (cf JEXL-223).

I'd like opinions on this idea - assuming it is not a bad one - and how to
best expose it. Although JEXL 3.3 is compatible with JEXL 3.2, the runtime
behavior might break due to these new default security restrictions.
The net-cost is that current users (people actually using JEXL for its
intended purpose) will have to actively decide how much permeability they
need if they want to upgrade to JEXL 3.3 and retain functionality.  They
will probably gain at least some insight about their platform/product
security. Note that the basic mitigation - being as permeable as JEXL 3.2 -
costs only a line of code..

Ideas on how to best warn/expose/explain this to users and any element
pertaining to this subject is welcome. :-)


This sort of functionality is only required if an application is passing 
untrusted / unsanitised input to JEXL. That seems an extremely dangerous 
thing to do to me. Do we have any indications that any real world users 
are doing this?


If the project starts down the road of being "secure by default for 
untrusted input" then rather than the project avoiding future CVEs, it 
opens itself up to a long stream of future CVEs as researchers find ways 
to bypass the restrictions put in place.


My recommended approach for projects like JEXL would to be clearly 
document that all input is expected to be trusted and then reject any 
vulnerability reports based on processing untrused input.


If there are users that need to process untrusted input then I'd suggest 
starting with asking how they are currently validating / sanitising that 
input.


Mark

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



JEXL Security

2022-10-24 Thread Henri Biestro (Apache)
Hello Commons;

JEXL-381 is an attempt at making JEXL's default more secure or at least
less 'permeable' wrt to the application/platform/JVM/file-system/host that
runs it. Based on JexlPermissions - a crude security visibility manager -,
this restricts the *default* behavior of what is visible to JEXL scripts to
the basics (lang, math, text, collection,...).
This does prevent a future crude test of some kind leading to a CVE stating
that JEXL poses a security risk since it can create processes or read the
whole file-system (cf JEXL-223).

I'd like opinions on this idea - assuming it is not a bad one - and how to
best expose it. Although JEXL 3.3 is compatible with JEXL 3.2, the runtime
behavior might break due to these new default security restrictions.
The net-cost is that current users (people actually using JEXL for its
intended purpose) will have to actively decide how much permeability they
need if they want to upgrade to JEXL 3.3 and retain functionality.  They
will probably gain at least some insight about their platform/product
security. Note that the basic mitigation - being as permeable as JEXL 3.2 -
costs only a line of code..

Ideas on how to best warn/expose/explain this to users and any element
pertaining to this subject is welcome. :-)
Thanks
Henrib


RE: Re: Publish statement on Commons Text CVE

2022-10-24 Thread Wolfgang Jung
Dear Gary,

I’ve sent this exact problem on Dec. 11 2021 to the mail-address mentioned on 
the above changed security page: secur...@commons.apache.org
But never received a response… Therefore my question: Is this mail-address 
still correct?

Best regards (and glad, that the default behaviour will be changed as 
suggested),
 Wolfgang Jung

On 2022/10/19 21:28:59 Gary Gregory wrote:
> Fixed! The Apache Commons Configuration Security page is now live:
> https://commons.apache.org/proper/commons-configuration/security.html
>
> Gary
>
> On Wed, Oct 19, 2022 at 4:45 PM Gary Gregory  wrote:
> >
> > Thank you for the brilliant detective work Bruno!
> >
> > Gary
> >
> > On Wed, Oct 19, 2022, 16:16 Bruno Kinoshita  wrote:
> >>
> >> I had a look at the browser network tab, and saw an HTTP 302 location
> >> redirect from Varnish. These redirects normally need to be configured in
> >> Varnish with some sort of rule.
> >>
> >> I went back to your email, grabbed the SVN URL, stepped up a few
> >> directories and saw an .htaccess at a parent level, that has a redirect
> >> rule for some commons components (it has for [configuration], not for
> >> [text]). I think we just need to remove the configuration entry.
> >>
> >> https://svn.apache.org/repos/infra/websites/production/commons/content/.htaccess
> >>
> >> HTH,
> >> Bruno
> >>
> >> On Thu, 20 Oct 2022 at 08:22, Gary Gregory  wrote:
> >>
> >> > Well, I published the Configuration site to the usual svn:
> >> >
> >> >
> >> > https://svn.apache.org/repos/infra/websites/production/commons/content/proper/commons-configuration/
> >> >
> >> > which should be end up at:
> >> >
> >> > https://commons.apache.org/proper/commons-configuration/index.html
> >> >
> >> > but for me clicking on the "Security" (in the top left menu) does not
> >> > take me to
> >> > https://commons.apache.org/proper/commons-configuration/security.html,
> >> > instead it redirects magically to
> >> > https://commons.apache.org/security.html
> >> >
> >> > Commons Text is fine in this area. What gives?
> >> >
> >> > Gary
> >> >
> >> > On Wed, Oct 19, 2022 at 12:48 PM Gary Gregory 
> >> > wrote:
> >> > >
> >> > > TY and merged. I'll publish later today.
> >> > >
> >> > > Gary
> >> > >
> >> > > On Wed, Oct 19, 2022 at 11:13 AM Arnout Engelen 
> >> > wrote:
> >> > > >
> >> > > > On Wed, Oct 19, 2022 at 12:23 PM Gary Gregory 
> >> > wrote:
> >> > > >>
> >> > > >> Would you be available to update the Commons Configuration page
> >> > > >>
> >> > https://github.com/apache/commons-configuration/blob/master/src/site/xdoc/security.xml
> >> > > >> in the same way you did for Commons Text? The CVE is basically the
> >> > > >> same: https://nvd.nist.gov/vuln/detail/CVE-2022-33980
> >> > > >
> >> > > >
> >> > > > Happy to! Proposed
> >> > https://github.com/apache/commons-configuration/pull/230
> >> > > >
> >> > > >
> >> > > > Kind regards,
> >> > > >
> >> > > > Arnout
> >> > > >
> >> > > >> On Tue, Oct 18, 2022 at 11:20 PM Gary Gregory 
> >> > wrote:
> >> > > >> >
> >> > > >> > FYI: I updated the security page
> >> > > >> > https://commons.apache.org/proper/commons-text/security.html
> >> > > >> >
> >> > > >> > Gary
> >> > > >> >
> >> > > >> > On Tue, Oct 18, 2022 at 4:25 PM Gary Gregory <
> >> > garydgreg...@gmail.com> wrote:
> >> > > >> > >
> >> > > >> > > I have an unpublished security page in the repo already. Let's
> >> > not duplicate information like this PR does please. Publishing a
> >> > non-snapshot site is a pain and I don't want to do more than I have to.
> >> > There is no need to buy in and promote the FUD on the front page IMO. 
> >> > This
> >> > component will soon publish a security page and you can PR that page (
> >> > https://github.com/apache/commons-text/blob/master/src/site/xdoc/security.xml)
> >> > if you want to update the details.
> >> > > >> > >
> >> > > >> > > TY!
> >> > > >> > >
> >> > > >> > > On Tue, Oct 18, 2022, 09:52 Arnout Engelen 
> >> > wrote:
> >> > > >> > >>
> >> > > >> > >> Hello Commons,
> >> > > >> > >>
> >> > > >> > >> As you might know Commons Text recently published a CVE. It
> >> > seems there is
> >> > > >> > >> a fair bit of confusion about its severity online, so it seems
> >> > like a good
> >> > > >> > >> idea to publish a statement around that on the website.
> >> > > >> > >>
> >> > > >> > >> I've proposed one at
> >> > https://github.com/apache/commons-text/pull/374 and
> >> > > >> > >> I'd like to ask for your review & help publishing. Given the
> >> > issue is
> >> > > >> > >> getting some attention it might be nice to publish something
> >> > soon and maybe
> >> > > >> > >> refine it later ;). I'll also publish it at
> >> > > >> > >> https://blogs.apache.org/security .
> >> > > >> > >>
> >> > > >> > >> I think what would need to happen is:
> >> > > >> > >> * review and merge
> >> > https://github.com/apache/commons-text/pull/374
> >> > > >> > >> * check out the commit before the merge commit (since that one
> >> > still has
> >> > > >> > >> 1.10.0 as the