[GitHub] commons-text issue #62: TEXT-101: Moved RandomStringUtils to Commons-text

2017-09-27 Thread ameyjadiye 
Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/62
  
@chtompki , I think all were thinking to deprecate it from lang and so we 
did. and due to more requests for ```RandomStringUtils```  we came up with the 
plan to move it also I think since ```RandomStringUtils``` is texty thing so 
belongs to commons-text and not lang. In same  mail trail you will see _"Grey 
area" should favour small components._

you should check this old mail trail as well 
http://markmail.org/message/bwyhvppr5s4waedp



---

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

Re: [IO] Releasing 2.6

2017-09-27 Thread Stian Soiland-Reyes 
I only got one error on Windows 10 – thanks for the fixes, Pascal and Gary!


The new error is:
  FileSystemUtilsTestCase.testGetFreeSpace_String:89
expected:<1.02861164E8> but was:<1.0286066E8>


I have:
   5 Dir(s)  104,991,649,792 bytes free

Test calls:

final long bytes = FileSystemUtils.freeSpace("");
final long kb = FileSystemUtils.freeSpaceKb("");
assertEquals((double) bytes / 1024, kb, 256d);


Presumably something else on my machine downloaded 504 kB between the
two freeSpace calls – which is not much these days – perhaps one email
:-)

I changed the test to use instead a 1% delta, which should generally
be a considerable amount of disk space (1 GB in my case), which is
still small enough to detect the ~2.4% difference between a kilobyte
vs kibibyte (the legacy freeSpaceKb is misnamed, it actually returns
kibibyte instead of pre-1998 “kilobyte”)

Also added javadoc that it's actually kibibytes -- perhaps a bit too
late :-) -- IO-506 deprecated the remaining methods of FileSystemUtils
in favour of java.nio.file.FileStore -- I think then we can deprecate
the whole FileSystemUtils  class as well.


On 27 September 2017 at 20:24, Pascal Schumacher
 wrote:
> Great!
>
> That should reduce the number of random test failures.
>
> I was just taking a look at this and the usage patterns of the folder looked
> horrible. :/
>
> Cheers,
> Pascal
>
>
> Am 27.09.2017 um 21:19 schrieb Gary Gregory:
>>
>> I updated the tests to use JUnit's TemporaryFolder rule instead of the old
>> custom and _shared_ folder. No more random errors.
>>
>> Gary
>>
>> On Wed, Sep 27, 2017 at 1:05 PM, Pascal Schumacher
>> >>
>>> wrote:
>>> Am 27.09.2017 um 19:58 schrieb Gary Gregory:
>>>
 I wonder if we need to force Maven to disable any concurrency when
 running
 tests?

>>> That should not be necessary.
>>>
>>> Maven/Maven-Surefire-Plugin does not run test in parallel by default. The
>>> surefire configuration of commons-io does not specify the parallel
>>> parameter and the forkcount parameter is set to 1 so the tests should be
>>> executed sequentially.
>>>
>>> Cheers,
>>> Pascal
>>>
>>>
>>> -
>>> 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
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [SECURITY] CVE-2017-12621 Apache Commons Jelly connects to URL with custom doctype definitions.

2017-09-27 Thread Bruno P. Kinoshita 
+1 Amazing work Rob! Kudos!
Bruno

Sent from Yahoo Mail on Android 
 
  On Thu, 28 Sep 2017 at 0:29, Benedikt Ritter wrote:   I 
would like to give kudos to Rob for handling this issue. The kind of dedication 
you put into fixing this issue and releasing a component that has not been 
touched for ages is what I’m looking for in PMC members.

Great work!
Benedikt

> Am 27.09.2017 um 15:05 schrieb Rob Tompkins :
> 
> CVE-2017-12621: Apache Commons Jelly connects to URL with custom doctype 
> definitions.
> 
> Severity: Medium
> 
> Vendor:
> The Apache Software Foundation
> 
> Versions Affected:
> commons-jelly-1.0 (core), namely commons-jelly-1.0.jar
> 
> Description:
> During Jelly (xml) file parsing with Apache Xerces, if a custom doctype 
> entity is declared with a “SYSTEM” entity with a URL and that entity is used 
> in the body of the Jelly file, during parser instantiation the parser will 
> attempt to connect to said URL. This could lead to XML External Entity (XXE) 
> attacks. The Open Web Application Security Project suggests that the fix be 
> https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet#XMLReader
> 
> Mitigation:
> 1.0 users should migrate to 1.0.1.
> 
> Example:
> 
> example.jelly
> --
> 
> 
>         
>        http://127.0.0.1:/;>
>        ]>
> 
>         xmlns:x="jelly:xml"
>        xmlns:html="jelly:html">
> 
> --
> 
> ExampleParser.java
> --
> public class ExampleParser {
>     
>     public static void main(String[] args) throws JellyException, 
> IOException, 
>                     NoSuchMethodException, 
> IllegalAccessException,IllegalArgumentException, 
>                     InvocationTargetException {
>         JellyContext context = new JellyContext();
>         context.runScript("example.jelly", null);
>     }
> }
> 
> Credit:
> This was discovered by Luca Carettoni of Doyensec.
> 
> References:
> [1] http://commons.apache.org/jelly/security-reports.html
> [2] https://issues.apache.org/jira/browse/JELLY-293
> 
> 
> -
> 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: [1/3] commons-io git commit: Remove setUp and tearDown methods that are no longer necessary after the switch to the TemporaryFolder rule.

2017-09-27 Thread Gary Gregory 
More clean ups! Yes! :-)

Gary

On Wed, Sep 27, 2017 at 2:23 PM,  wrote:

> Repository: commons-io
> Updated Branches:
>   refs/heads/master 14b52eb4f -> a43d2fa2f
>
>
> Remove setUp and tearDown methods that are no longer necessary after the
> switch to the TemporaryFolder rule.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-io/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-io/commit/68374b28
> Tree: http://git-wip-us.apache.org/repos/asf/commons-io/tree/68374b28
> Diff: http://git-wip-us.apache.org/repos/asf/commons-io/diff/68374b28
>
> Branch: refs/heads/master
> Commit: 68374b282662788ffedad30e600771e6d5de321b
> Parents: 99a353b
> Author: pascalschumacher 
> Authored: Wed Sep 27 22:18:21 2017 +0200
> Committer: pascalschumacher 
> Committed: Wed Sep 27 22:22:52 2017 +0200
>
> --
>  .../commons/io/FileDeleteStrategyTestCase.java  |  7 ---
>  .../apache/commons/io/FilenameUtilsTestCase.java| 16 
>  .../io/comparator/ComparatorAbstractTestCase.java   | 14 --
>  .../commons/io/filefilter/FileFilterTestCase.java   | 12 
>  .../org/apache/commons/io/input/TailerTest.java |  3 ---
>  .../commons/io/monitor/AbstractMonitorTestCase.java |  6 --
>  .../io/output/FileWriterWithEncodingTest.java   |  9 -
>  .../commons/io/output/LockableFileWriterTest.java   | 10 --
>  8 files changed, 77 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/commons-io/blob/
> 68374b28/src/test/java/org/apache/commons/io/FileDeleteStrategyTestCase.
> java
> --
> diff --git a/src/test/java/org/apache/commons/io/
> FileDeleteStrategyTestCase.java b/src/test/java/org/apache/commons/io/
> FileDeleteStrategyTestCase.java
> index 51df9e7..08c378e 100644
> --- a/src/test/java/org/apache/commons/io/FileDeleteStrategyTestCase.java
> +++ b/src/test/java/org/apache/commons/io/FileDeleteStrategyTestCase.java
> @@ -27,7 +27,6 @@ import java.io.FileOutputStream;
>  import java.io.IOException;
>
>  import org.apache.commons.io.testtools.TestUtils;
> -import org.junit.After;
>  import org.junit.Rule;
>  import org.junit.Test;
>  import org.junit.rules.TemporaryFolder;
> @@ -160,10 +159,4 @@ public class FileDeleteStrategyTestCase {
>  assertEquals("FileDeleteStrategy[Normal]",
> FileDeleteStrategy.NORMAL.toString());
>  assertEquals("FileDeleteStrategy[Force]",
> FileDeleteStrategy.FORCE.toString());
>  }
> -
> -@After
> -public void tearDown() throws Exception {
> -FileUtils.deleteDirectory(getTestDirectory());
> -}
> -
>  }
>
> http://git-wip-us.apache.org/repos/asf/commons-io/blob/
> 68374b28/src/test/java/org/apache/commons/io/FilenameUtilsTestCase.java
> --
> diff --git a/src/test/java/org/apache/commons/io/FilenameUtilsTestCase.java
> b/src/test/java/org/apache/commons/io/FilenameUtilsTestCase.java
> index dc69616..dfb9434 100644
> --- a/src/test/java/org/apache/commons/io/FilenameUtilsTestCase.java
> +++ b/src/test/java/org/apache/commons/io/FilenameUtilsTestCase.java
> @@ -30,7 +30,6 @@ import java.util.Arrays;
>  import java.util.Collection;
>
>  import org.apache.commons.io.testtools.TestUtils;
> -import org.junit.After;
>  import org.junit.Before;
>  import org.junit.Rule;
>  import org.junit.Test;
> @@ -46,10 +45,6 @@ public class FilenameUtilsTestCase {
>  @Rule
>  public TemporaryFolder temporaryFolder = new TemporaryFolder();
>
> -private File getTestDirectory() {
> -return temporaryFolder.getRoot();
> -}
> -
>  private static final String SEP = "" + File.separatorChar;
>  private static final boolean WINDOWS = File.separatorChar == '\\';
>
> @@ -59,9 +54,6 @@ public class FilenameUtilsTestCase {
>  private int testFile1Size;
>  private int testFile2Size;
>
> -/**
> - * @see junit.framework.TestCase#setUp()
> - */
>  @Before
>  public void setUp() throws Exception {
>  testFile1 = temporaryFolder.newFile("file1-test.txt");
> @@ -103,14 +95,6 @@ public class FilenameUtilsTestCase {
>  }
>  }
>
> -/**
> - * @see junit.framework.TestCase#tearDown()
> - */
> -@After
> -public void tearDown() throws Exception {
> -temporaryFolder.delete();
> -}
> -
>  //--
> -
>  @Test
>  public void testNormalize() throws Exception {
>
> http://git-wip-us.apache.org/repos/asf/commons-io/blob/
> 68374b28/src/test/java/org/apache/commons/io/comparator/
> ComparatorAbstractTestCase.java
> --
>

Re: [VOTE] Release Apache Commons JCS 2.2.1

2017-09-27 Thread Gary Gregory 
You really need to publish a site for an RC IMO so I can compare your
reports to mine (CLIRR, RAT in particular).

Gary

On Wed, Sep 27, 2017 at 1:40 PM, Romain Manni-Bucau 
wrote:

> Hi Thomas
>
> Didn't run the site one yet - was planned post vote - but did the others
> without the profile since it is configured to be added automatically. Is it
> an issue?
>
> Le 27 sept. 2017 21:06, "Thomas Vandahl"  a écrit :
>
> On 25.09.17 17:47, Gary Gregory wrote:
> > -1
> >
> > The file
> > https://dist.apache.org/repos/dist/dev/commons/jcs/source/
> commons-jcs-dist-2.2.1-src.zip
> > does not contain any of the modules folders.
> >
>
> Hi Romain,
>
> did you do
>   mvn -Duser.name=rmannibucau -Prelease release:prepare
>   mvn -Duser.name=rmannibucau -Prelease release:perform
>   mvn -Duser.name=rmannibucau -Prelease clean site site:stage
> ?
>
> Bye, Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

[GitHub] commons-text issue #64: Minor JavaDoc change for deprecated isDelimiter

2017-09-27 Thread arunvinudss 
Github user arunvinudss commented on the issue:

https://github.com/apache/commons-text/pull/64
  
@chtompki Yes Rob I would definitely vote in the affirmative. Since the 
functionality provided by that method is trivial I would be surprised if anyone 
was using it in the first place. 


---

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

Re: [COLLECTIONS] Test failures on Windows

2017-09-27 Thread Bruno P. Kinoshita 
Forgot to mention something important. When I was debugging the hash tests, 
they would pretty much always pass.
But if I ran the tests normally in maven or eclipse they would always fail.
Debugging adds a small overhead I think, that could be slowing down some part 
of the code with a concurrency issue?
Just in case it helps...
Interesting this surefire configuration Andreas. Do you have more information 
about it? Is it something we may have to worry about in components that use 
locale and jvm 9?
CheersBruno

Sent from Yahoo Mail on Android 
 
  On Thu, 28 Sep 2017 at 4:45, Andreas Kuhtz wrote:   
Hi,

I'm running Win7 and with "mvn clean verify". Checkout master.

I got the hash code errors, too. But sometimes the tests pass, the next
time they failed with 44 failures (the hash code verification).

As I'm not sure if my antivirus kicks in and keep some files in the target
dir, I ran "mvn clean" and after that "mvn clean verify".
But now I have the 44 failures with jdk-1.7.0_67, jdk-1.8.0_131 and 9+181

Gary:
To get around the issue with ServiceConfiguration sun.util.locale...  I
added the following profile to the pom.xml. After that I only got the 44
errors (hash code) as with Java 7 and 8.

    
      jdk9-build
      
        9
      
      
        
          
            maven-surefire-plugin
            
              -Djava.locale.providers=COMPAT
            
          
        
      
    

I'm not sure if I can help more, but if you need more info just let me know.

Andreas

2017-09-27 19:10 GMT+02:00 Gary Gregory :

> Using git master and 'mvn clean verify', on Windows 10, with Java 7, I get
> 44 failures, and I think this is all/mostly hash code problems.
>
> With Java 8, all tests pass.
>
> With Java 9, I get ONE failure: ListIteratorWrapperTest.testRemove:116 ╗
> ServiceConfiguration sun.util.locale
>
> If I checkout the 4.1 tag and use Java 7, I get 44 failures. ARG! What the
> heck?
>
> Gary
>
>
>
> On Mon, Sep 25, 2017 at 12:02 PM, Benedikt Ritter 
> wrote:
>
> > Hi,
> >
> > who can help with the test failures on Windows? I’d like to push out the
> > next release soon to get Collections Java 9 ready. I don’t have access
> to a
> > Windows installation and I don’t feel like debugging inside a VM :o)
> >
> > Regards,
> > Benedikt
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [VOTE] Release Apache Commons JCS 2.2.1

2017-09-27 Thread Thomas Vandahl 
On 27.09.17 21:40, Romain Manni-Bucau wrote:
> Didn't run the site one yet - was planned post vote - but did the others
> without the profile since it is configured to be added automatically. Is it
> an issue?

It might be. I copied these from my actual shell history, so I know them
to work.

Bye, Thomas

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

Re: [VOTE] Release Apache Commons JCS 2.2.1

2017-09-27 Thread Romain Manni-Bucau 
Hi Thomas

Didn't run the site one yet - was planned post vote - but did the others
without the profile since it is configured to be added automatically. Is it
an issue?

Le 27 sept. 2017 21:06, "Thomas Vandahl"  a écrit :

On 25.09.17 17:47, Gary Gregory wrote:
> -1
>
> The file
> https://dist.apache.org/repos/dist/dev/commons/jcs/source/
commons-jcs-dist-2.2.1-src.zip
> does not contain any of the modules folders.
>

Hi Romain,

did you do
  mvn -Duser.name=rmannibucau -Prelease release:prepare
  mvn -Duser.name=rmannibucau -Prelease release:perform
  mvn -Duser.name=rmannibucau -Prelease clean site site:stage
?

Bye, Thomas

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

Re: [IO] Releasing 2.6

2017-09-27 Thread Pascal Schumacher 

Great!

That should reduce the number of random test failures.

I was just taking a look at this and the usage patterns of the folder 
looked horrible. :/


Cheers,
Pascal

Am 27.09.2017 um 21:19 schrieb Gary Gregory:

I updated the tests to use JUnit's TemporaryFolder rule instead of the old
custom and _shared_ folder. No more random errors.

Gary

On Wed, Sep 27, 2017 at 1:05 PM, Pascal Schumacher

Re: [IO] Releasing 2.6

2017-09-27 Thread Gary Gregory 
I updated the tests to use JUnit's TemporaryFolder rule instead of the old
custom and _shared_ folder. No more random errors.

Gary

On Wed, Sep 27, 2017 at 1:05 PM, Pascal Schumacher  wrote:

> Am 27.09.2017 um 19:58 schrieb Gary Gregory:
>
>> I wonder if we need to force Maven to disable any concurrency when running
>> tests?
>>
> That should not be necessary.
>
> Maven/Maven-Surefire-Plugin does not run test in parallel by default. The
> surefire configuration of commons-io does not specify the parallel
> parameter and the forkcount parameter is set to 1 so the tests should be
> executed sequentially.
>
> Cheers,
> Pascal
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [SECURITY] CVE-2017-12621 Apache Commons Jelly connects to URL with custom doctype definitions.

2017-09-27 Thread Rob Tompkins 
Just glad to help. And, it was fun to learn the CVE process.

-Rob


> On Sep 27, 2017, at 2:25 PM, Pascal Schumacher  
> wrote:
> 
> I agree this required a lot of dedication/work.
> 
> Thanks Rob!
> 
> Am 27.09.2017 um 16:29 schrieb Benedikt Ritter:
>> I would like to give kudos to Rob for handling this issue. The kind of 
>> dedication you put into fixing this issue and releasing a component that has 
>> not been touched for ages is what I’m looking for in PMC members.
>> 
>> Great work!
>> Benedikt
>> 
>>> Am 27.09.2017 um 15:05 schrieb Rob Tompkins :
>>> 
>>> CVE-2017-12621: Apache Commons Jelly connects to URL with custom doctype 
>>> definitions.
>>> 
>>> Severity: Medium
>>> 
>>> Vendor:
>>> The Apache Software Foundation
>>> 
>>> Versions Affected:
>>> commons-jelly-1.0 (core), namely commons-jelly-1.0.jar
>>> 
>>> Description:
>>> During Jelly (xml) file parsing with Apache Xerces, if a custom doctype 
>>> entity is declared with a “SYSTEM” entity with a URL and that entity is 
>>> used in the body of the Jelly file, during parser instantiation the parser 
>>> will attempt to connect to said URL. This could lead to XML External Entity 
>>> (XXE) attacks. The Open Web Application Security Project suggests that the 
>>> fix be 
>>> https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet#XMLReader
>>> 
>>> Mitigation:
>>> 1.0 users should migrate to 1.0.1.
>>> 
>>> Example:
>>> 
>>> example.jelly
>>> --
>>> 
>>> 
>>> >>
>>>http://127.0.0.1:/;>
>>>]>
>>> 
>>> >> xmlns:x="jelly:xml"
>>> xmlns:html="jelly:html">
>>> 
>>> --
>>> 
>>> ExampleParser.java
>>> --
>>> public class ExampleParser {
>>> 
>>> public static void main(String[] args) throws JellyException, 
>>> IOException,
>>> NoSuchMethodException, 
>>> IllegalAccessException,IllegalArgumentException,
>>> InvocationTargetException {
>>> JellyContext context = new JellyContext();
>>> context.runScript("example.jelly", null);
>>> }
>>> }
>>> 
>>> Credit:
>>> This was discovered by Luca Carettoni of Doyensec.
>>> 
>>> References:
>>> [1] http://commons.apache.org/jelly/security-reports.html
>>> [2] https://issues.apache.org/jira/browse/JELLY-293
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [VOTE] Release Apache Commons JCS 2.2.1

2017-09-27 Thread Thomas Vandahl 
On 25.09.17 17:47, Gary Gregory wrote:
> -1
> 
> The file
> https://dist.apache.org/repos/dist/dev/commons/jcs/source/commons-jcs-dist-2.2.1-src.zip
> does not contain any of the modules folders.
> 

Hi Romain,

did you do
  mvn -Duser.name=rmannibucau -Prelease release:prepare
  mvn -Duser.name=rmannibucau -Prelease release:perform
  mvn -Duser.name=rmannibucau -Prelease clean site site:stage
?

Bye, Thomas

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

[GitHub] commons-text issue #64: Minor JavaDoc change for deprecated isDelimiter

2017-09-27 Thread chtompki 
Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/64
  
@arunvinudss - would you vote for removing it if we were to roll a, very 
hypothetical, 2.0 right now? If so, then I'd say we have our decision.


---

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

Re: [IO] Releasing 2.6

2017-09-27 Thread Pascal Schumacher 

Am 27.09.2017 um 19:58 schrieb Gary Gregory:

I wonder if we need to force Maven to disable any concurrency when running
tests?

That should not be necessary.

Maven/Maven-Surefire-Plugin does not run test in parallel by default. 
The surefire configuration of commons-io does not specify the parallel 
parameter and the forkcount parameter is set to 1 so the tests should be 
executed sequentially.


Cheers,
Pascal

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

[GitHub] commons-text issue #62: TEXT-101: Moved RandomStringUtils to Commons-text

2017-09-27 Thread chtompki 
Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/62
  
As I'm pulling this in this crosses my mind: 

Wait I'm curious here. Weren't folks leaning towards keeping 
`RandomStringUtils` in `[lang]`?

The thread in question is this one: 
http://markmail.org/message/5tblwhldrwsbfdym

It feels like @britter, @PascalSchumacher, and @garydgregory were all 
leaning towards the `[lang]` option. If that's the case we should probably go 
with that.


---

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

Re: [COLLECTIONS] Test failures on Windows

2017-09-27 Thread Andreas Kuhtz 
Hi,

I'm running Win7 and with "mvn clean verify". Checkout master.

I got the hash code errors, too. But sometimes the tests pass, the next
time they failed with 44 failures (the hash code verification).

As I'm not sure if my antivirus kicks in and keep some files in the target
dir, I ran "mvn clean" and after that "mvn clean verify".
But now I have the 44 failures with jdk-1.7.0_67, jdk-1.8.0_131 and 9+181

Gary:
To get around the issue with ServiceConfiguration sun.util.locale...  I
added the following profile to the pom.xml. After that I only got the 44
errors (hash code) as with Java 7 and 8.


  jdk9-build
  
9
  
  

  
maven-surefire-plugin

  -Djava.locale.providers=COMPAT

  

  


I'm not sure if I can help more, but if you need more info just let me know.

Andreas

2017-09-27 19:10 GMT+02:00 Gary Gregory :

> Using git master and 'mvn clean verify', on Windows 10, with Java 7, I get
> 44 failures, and I think this is all/mostly hash code problems.
>
> With Java 8, all tests pass.
>
> With Java 9, I get ONE failure: ListIteratorWrapperTest.testRemove:116 ╗
> ServiceConfiguration sun.util.locale
>
> If I checkout the 4.1 tag and use Java 7, I get 44 failures. ARG! What the
> heck?
>
> Gary
>
>
>
> On Mon, Sep 25, 2017 at 12:02 PM, Benedikt Ritter 
> wrote:
>
> > Hi,
> >
> > who can help with the test failures on Windows? I’d like to push out the
> > next release soon to get Collections Java 9 ready. I don’t have access
> to a
> > Windows installation and I don’t feel like debugging inside a VM :o)
> >
> > Regards,
> > Benedikt
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [SECURITY] CVE-2017-12621 Apache Commons Jelly connects to URL with custom doctype definitions.

2017-09-27 Thread Pascal Schumacher 

I agree this required a lot of dedication/work.

Thanks Rob!

Am 27.09.2017 um 16:29 schrieb Benedikt Ritter:

I would like to give kudos to Rob for handling this issue. The kind of 
dedication you put into fixing this issue and releasing a component that has 
not been touched for ages is what I’m looking for in PMC members.

Great work!
Benedikt


Am 27.09.2017 um 15:05 schrieb Rob Tompkins :

CVE-2017-12621: Apache Commons Jelly connects to URL with custom doctype 
definitions.

Severity: Medium

Vendor:
The Apache Software Foundation

Versions Affected:
commons-jelly-1.0 (core), namely commons-jelly-1.0.jar

Description:
During Jelly (xml) file parsing with Apache Xerces, if a custom doctype entity 
is declared with a “SYSTEM” entity with a URL and that entity is used in the 
body of the Jelly file, during parser instantiation the parser will attempt to 
connect to said URL. This could lead to XML External Entity (XXE) attacks. The 
Open Web Application Security Project suggests that the fix be 
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet#XMLReader

Mitigation:
1.0 users should migrate to 1.0.1.

Example:

example.jelly
--



http://127.0.0.1:/;>
]>



--

ExampleParser.java
--
public class ExampleParser {

public static void main(String[] args) throws JellyException, 
IOException,
NoSuchMethodException, 
IllegalAccessException,IllegalArgumentException,
InvocationTargetException {
JellyContext context = new JellyContext();
context.runScript("example.jelly", null);
}
}

Credit:
This was discovered by Luca Carettoni of Doyensec.

References:
[1] http://commons.apache.org/jelly/security-reports.html
[2] https://issues.apache.org/jira/browse/JELLY-293


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



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




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

Re: [IO] Releasing 2.6

2017-09-27 Thread Gary Gregory 
Actually, we should not manage our own test folder, we should let JUnit do
with the TemporaryFolder rule...

Gary

On Wed, Sep 27, 2017 at 11:58 AM, Gary Gregory 
wrote:

> But I am also seeing random failures trying to set up and teardown the
> test directory. For example:
>
> java.lang.AssertionError: Could not create directory
> C:\vcs\git\apache\commons\commons-io\target\test_io
> at org.apache.commons.io.IOUtilsTestCase.setUp(
> IOUtilsTestCase.java:80)
>
> testAsBufferedReader(org.apache.commons.io.IOUtilsTestCase)  Time
> elapsed: 0.016 sec  <<< FAILURE!
> java.lang.AssertionError: Could not create directory
> C:\vcs\git\apache\commons\commons-io\target\test_io
> at org.apache.commons.io.IOUtilsTestCase.tearDown(
> IOUtilsTestCase.java:116)
>
> I wonder if we need to force Maven to disable any concurrency when running
> tests?
>
> Gary
>
>
> On Wed, Sep 27, 2017 at 11:49 AM, Gary Gregory 
> wrote:
>
>> I fixed that failure with some Git magic.
>>
>> Gary
>>
>> On Wed, Sep 27, 2017 at 12:32 AM, Benedikt Ritter 
>> wrote:
>>
>>>
>>> > Am 27.09.2017 um 00:16 schrieb Gary Gregory :
>>> >
>>> > This test fails on Windows:
>>>
>>> Can’t we just drop Windows support? :(
>>>
>>> Do you have some time to investigate this?
>>>
>>> Cheers,
>>> Benedikt
>>>
>>> >
>>> > org.apache.commons.io.FileUtilsTestCase
>>> >
>>> > FileUtilsTestCase
>>> > org.apache.commons.io.FileUtilsTestCase
>>> > testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
>>> > java.lang.AssertionError
>>> >
>>> > at org.junit.Assert.fail(Assert.java:86)
>>> >
>>> > at org.junit.Assert.assertTrue(Assert.java:41)
>>> >
>>> > at org.junit.Assert.assertFalse(Assert.java:64)
>>> >
>>> > at org.junit.Assert.assertFalse(Assert.java:74)
>>> >
>>> > at
>>> > org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgn
>>> oreEOL(FileUtilsTestCase.java:681)
>>> >
>>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> >
>>> > at
>>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>> ssorImpl.java:57)
>>> >
>>> > at
>>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> thodAccessorImpl.java:43)
>>> >
>>> > at java.lang.reflect.Method.invoke(Method.java:606)
>>> >
>>> > at
>>> > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
>>> FrameworkMethod.java:50)
>>> >
>>> > at
>>> > org.junit.internal.runners.model.ReflectiveCallable.run(Refl
>>> ectiveCallable.java:12)
>>> >
>>> > at
>>> > org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr
>>> ameworkMethod.java:47)
>>> >
>>> > at
>>> > org.junit.internal.runners.statements.InvokeMethod.evaluate(
>>> InvokeMethod.java:17)
>>> >
>>> > at
>>> > org.junit.internal.runners.statements.RunBefores.evaluate(Ru
>>> nBefores.java:26)
>>> >
>>> > at
>>> > org.junit.internal.runners.statements.RunAfters.evaluate(Run
>>> Afters.java:27)
>>> >
>>> > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>> >
>>> > at
>>> > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>>> 4ClassRunner.java:78)
>>> >
>>> > at
>>> > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>>> 4ClassRunner.java:57)
>>> >
>>> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>> >
>>> > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>> >
>>> > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>> >
>>> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>> >
>>> > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>> >
>>> > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.r
>>> un(JUnit4TestReference.java:86)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test
>>> Execution.java:38)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
>>> sts(RemoteTestRunner.java:539)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
>>> sts(RemoteTestRunner.java:761)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R
>>> emoteTestRunner.java:461)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
>>> RemoteTestRunner.java:207)
>>> >
>>> >
>>> > Gary
>>> >
>>> > On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter 
>>> wrote:
>>> >
>>> >> Hey,
>>> >>
>>> >> I’m going through the list of components I happen to work with and
>>> make
>>> >> them ready for Java 9. Since I’m blocked in the release process of
>>> >> collections because of the Windows test failures, I’m going to cut a
>>> RC for
>>> >> IO 2.6 probably tomorrow night.
>>> >>
>>> >> Regards,
>>> >> Benedikt
>>> >> -
>>> >> To unsubscribe, e-mail:

Re: [IO] Releasing 2.6

2017-09-27 Thread Gary Gregory 
But I am also seeing random failures trying to set up and teardown the test
directory. For example:

java.lang.AssertionError: Could not create directory
C:\vcs\git\apache\commons\commons-io\target\test_io
at
org.apache.commons.io.IOUtilsTestCase.setUp(IOUtilsTestCase.java:80)

testAsBufferedReader(org.apache.commons.io.IOUtilsTestCase)  Time elapsed:
0.016 sec  <<< FAILURE!
java.lang.AssertionError: Could not create directory
C:\vcs\git\apache\commons\commons-io\target\test_io
at
org.apache.commons.io.IOUtilsTestCase.tearDown(IOUtilsTestCase.java:116)

I wonder if we need to force Maven to disable any concurrency when running
tests?

Gary


On Wed, Sep 27, 2017 at 11:49 AM, Gary Gregory 
wrote:

> I fixed that failure with some Git magic.
>
> Gary
>
> On Wed, Sep 27, 2017 at 12:32 AM, Benedikt Ritter 
> wrote:
>
>>
>> > Am 27.09.2017 um 00:16 schrieb Gary Gregory :
>> >
>> > This test fails on Windows:
>>
>> Can’t we just drop Windows support? :(
>>
>> Do you have some time to investigate this?
>>
>> Cheers,
>> Benedikt
>>
>> >
>> > org.apache.commons.io.FileUtilsTestCase
>> >
>> > FileUtilsTestCase
>> > org.apache.commons.io.FileUtilsTestCase
>> > testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
>> > java.lang.AssertionError
>> >
>> > at org.junit.Assert.fail(Assert.java:86)
>> >
>> > at org.junit.Assert.assertTrue(Assert.java:41)
>> >
>> > at org.junit.Assert.assertFalse(Assert.java:64)
>> >
>> > at org.junit.Assert.assertFalse(Assert.java:74)
>> >
>> > at
>> > org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgn
>> oreEOL(FileUtilsTestCase.java:681)
>> >
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >
>> > at
>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:57)
>> >
>> > at
>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> >
>> > at java.lang.reflect.Method.invoke(Method.java:606)
>> >
>> > at
>> > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
>> FrameworkMethod.java:50)
>> >
>> > at
>> > org.junit.internal.runners.model.ReflectiveCallable.run(Refl
>> ectiveCallable.java:12)
>> >
>> > at
>> > org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr
>> ameworkMethod.java:47)
>> >
>> > at
>> > org.junit.internal.runners.statements.InvokeMethod.evaluate(
>> InvokeMethod.java:17)
>> >
>> > at
>> > org.junit.internal.runners.statements.RunBefores.evaluate(
>> RunBefores.java:26)
>> >
>> > at
>> > org.junit.internal.runners.statements.RunAfters.evaluate(Run
>> Afters.java:27)
>> >
>> > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>> >
>> > at
>> > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>> 4ClassRunner.java:78)
>> >
>> > at
>> > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>> 4ClassRunner.java:57)
>> >
>> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>> >
>> > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>> >
>> > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>> >
>> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>> >
>> > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>> >
>> > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.
>> run(JUnit4TestReference.java:86)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit.runner.TestExecution.run(
>> TestExecution.java:38)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
>> sts(RemoteTestRunner.java:539)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
>> sts(RemoteTestRunner.java:761)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
>> RemoteTestRunner.java:461)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
>> RemoteTestRunner.java:207)
>> >
>> >
>> > Gary
>> >
>> > On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter 
>> wrote:
>> >
>> >> Hey,
>> >>
>> >> I’m going through the list of components I happen to work with and make
>> >> them ready for Java 9. Since I’m blocked in the release process of
>> >> collections because of the Windows test failures, I’m going to cut a
>> RC for
>> >> IO 2.6 probably tomorrow night.
>> >>
>> >> Regards,
>> >> Benedikt
>> >> -
>> >> 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: [IO] Releasing 2.6

2017-09-27 Thread Gary Gregory 
I fixed that failure with some Git magic.

Gary

On Wed, Sep 27, 2017 at 12:32 AM, Benedikt Ritter 
wrote:

>
> > Am 27.09.2017 um 00:16 schrieb Gary Gregory :
> >
> > This test fails on Windows:
>
> Can’t we just drop Windows support? :(
>
> Do you have some time to investigate this?
>
> Cheers,
> Benedikt
>
> >
> > org.apache.commons.io.FileUtilsTestCase
> >
> > FileUtilsTestCase
> > org.apache.commons.io.FileUtilsTestCase
> > testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
> > java.lang.AssertionError
> >
> > at org.junit.Assert.fail(Assert.java:86)
> >
> > at org.junit.Assert.assertTrue(Assert.java:41)
> >
> > at org.junit.Assert.assertFalse(Assert.java:64)
> >
> > at org.junit.Assert.assertFalse(Assert.java:74)
> >
> > at
> > org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(
> FileUtilsTestCase.java:681)
> >
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:57)
> >
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> >
> > at java.lang.reflect.Method.invoke(Method.java:606)
> >
> > at
> > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:50)
> >
> > at
> > org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
> >
> > at
> > org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:47)
> >
> > at
> > org.junit.internal.runners.statements.InvokeMethod.
> evaluate(InvokeMethod.java:17)
> >
> > at
> > org.junit.internal.runners.statements.RunBefores.
> evaluate(RunBefores.java:26)
> >
> > at
> > org.junit.internal.runners.statements.RunAfters.evaluate(
> RunAfters.java:27)
> >
> > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> >
> > at
> > org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:78)
> >
> > at
> > org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:57)
> >
> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> >
> > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> >
> > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> >
> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> >
> > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> >
> > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> >
> > at
> > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(
> JUnit4TestReference.java:86)
> >
> > at
> > org.eclipse.jdt.internal.junit.runner.TestExecution.
> run(TestExecution.java:38)
> >
> > at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> runTests(RemoteTestRunner.java:539)
> >
> > at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> runTests(RemoteTestRunner.java:761)
> >
> > at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> run(RemoteTestRunner.java:461)
> >
> > at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> main(RemoteTestRunner.java:207)
> >
> >
> > Gary
> >
> > On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter 
> wrote:
> >
> >> Hey,
> >>
> >> I’m going through the list of components I happen to work with and make
> >> them ready for Java 9. Since I’m blocked in the release process of
> >> collections because of the Windows test failures, I’m going to cut a RC
> for
> >> IO 2.6 probably tomorrow night.
> >>
> >> Regards,
> >> Benedikt
> >> -
> >> 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: [COLLECTIONS] Test failures on Windows

2017-09-27 Thread Gary Gregory 
Using git master and 'mvn clean verify', on Windows 10, with Java 7, I get
44 failures, and I think this is all/mostly hash code problems.

With Java 8, all tests pass.

With Java 9, I get ONE failure: ListIteratorWrapperTest.testRemove:116 ╗
ServiceConfiguration sun.util.locale

If I checkout the 4.1 tag and use Java 7, I get 44 failures. ARG! What the
heck?

Gary



On Mon, Sep 25, 2017 at 12:02 PM, Benedikt Ritter 
wrote:

> Hi,
>
> who can help with the test failures on Windows? I’d like to push out the
> next release soon to get Collections Java 9 ready. I don’t have access to a
> Windows installation and I don’t feel like debugging inside a VM :o)
>
> Regards,
> Benedikt
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [SECURITY] CVE-2017-12621 Apache Commons Jelly connects to URL with custom doctype definitions.

2017-09-27 Thread Gary Gregory 
On Wed, Sep 27, 2017 at 8:29 AM, Benedikt Ritter  wrote:

> I would like to give kudos to Rob for handling this issue. The kind of
> dedication you put into fixing this issue and releasing a component that
> has not been touched for ages is what I’m looking for in PMC members.
>
> Great work!
>

+1

Gary


> Benedikt
>
> > Am 27.09.2017 um 15:05 schrieb Rob Tompkins :
> >
> > CVE-2017-12621: Apache Commons Jelly connects to URL with custom doctype
> definitions.
> >
> > Severity: Medium
> >
> > Vendor:
> > The Apache Software Foundation
> >
> > Versions Affected:
> > commons-jelly-1.0 (core), namely commons-jelly-1.0.jar
> >
> > Description:
> > During Jelly (xml) file parsing with Apache Xerces, if a custom doctype
> entity is declared with a “SYSTEM” entity with a URL and that entity is
> used in the body of the Jelly file, during parser instantiation the parser
> will attempt to connect to said URL. This could lead to XML External Entity
> (XXE) attacks. The Open Web Application Security Project suggests that the
> fix be https://www.owasp.org/index.php/XML_External_Entity_(XXE)_
> Prevention_Cheat_Sheet#XMLReader
> >
> > Mitigation:
> > 1.0 users should migrate to 1.0.1.
> >
> > Example:
> >
> > example.jelly
> > --
> > 
> > 
> >  >
> >http://127.0.0.1:/;>
> >]>
> > 
> >  > xmlns:x="jelly:xml"
> > xmlns:html="jelly:html">
> > 
> > --
> >
> > ExampleParser.java
> > --
> > public class ExampleParser {
> >
> >   public static void main(String[] args) throws JellyException,
> IOException,
> >   NoSuchMethodException,
> IllegalAccessException,IllegalArgumentException,
> >   InvocationTargetException {
> >   JellyContext context = new JellyContext();
> >   context.runScript("example.jelly", null);
> >   }
> > }
> >
> > Credit:
> > This was discovered by Luca Carettoni of Doyensec.
> >
> > References:
> > [1] http://commons.apache.org/jelly/security-reports.html
> > [2] https://issues.apache.org/jira/browse/JELLY-293
> >
> >
> > -
> > 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: [SECURITY] CVE-2017-12621 Apache Commons Jelly connects to URL with custom doctype definitions.

2017-09-27 Thread Benedikt Ritter 
I would like to give kudos to Rob for handling this issue. The kind of 
dedication you put into fixing this issue and releasing a component that has 
not been touched for ages is what I’m looking for in PMC members.

Great work!
Benedikt

> Am 27.09.2017 um 15:05 schrieb Rob Tompkins :
> 
> CVE-2017-12621: Apache Commons Jelly connects to URL with custom doctype 
> definitions.
> 
> Severity: Medium
> 
> Vendor:
> The Apache Software Foundation
> 
> Versions Affected:
> commons-jelly-1.0 (core), namely commons-jelly-1.0.jar
> 
> Description:
> During Jelly (xml) file parsing with Apache Xerces, if a custom doctype 
> entity is declared with a “SYSTEM” entity with a URL and that entity is used 
> in the body of the Jelly file, during parser instantiation the parser will 
> attempt to connect to said URL. This could lead to XML External Entity (XXE) 
> attacks. The Open Web Application Security Project suggests that the fix be 
> https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet#XMLReader
> 
> Mitigation:
> 1.0 users should migrate to 1.0.1.
> 
> Example:
> 
> example.jelly
> --
> 
> 
> 
>http://127.0.0.1:/;>
>]>
> 
>  xmlns:x="jelly:xml"
> xmlns:html="jelly:html">
> 
> --
> 
> ExampleParser.java
> --
> public class ExampleParser {
>   
>   public static void main(String[] args) throws JellyException, 
> IOException, 
>   NoSuchMethodException, 
> IllegalAccessException,IllegalArgumentException, 
>   InvocationTargetException {
>   JellyContext context = new JellyContext();
>   context.runScript("example.jelly", null);
>   }
> }
> 
> Credit:
> This was discovered by Luca Carettoni of Doyensec.
> 
> References:
> [1] http://commons.apache.org/jelly/security-reports.html
> [2] https://issues.apache.org/jira/browse/JELLY-293
> 
> 
> -
> 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

[SECURITY] CVE-2017-12621 Apache Commons Jelly connects to URL with custom doctype definitions.

2017-09-27 Thread Rob Tompkins 
CVE-2017-12621: Apache Commons Jelly connects to URL with custom doctype 
definitions.

Severity: Medium

Vendor:
The Apache Software Foundation

Versions Affected:
commons-jelly-1.0 (core), namely commons-jelly-1.0.jar

Description:
During Jelly (xml) file parsing with Apache Xerces, if a custom doctype entity 
is declared with a “SYSTEM” entity with a URL and that entity is used in the 
body of the Jelly file, during parser instantiation the parser will attempt to 
connect to said URL. This could lead to XML External Entity (XXE) attacks. The 
Open Web Application Security Project suggests that the fix be 
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet#XMLReader

Mitigation:
1.0 users should migrate to 1.0.1.

Example:

example.jelly
--



http://127.0.0.1:/;>
]>



--

ExampleParser.java
--
public class ExampleParser {

public static void main(String[] args) throws JellyException, 
IOException, 
NoSuchMethodException, 
IllegalAccessException,IllegalArgumentException, 
InvocationTargetException {
JellyContext context = new JellyContext();
context.runScript("example.jelly", null);
}
}

Credit:
This was discovered by Luca Carettoni of Doyensec.

References:
[1] http://commons.apache.org/jelly/security-reports.html
[2] https://issues.apache.org/jira/browse/JELLY-293


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

[ANNOUNCE] Apache Commons Jelly 1.0.1 released!

2017-09-27 Thread Rob Tompkins 
The Apache Commons Team is pleased to announce the release of Apache
Commons Jelly 1.0.1.

Jelly is a tool for turning XML into executable code. So Jelly is a 
Java and XML based scripting and processing engine. Jelly can be used 
as a more flexible and powerful front end to Ant such as in the Maven 1.X 
project, as a testing framework such as JellyUnit, in an intergration 
or workflow system such as werkflow or as a page templating system 
inside engines like Cocoon.

1.0.1 is fully binary compatible to the last release. No client code
changes are required to migrate from version 1.0 to 1.0.1.

This release only includes one bug fix, JELLY-293: Accommodate toggling 
off DTD external entities.

Source and binary distributions are available for download from the Apache
Commons download site:
  http://commons.apache.org/proper/commons-jelly/download_jelly.cgi

When downloading, please verify signatures using the KEYS file available at
the above location when downloading the release.

Alternatively the release can be pulled via maven:
  commons-jelly
  commons-jelly
  1.0.1

Full details of all the changes in 1.0.1 can be found in the changelog:
  http://commons.apache.org/proper/commons-jelly/changes-report.html

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

http://commons.apache.org/proper/commons-jelly/

Rob Tompkins,
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

[GitHub] commons-text issue #62: TEXT-101: Moved RandomStringUtils to Commons-text

2017-09-27 Thread chtompki 
Github user chtompki commented on the issue:

https://github.com/apache/commons-text/pull/62
  
Should be able to look again today.


---

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

Re: [IO] Releasing 2.6

2017-09-27 Thread sebb 
The current Jenkins build uses Windows:


https://builds.apache.org/view/A-D/view/Commons/job/commons-io/58/

Last few runs were successful.

On 27 September 2017 at 08:46, Pascal Schumacher
 wrote:
> Strange.
>
> I just ran the commons-io test three times on windows 10 and every run was
> successful.
>
> Are you sure that you are not seeing on of the occasional failures that the
> io test suffer from?
>
>
> Am 27.09.2017 um 00:16 schrieb Gary Gregory:
>>
>> This test fails on Windows:
>>
>> org.apache.commons.io.FileUtilsTestCase
>>
>> FileUtilsTestCase
>> org.apache.commons.io.FileUtilsTestCase
>> testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
>> java.lang.AssertionError
>>
>> at org.junit.Assert.fail(Assert.java:86)
>>
>> at org.junit.Assert.assertTrue(Assert.java:41)
>>
>> at org.junit.Assert.assertFalse(Assert.java:64)
>>
>> at org.junit.Assert.assertFalse(Assert.java:74)
>>
>> at
>>
>> org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(FileUtilsTestCase.java:681)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at
>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>
>> at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>> at java.lang.reflect.Method.invoke(Method.java:606)
>>
>> at
>>
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>
>> at
>>
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>
>> at
>>
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>>
>> at
>>
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>>
>> at
>>
>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>>
>> at
>>
>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>>
>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>
>> at
>>
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>
>> at
>>
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>
>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>
>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>
>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>
>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207)
>>
>>
>> Gary
>>
>> On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter 
>> wrote:
>>
>>> Hey,
>>>
>>> I’m going through the list of components I happen to work with and make
>>> them ready for Java 9. Since I’m blocked in the release process of
>>> collections because of the Windows test failures, I’m going to cut a RC
>>> for
>>> IO 2.6 probably tomorrow night.
>>>
>>> Regards,
>>> Benedikt
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [LOGGING] Release with Java 9 Module support

2017-09-27 Thread Stephen Colebourne 
On 27 September 2017 at 00:01, Emmanuel Bourg  wrote:
> I wonder if we should do the same for commons-lang 2.x, it's still
> commonly used.

Yes. This would be very helpful
Stephen

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

Re: [VOTE] Release Apache Commons JCS 2.2.1

2017-09-27 Thread Romain Manni-Bucau 
Have to admit I'm not 100% sure how dist module is intended to work
(probably a 2 phases build?) but since we don't deploy it on maven I can
probably update it in dist without cancelling the release? That said would
need some help for it.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-09-25 17:47 GMT+02:00 Gary Gregory :

> -1
>
> The file
> https://dist.apache.org/repos/dist/dev/commons/jcs/source/
> commons-jcs-dist-2.2.1-src.zip
> does not contain any of the modules folders.
>
> Gary
>
> On Sun, Sep 24, 2017 at 5:01 AM, Romain Manni-Bucau  >
> wrote:
>
> > As announced on the list, I would like to release the [jcs] component to
> > resolve a cdi performance issue (
> > https://issues.apache.org/jira/browse/JCS-183).
> >
> >  Maven artifacts are at:
> > https://repository.apache.org/content/repositories/
> orgapachecommons-1269/
> >
> >  The Subversion tag is:
> > http://svn.apache.org/repos/asf/commons/proper/jcs/tags/
> commons-jcs-2.2.1/
> >
> >  The release notes are available at:
> > http://svn.apache.org/repos/asf/commons/proper/jcs/tags/
> > commons-jcs-2.2.1/RELEASE-NOTES.txt
> >
> >  The staged sources and binaries are available at
> > https://dist.apache.org/repos/dist/dev/commons/jcs/
> >
> >  Please review the release candidate and vote.
> >
> >[ ] +1 Release these artifacts
> >[ ] +-0 don't care
> >[ ] -1 I oppose this release because ${reason}
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  > rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
>

Re: [IO] Releasing 2.6

2017-09-27 Thread Pascal Schumacher 

Strange.

I just ran the commons-io test three times on windows 10 and every run 
was successful.


Are you sure that you are not seeing on of the occasional failures that 
the io test suffer from?


Am 27.09.2017 um 00:16 schrieb Gary Gregory:

This test fails on Windows:

org.apache.commons.io.FileUtilsTestCase

FileUtilsTestCase
org.apache.commons.io.FileUtilsTestCase
testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
java.lang.AssertionError

at org.junit.Assert.fail(Assert.java:86)

at org.junit.Assert.assertTrue(Assert.java:41)

at org.junit.Assert.assertFalse(Assert.java:64)

at org.junit.Assert.assertFalse(Assert.java:74)

at
org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(FileUtilsTestCase.java:681)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)

at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)

at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)

at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)

at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)

at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)

at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)

at org.junit.runners.ParentRunner.run(ParentRunner.java:363)

at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)

at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207)


Gary

On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter  wrote:


Hey,

I’m going through the list of components I happen to work with and make
them ready for Java 9. Since I’m blocked in the release process of
collections because of the Windows test failures, I’m going to cut a RC for
IO 2.6 probably tomorrow night.

Regards,
Benedikt
-
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: [IO] Releasing 2.6

2017-09-27 Thread Benedikt Ritter 

> Am 27.09.2017 um 00:16 schrieb Gary Gregory :
> 
> This test fails on Windows:

Can’t we just drop Windows support? :(

Do you have some time to investigate this?

Cheers,
Benedikt

> 
> org.apache.commons.io.FileUtilsTestCase
> 
> FileUtilsTestCase
> org.apache.commons.io.FileUtilsTestCase
> testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
> java.lang.AssertionError
> 
> at org.junit.Assert.fail(Assert.java:86)
> 
> at org.junit.Assert.assertTrue(Assert.java:41)
> 
> at org.junit.Assert.assertFalse(Assert.java:64)
> 
> at org.junit.Assert.assertFalse(Assert.java:74)
> 
> at
> org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(FileUtilsTestCase.java:681)
> 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 
> at java.lang.reflect.Method.invoke(Method.java:606)
> 
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> 
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539)
> 
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761)
> 
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461)
> 
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207)
> 
> 
> Gary
> 
> On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter  wrote:
> 
>> Hey,
>> 
>> I’m going through the list of components I happen to work with and make
>> them ready for Java 9. Since I’m blocked in the release process of
>> collections because of the Windows test failures, I’m going to cut a RC for
>> IO 2.6 probably tomorrow night.
>> 
>> Regards,
>> Benedikt
>> -
>> 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