[jira] [Created] (COMPRESS-371) LZString compression/decompression support

[Philippe Mouawad (JIRA)]

Philippe Mouawad created COMPRESS-371:
-

 Summary: LZString compression/decompression support
 Key: COMPRESS-371
 URL: https://issues.apache.org/jira/browse/COMPRESS-371
 Project: Commons Compress
  Issue Type: Improvement
  Components: Compressors
Affects Versions: 1.12
Reporter: Philippe Mouawad


Hello,
LZString compression has some use in JS world (Mobile, Node.JS...) at least and 
currently there is no official and robust support for it in Java.

http://pieroxy.net/blog/pages/lz-string/index.html


It would be nice to have a reference implementation for it in commons-compress.
Thanks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COMPRESS-370) Support Brotli compression

[Philippe Mouawad (JIRA)]

Philippe Mouawad created COMPRESS-370:
-

 Summary: Support Brotli compression
 Key: COMPRESS-370
 URL: https://issues.apache.org/jira/browse/COMPRESS-370
 Project: Commons Compress
  Issue Type: Improvement
  Components: Compressors
Affects Versions: 1.12
Reporter: Philippe Mouawad


Brotli compression is being nowadays used by Servers:
https://en.wikipedia.org/wiki/Brotli

It would be very interesting to have it developed as it could be at least used 
by Apache HttpClient => Apache JMeter and I'm sure a lot of other projects may 
take advantage of it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COMMONSSITE-90) Add option to include badges in the README.md file

[Gary Gregory (JIRA)]

Gary Gregory created COMMONSSITE-90:
---

 Summary: Add option to include badges in the README.md file
 Key: COMMONSSITE-90
 URL: https://issues.apache.org/jira/browse/COMMONSSITE-90
 Project: Commons All
  Issue Type: New Feature
  Components: Commons Build Plugin
Reporter: Gary Gregory


Add option to include badges in the README.md file

For example from Commons Lang:

{noformat}
Apache Commons Lang
===

[![Build 
Status](https://travis-ci.org/apache/commons-lang.svg?branch=master)](https://travis-ci.org/apache/commons-lang)
[![Coverage 
Status](https://coveralls.io/repos/apache/commons-lang/badge.svg?branch=master)](https://coveralls.io/r/apache/commons-lang)
[![Maven 
Central](https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-lang3/badge.svg)](https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-lang3/)
[![License](http://img.shields.io/:license-apache-blue.svg)](http://www.apache.org/licenses/LICENSE-2.0.html)
...
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (COMPRESS-369) Allow archiver extensions through a standard JRE ServiceLoader

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated COMPRESS-369:
--
Description: 
Allow archiver extensions through a standard JRE ServiceLoader.

Introduce a new interface 
{{org.apache.commons.compress.archivers.ArchiveStreamProvider}}.

Update {{ArchiveStreamFactory}} to implement this new interface and use a 
service loader to pick up extra {{ArchiveStreamProvider}}.

The service loader file is 
{{META-INF/services/org.apache.commons.compress.archivers.ArchiveStreamProvider}}

The new interface:

{code:java}
/*
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 */

package org.apache.commons.compress.archivers;

import java.io.InputStream;
import java.io.OutputStream;
import java.util.Set;

/**
 * Creates Archive {@link ArchiveInputStream}s and {@link ArchiveOutputStream}s.
 * 
 * @since 1.13
 */
public interface ArchiveStreamProvider {

/**
 * Creates an archive input stream from an archiver name and an input
 * stream.
 * 
 * @param archiverName
 *the archive name, i.e. {@value #AR}, {@value #ARJ},
 *{@value #ZIP}, {@value #TAR}, {@value #JAR}, {@value #CPIO},
 *{@value #DUMP} or {@value #SEVEN_Z}
 * @param in
 *the input stream
 * @param encoding,
 *or null for the default
 * @return the archive input stream
 * @throws ArchiveException
 * if the archiver name is not known
 * @throws StreamingNotSupportedException
 * if the format cannot be read from a stream
 * @throws IllegalArgumentException
 * if the archiver name or stream is null
 */
ArchiveInputStream createArchiveInputStream(final String name, final 
InputStream in, final String encoding)
throws ArchiveException;

/**
 * Creates an archive output stream from an archiver name and an output
 * stream.
 * 
 * @param archiverName
 *the archive name, i.e. {@value #AR}, {@value #ZIP},
 *{@value #TAR}, {@value #JAR} or {@value #CPIO}
 * @param out
 *the output stream
 * @param encoding,
 *or null for the default
 * @return the archive output stream
 * @throws ArchiveException
 * if the archiver name is not known
 * @throws StreamingNotSupportedException
 * if the format cannot be written to a stream
 * @throws IllegalArgumentException
 * if the archiver name or stream is null
 */
ArchiveOutputStream createArchiveOutputStream(final String name, final 
OutputStream out, final String encoding)
throws ArchiveException;

/**
 * Gets all the input stream archive names for this provider
 * 
 * @return all the input archive names for this provider
 */
Set getInputStreamArchiveNames();

/**
 * Gets all the output stream archive names for this provider
 * 
 * @return all the output archive names for this provider
 */
Set getOutputStreamArchiveNames();

}
{code}

  was:
Allow archiver extensions through a standard JRE ServiceLoader.

Introduce a new interface 
{{org.apache.commons.compress.archivers.ArchiveStreamProvider}}/

Update {{ArchiveStreamFactory}} to implement this new interface and use a 
service loader to pick up extra {{ArchiveStreamProvider}}.

The service loader file is 
{{META-INF/services/org.apache.commons.compress.archivers.ArchiveStreamProvider}}

The new interface:

{code:java}
/*
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed 

[jira] [Updated] (COMPRESS-369) Allow archiver extensions through a standard JRE ServiceLoader

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated COMPRESS-369:
--
Description: 
Allow archiver extensions through a standard JRE ServiceLoader.

Introduce a new interface 
{{org.apache.commons.compress.archivers.ArchiveStreamProvider}}/

Update {{ArchiveStreamFactory}} to implement this new interface and use a 
service loader to pick up extra {{ArchiveStreamProvider}}.

The service loader file is 
{{META-INF/services/org.apache.commons.compress.archivers.ArchiveStreamProvider}}

The new interface:

{code:java}
/*
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 */

package org.apache.commons.compress.archivers;

import java.io.InputStream;
import java.io.OutputStream;
import java.util.Set;

/**
 * Creates Archive {@link ArchiveInputStream}s and {@link ArchiveOutputStream}s.
 * 
 * @since 1.13
 */
public interface ArchiveStreamProvider {

/**
 * Creates an archive input stream from an archiver name and an input
 * stream.
 * 
 * @param archiverName
 *the archive name, i.e. {@value #AR}, {@value #ARJ},
 *{@value #ZIP}, {@value #TAR}, {@value #JAR}, {@value #CPIO},
 *{@value #DUMP} or {@value #SEVEN_Z}
 * @param in
 *the input stream
 * @param encoding,
 *or null for the default
 * @return the archive input stream
 * @throws ArchiveException
 * if the archiver name is not known
 * @throws StreamingNotSupportedException
 * if the format cannot be read from a stream
 * @throws IllegalArgumentException
 * if the archiver name or stream is null
 */
ArchiveInputStream createArchiveInputStream(final String name, final 
InputStream in, final String encoding)
throws ArchiveException;

/**
 * Creates an archive output stream from an archiver name and an output
 * stream.
 * 
 * @param archiverName
 *the archive name, i.e. {@value #AR}, {@value #ZIP},
 *{@value #TAR}, {@value #JAR} or {@value #CPIO}
 * @param out
 *the output stream
 * @param encoding,
 *or null for the default
 * @return the archive output stream
 * @throws ArchiveException
 * if the archiver name is not known
 * @throws StreamingNotSupportedException
 * if the format cannot be written to a stream
 * @throws IllegalArgumentException
 * if the archiver name or stream is null
 */
ArchiveOutputStream createArchiveOutputStream(final String name, final 
OutputStream out, final String encoding)
throws ArchiveException;

/**
 * Gets all the input stream archive names for this provider
 * 
 * @return all the input archive names for this provider
 */
Set getInputStreamArchiveNames();

/**
 * Gets all the output stream archive names for this provider
 * 
 * @return all the output archive names for this provider
 */
Set getOutputStreamArchiveNames();

}
{code}

  was:
Allow archiver extensions through a standard JRE ServiceLoader.

(Better description soon.)


> Allow archiver extensions through a standard JRE ServiceLoader
> --
>
> Key: COMPRESS-369
> URL: https://issues.apache.org/jira/browse/COMPRESS-369
> Project: Commons Compress
>  Issue Type: New Feature
>  Components: Archivers
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.13
>
>
> Allow archiver extensions through a standard JRE ServiceLoader.
> Introduce a new interface 
> {{org.apache.commons.compress.archivers.ArchiveStreamProvider}}/
> Update {{ArchiveStreamFactory}} to implement this new interface and use a 
> service loader to pick up extra {{ArchiveStreamProvider}}.
> The service loader file is 
> {{META-INF/services/org.apache.commons.compress.archivers.ArchiveStreamProvider}}
> The new interface:
> {code:java}
> /*
>  * Licensed to the Apache 

[jira] [Resolved] (COMPRESS-369) Allow archiver extensions through a standard JRE ServiceLoader

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved COMPRESS-369.
---
   Resolution: Fixed
Fix Version/s: 1.13

In Git master. Feedback welcome.

> Allow archiver extensions through a standard JRE ServiceLoader
> --
>
> Key: COMPRESS-369
> URL: https://issues.apache.org/jira/browse/COMPRESS-369
> Project: Commons Compress
>  Issue Type: New Feature
>  Components: Archivers
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.13
>
>
> Allow archiver extensions through a standard JRE ServiceLoader.
> Introduce a new interface 
> {{org.apache.commons.compress.archivers.ArchiveStreamProvider}}/
> Update {{ArchiveStreamFactory}} to implement this new interface and use a 
> service loader to pick up extra {{ArchiveStreamProvider}}.
> The service loader file is 
> {{META-INF/services/org.apache.commons.compress.archivers.ArchiveStreamProvider}}
> The new interface:
> {code:java}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one
>  * or more contributor license agreements.  See the NOTICE file
>  * distributed with this work for additional information
>  * regarding copyright ownership.  The ASF licenses this file
>  * to you under the Apache License, Version 2.0 (the
>  * "License"); you may not use this file except in compliance
>  * with the License.  You may obtain a copy of the License at
>  *
>  * http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing,
>  * software distributed under the License is distributed on an
>  * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>  * KIND, either express or implied.  See the License for the
>  * specific language governing permissions and limitations
>  * under the License.
>  */
> package org.apache.commons.compress.archivers;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.util.Set;
> /**
>  * Creates Archive {@link ArchiveInputStream}s and {@link 
> ArchiveOutputStream}s.
>  * 
>  * @since 1.13
>  */
> public interface ArchiveStreamProvider {
> /**
>  * Creates an archive input stream from an archiver name and an input
>  * stream.
>  * 
>  * @param archiverName
>  *the archive name, i.e. {@value #AR}, {@value #ARJ},
>  *{@value #ZIP}, {@value #TAR}, {@value #JAR}, {@value #CPIO},
>  *{@value #DUMP} or {@value #SEVEN_Z}
>  * @param in
>  *the input stream
>  * @param encoding,
>  *or null for the default
>  * @return the archive input stream
>  * @throws ArchiveException
>  * if the archiver name is not known
>  * @throws StreamingNotSupportedException
>  * if the format cannot be read from a stream
>  * @throws IllegalArgumentException
>  * if the archiver name or stream is null
>  */
> ArchiveInputStream createArchiveInputStream(final String name, final 
> InputStream in, final String encoding)
> throws ArchiveException;
> /**
>  * Creates an archive output stream from an archiver name and an output
>  * stream.
>  * 
>  * @param archiverName
>  *the archive name, i.e. {@value #AR}, {@value #ZIP},
>  *{@value #TAR}, {@value #JAR} or {@value #CPIO}
>  * @param out
>  *the output stream
>  * @param encoding,
>  *or null for the default
>  * @return the archive output stream
>  * @throws ArchiveException
>  * if the archiver name is not known
>  * @throws StreamingNotSupportedException
>  * if the format cannot be written to a stream
>  * @throws IllegalArgumentException
>  * if the archiver name or stream is null
>  */
> ArchiveOutputStream createArchiveOutputStream(final String name, final 
> OutputStream out, final String encoding)
> throws ArchiveException;
> /**
>  * Gets all the input stream archive names for this provider
>  * 
>  * @return all the input archive names for this provider
>  */
> Set getInputStreamArchiveNames();
> /**
>  * Gets all the output stream archive names for this provider
>  * 
>  * @return all the output archive names for this provider
>  */
> Set getOutputStreamArchiveNames();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #212: [LANG-1285] Replicate the fix for LANG-1186

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/212
  

[![Coverage 
Status](https://coveralls.io/builds/8847626/badge)](https://coveralls.io/builds/8847626)

Coverage increased (+0.0004%) to 93.563% when pulling 
**b61c9b3594bec226dd26ef9af966ebaa6ebf78dc on ilgrosso:master** into 
**0f6a292a29fedd49741310cd517ac4ba907bf8d4 on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LANG-1285) NullPointerException in FastDateParser$TimeZoneStrategy

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15669562#comment-15669562
 ] 

ASF GitHub Bot commented on LANG-1285:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/212
  

[![Coverage 
Status](https://coveralls.io/builds/8847626/badge)](https://coveralls.io/builds/8847626)

Coverage increased (+0.0004%) to 93.563% when pulling 
**b61c9b3594bec226dd26ef9af966ebaa6ebf78dc on ilgrosso:master** into 
**0f6a292a29fedd49741310cd517ac4ba907bf8d4 on apache:master**.



> NullPointerException in FastDateParser$TimeZoneStrategy
> ---
>
> Key: LANG-1285
> URL: https://issues.apache.org/jira/browse/LANG-1285
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.5
> Environment: Centos 7, en_GB locale
>Reporter: Francesco Chicchiriccò
> Fix For: 3.6
>
>
> It seems that after LANG-1186 was fixed, and before 3.5 went out, the bug was 
> re-introduced.
> One of my customers is getting the following error (I am actually not able to 
> reproduce it) with 3.5:
> {code}
> java.lang.NullPointerException
> at 
> org.apache.commons.lang3.time.FastDateParser$TimeZoneStrategy.(FastDateParser.java:869)
> at 
> org.apache.commons.lang3.time.FastDateParser.getLocaleSpecificStrategy(FastDateParser.java:637)
> at 
> org.apache.commons.lang3.time.FastDateParser.getStrategy(FastDateParser.java:606)
> at 
> org.apache.commons.lang3.time.FastDateParser.access$100(FastDateParser.java:73)
> at 
> org.apache.commons.lang3.time.FastDateParser$StrategyParser.letterPattern(FastDateParser.java:234)
> at 
> org.apache.commons.lang3.time.FastDateParser$StrategyParser.getNextStrategy(FastDateParser.java:220)
> at 
> org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:167)
> at 
> org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:153)
> at 
> org.apache.commons.lang3.time.FastDateFormat.(FastDateFormat.java:394)
> at 
> org.apache.commons.lang3.time.FastDateFormat.(FastDateFormat.java:378)
> at 
> org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:100)
> at 
> org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:97)
> at 
> org.apache.commons.lang3.time.FormatCache.getInstance(FormatCache.java:81)
> at 
> org.apache.commons.lang3.time.FastDateFormat.getInstance(FastDateFormat.java:128)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #212: [LANG-1285] Replicate the fix for LANG-1186

[ilgrosso]

GitHub user ilgrosso opened a pull request:

https://github.com/apache/commons-lang/pull/212

[LANG-1285] Replicate the fix for LANG-1186



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ilgrosso/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/212.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #212


commit b61c9b3594bec226dd26ef9af966ebaa6ebf78dc
Author: Francesco Chicchiriccò 
Date:   2016-11-16T06:07:43Z

[LANG-1285] Replicate the fix for LANG-1186




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LANG-1285) NullPointerException in FastDateParser$TimeZoneStrategy

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15669558#comment-15669558
 ] 

ASF GitHub Bot commented on LANG-1285:
--

GitHub user ilgrosso opened a pull request:

https://github.com/apache/commons-lang/pull/212

[LANG-1285] Replicate the fix for LANG-1186



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ilgrosso/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/212.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #212


commit b61c9b3594bec226dd26ef9af966ebaa6ebf78dc
Author: Francesco Chicchiriccò 
Date:   2016-11-16T06:07:43Z

[LANG-1285] Replicate the fix for LANG-1186




> NullPointerException in FastDateParser$TimeZoneStrategy
> ---
>
> Key: LANG-1285
> URL: https://issues.apache.org/jira/browse/LANG-1285
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Affects Versions: 3.5
> Environment: Centos 7, en_GB locale
>Reporter: Francesco Chicchiriccò
> Fix For: 3.6
>
>
> It seems that after LANG-1186 was fixed, and before 3.5 went out, the bug was 
> re-introduced.
> One of my customers is getting the following error (I am actually not able to 
> reproduce it) with 3.5:
> {code}
> java.lang.NullPointerException
> at 
> org.apache.commons.lang3.time.FastDateParser$TimeZoneStrategy.(FastDateParser.java:869)
> at 
> org.apache.commons.lang3.time.FastDateParser.getLocaleSpecificStrategy(FastDateParser.java:637)
> at 
> org.apache.commons.lang3.time.FastDateParser.getStrategy(FastDateParser.java:606)
> at 
> org.apache.commons.lang3.time.FastDateParser.access$100(FastDateParser.java:73)
> at 
> org.apache.commons.lang3.time.FastDateParser$StrategyParser.letterPattern(FastDateParser.java:234)
> at 
> org.apache.commons.lang3.time.FastDateParser$StrategyParser.getNextStrategy(FastDateParser.java:220)
> at 
> org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:167)
> at 
> org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:153)
> at 
> org.apache.commons.lang3.time.FastDateFormat.(FastDateFormat.java:394)
> at 
> org.apache.commons.lang3.time.FastDateFormat.(FastDateFormat.java:378)
> at 
> org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:100)
> at 
> org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:97)
> at 
> org.apache.commons.lang3.time.FormatCache.getInstance(FormatCache.java:81)
> at 
> org.apache.commons.lang3.time.FastDateFormat.getInstance(FastDateFormat.java:128)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (LANG-1285) NullPointerException in FastDateParser$TimeZoneStrategy

[JIRA]

Francesco Chicchiriccò created LANG-1285:


 Summary: NullPointerException in FastDateParser$TimeZoneStrategy
 Key: LANG-1285
 URL: https://issues.apache.org/jira/browse/LANG-1285
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.time.*
Affects Versions: 3.5
 Environment: Centos 7, en_GB locale
Reporter: Francesco Chicchiriccò
 Fix For: 3.6


It seems that after LANG-1186 was fixed, and before 3.5 went out, the bug was 
re-introduced.

One of my customers is getting the following error (I am actually not able to 
reproduce it) with 3.5:

{code}
java.lang.NullPointerException
at 
org.apache.commons.lang3.time.FastDateParser$TimeZoneStrategy.(FastDateParser.java:869)
at 
org.apache.commons.lang3.time.FastDateParser.getLocaleSpecificStrategy(FastDateParser.java:637)
at 
org.apache.commons.lang3.time.FastDateParser.getStrategy(FastDateParser.java:606)
at 
org.apache.commons.lang3.time.FastDateParser.access$100(FastDateParser.java:73)
at 
org.apache.commons.lang3.time.FastDateParser$StrategyParser.letterPattern(FastDateParser.java:234)
at 
org.apache.commons.lang3.time.FastDateParser$StrategyParser.getNextStrategy(FastDateParser.java:220)
at 
org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:167)
at 
org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:153)
at 
org.apache.commons.lang3.time.FastDateFormat.(FastDateFormat.java:394)
at 
org.apache.commons.lang3.time.FastDateFormat.(FastDateFormat.java:378)
at 
org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:100)
at 
org.apache.commons.lang3.time.FastDateFormat$1.createInstance(FastDateFormat.java:97)
at 
org.apache.commons.lang3.time.FormatCache.getInstance(FormatCache.java:81)
at 
org.apache.commons.lang3.time.FastDateFormat.getInstance(FastDateFormat.java:128)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COMPRESS-369) Allow archiver extensions through a standard JRE ServiceLoader

[Gary Gregory (JIRA)]

Gary Gregory created COMPRESS-369:
-

 Summary: Allow archiver extensions through a standard JRE 
ServiceLoader
 Key: COMPRESS-369
 URL: https://issues.apache.org/jira/browse/COMPRESS-369
 Project: Commons Compress
  Issue Type: New Feature
  Components: Archivers
Reporter: Gary Gregory
Assignee: Gary Gregory


Allow archiver extensions through a standard JRE ServiceLoader.

(Better description soon.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (COMPRESS-368) Allow compressor extensions through a standard JRE ServiceLoader

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved COMPRESS-368.
---
   Resolution: Fixed
Fix Version/s: 1.13

In Git master. Feedback welcome.

> Allow compressor extensions through a standard JRE ServiceLoader
> 
>
> Key: COMPRESS-368
> URL: https://issues.apache.org/jira/browse/COMPRESS-368
> Project: Commons Compress
>  Issue Type: New Feature
>  Components: Compressors
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.13
>
>
> Allow compressor extensions through a standard JRE ServiceLoader.
> Introduce a new interface 
> {{org.apache.commons.compress.compressors.CompressorStreamProvider}}
> Update {{CompressorStreamFactory}} to implement this new interface and use a 
> service loader to pick up extra {{CompressorStreamProvider}}.
> The service loader file is 
> {{META-INF/services/org.apache.commons.compress.compressors.CompressorStreamProvider}}
> The new interface:
> {code:java}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one
>  * or more contributor license agreements.  See the NOTICE file
>  * distributed with this work for additional information
>  * regarding copyright ownership.  The ASF licenses this file
>  * to you under the Apache License, Version 2.0 (the
>  * "License"); you may not use this file except in compliance
>  * with the License.  You may obtain a copy of the License at
>  *
>  * http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing,
>  * software distributed under the License is distributed on an
>  * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>  * KIND, either express or implied.  See the License for the
>  * specific language governing permissions and limitations
>  * under the License.
>  */
> package org.apache.commons.compress.compressors;
> import java.io.InputStream;
> import java.io.OutputStream;
> import java.util.Set;
> /**
>  * Creates Compressor {@link CompressorInputStream}s and
>  * {@link CompressorOutputStream}s.
>  * 
>  * @since 1.13
>  */
> public interface CompressorStreamProvider {
> /**
>  * Creates a compressor input stream from a compressor name and an input
>  * stream.
>  * 
>  * @param name
>  *of the compressor, i.e. {@value #GZIP}, {@value #BZIP2},
>  *{@value #XZ}, {@value #LZMA}, {@value #PACK200},
>  *{@value #SNAPPY_RAW}, {@value #SNAPPY_FRAMED}, {@value #Z} 
> or
>  *{@value #DEFLATE}
>  * @param in
>  *the input stream
>  * @return compressor input stream
>  * @throws CompressorException
>  * if the compressor name is not known
>  * @throws IllegalArgumentException
>  * if the name or input stream is null
>  */
> CompressorInputStream createCompressorInputStream(final String name, 
> final InputStream in)
> throws CompressorException;
> /**
>  * Creates a compressor output stream from an compressor name and an 
> output
>  * stream.
>  * 
>  * @param name
>  *the compressor name, i.e. {@value #GZIP}, {@value #BZIP2},
>  *{@value #XZ}, {@value #PACK200} or {@value #DEFLATE}
>  * @param out
>  *the output stream
>  * @return the compressor output stream
>  * @throws CompressorException
>  * if the archiver name is not known
>  * @throws IllegalArgumentException
>  * if the archiver name or stream is null
>  */
> CompressorOutputStream createCompressorOutputStream(final String name, 
> final OutputStream out)
> throws CompressorException;
> /**
>  * Gets all the input stream compressor names for this provider
>  * 
>  * @return all the input compressor names for this provider
>  */
> Set getInputStreamCompressorNames();
> /**
>  * Gets all the output stream compressor names for this provider
>  * 
>  * @return all the output compressor names for this provider
>  */
> Set getOutputStreamCompressorNames();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (COMPRESS-368) Allow compressor extensions through a standard JRE ServiceLoader

[Gary Gregory (JIRA)]

Gary Gregory created COMPRESS-368:
-

 Summary: Allow compressor extensions through a standard JRE 
ServiceLoader
 Key: COMPRESS-368
 URL: https://issues.apache.org/jira/browse/COMPRESS-368
 Project: Commons Compress
  Issue Type: New Feature
  Components: Compressors
Reporter: Gary Gregory
Assignee: Gary Gregory


Allow compressor extensions through a standard JRE ServiceLoader.

Introduce a new interface 
{{org.apache.commons.compress.compressors.CompressorStreamProvider}}

Update {{CompressorStreamFactory}} to implement this new interface and use a 
service loader to pick up extra {{CompressorStreamProvider}}.

The service loader file is 
{{META-INF/services/org.apache.commons.compress.compressors.CompressorStreamProvider}}

The new interface:

{code:java}
/*
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 */

package org.apache.commons.compress.compressors;

import java.io.InputStream;
import java.io.OutputStream;
import java.util.Set;

/**
 * Creates Compressor {@link CompressorInputStream}s and
 * {@link CompressorOutputStream}s.
 * 
 * @since 1.13
 */
public interface CompressorStreamProvider {

/**
 * Creates a compressor input stream from a compressor name and an input
 * stream.
 * 
 * @param name
 *of the compressor, i.e. {@value #GZIP}, {@value #BZIP2},
 *{@value #XZ}, {@value #LZMA}, {@value #PACK200},
 *{@value #SNAPPY_RAW}, {@value #SNAPPY_FRAMED}, {@value #Z} or
 *{@value #DEFLATE}
 * @param in
 *the input stream
 * @return compressor input stream
 * @throws CompressorException
 * if the compressor name is not known
 * @throws IllegalArgumentException
 * if the name or input stream is null
 */
CompressorInputStream createCompressorInputStream(final String name, final 
InputStream in)
throws CompressorException;

/**
 * Creates a compressor output stream from an compressor name and an output
 * stream.
 * 
 * @param name
 *the compressor name, i.e. {@value #GZIP}, {@value #BZIP2},
 *{@value #XZ}, {@value #PACK200} or {@value #DEFLATE}
 * @param out
 *the output stream
 * @return the compressor output stream
 * @throws CompressorException
 * if the archiver name is not known
 * @throws IllegalArgumentException
 * if the archiver name or stream is null
 */
CompressorOutputStream createCompressorOutputStream(final String name, 
final OutputStream out)
throws CompressorException;

/**
 * Gets all the input stream compressor names for this provider
 * 
 * @return all the input compressor names for this provider
 */
Set getInputStreamCompressorNames();

/**
 * Gets all the output stream compressor names for this provider
 * 
 * @return all the output compressor names for this provider
 */
Set getOutputStreamCompressorNames();

}
{code}





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #211: Fixed possible infinite loop in random of RandomStr...

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/211
  
Thanks for the pull request. :)

Please do not mix formatting/white-space changes with functional changes in 
commit.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution

[Jochen Wiedmann (JIRA)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15667947#comment-15667947
 ] 

Jochen Wiedmann commented on FILEUPLOAD-279:


Chris, we are preparing an alternative solution. But pushing out a release, and 
all that, needs time. So, please be a bit patient.


> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation 
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
>  Labels: security
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can 
> be manipulated in such a way that when it is deserialized, it can write or 
> copy files to disk in arbitrary locations. Furthermore, while the Object can 
> be used alone, this new vector can be integrated with ysoserial to upload and 
> execute binaries in a single deserialization call. This may or may not work 
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s 
> yososerial tool to gain remote code execution on a variety of commercial 
> products, based on a presentation at AppSec Cali in January, 2015. The 
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and 
> Spring that do “unexpected” things during deserialization. Specifically, the 
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing 
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make 
> “it easy to add robust, high-performance, file upload capability to your 
> servlets and web applications.” One of the classes in the FileUpload library 
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads. 
> Interestingly, DiskFileItem is serializable and implements custom 
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository 
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the 
> JVMs are
> 639 * on different machines It is possible that the repository 
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null 
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after 
> analyzing the state of DiskFileItem after serialization it became clear that 
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not 
> serialized. dfos is regenerated by the getOutputStream() call above (which 
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid 
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file 
> from disk.
> That filename is always generated via getOutputStream.
> Serialized Object Modification
> The rules listed above 

[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution

[Chris Seieroe (JIRA)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15667888#comment-15667888
 ] 

Chris Seieroe commented on FILEUPLOAD-279:
--

Are you saying it breaks backwards compatibility because the consuming 
applications may serialize DiskFileItem themselves?

I'm trying to be practical here. I have a release going out in a matter of 
days, and while the only deserializing from trusted sources or other mitigation 
techniques may be the best solution, that's too risky and we simply don't have 
the time. If I need to, I'll build my own version of this library with the 
patch. But, obviously, if you're saying there's a problem with that patch, then 
I need to find some other solution.

> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation 
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
>  Labels: security
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can 
> be manipulated in such a way that when it is deserialized, it can write or 
> copy files to disk in arbitrary locations. Furthermore, while the Object can 
> be used alone, this new vector can be integrated with ysoserial to upload and 
> execute binaries in a single deserialization call. This may or may not work 
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s 
> yososerial tool to gain remote code execution on a variety of commercial 
> products, based on a presentation at AppSec Cali in January, 2015. The 
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and 
> Spring that do “unexpected” things during deserialization. Specifically, the 
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing 
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make 
> “it easy to add robust, high-performance, file upload capability to your 
> servlets and web applications.” One of the classes in the FileUpload library 
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads. 
> Interestingly, DiskFileItem is serializable and implements custom 
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository 
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the 
> JVMs are
> 639 * on different machines It is possible that the repository 
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null 
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after 
> analyzing the state of DiskFileItem after serialization it became clear that 
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not 
> serialized. dfos is regenerated by the getOutputStream() call above 

[jira] [Commented] (RNG-30) Sampling

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15667594#comment-15667594
 ] 

Gilles commented on RNG-30:
---

Code for generating random permutations and shuffling generic collections has 
been added in that branch.

> Sampling
> 
>
> Key: RNG-30
> URL: https://issues.apache.org/jira/browse/RNG-30
> Project: Commons RNG
>  Issue Type: New Feature
>Reporter: Gilles
>Assignee: Gilles
>  Labels: API
> Fix For: 1.0
>
>
> It is proposed to create a "commons-rng-sampling" module.
> It will contain code for generating random deviates on the basis of the 
> {{UniformRandomProvider}} interface defined in module 
> "commons-rng-client-api".
> The sampling algorithms will be copied from Commons Math classes (in package 
> "o.a.c.math4.distribution").



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (LANG-1272) Array shuffling

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15667588#comment-15667588
 ] 

Gilles edited comment on LANG-1272 at 11/15/16 4:32 PM:


bq. A. Why not use Collections.shuffle in the implementation?
Because "Commons RNG" provides supposedly better algorithms than 
{{java.util.Random}}.

bq. IMHO that should support generic types + primitive types

I've just committed sampling and shuffling for a generic list.
Comments welcome about the code currently in branch "RNG-30__sampling" (of 
"Commons RNG").



was (Author: erans):
bq. A. Why not use Collections.shuffle in the implementation?
Because "Commons RNG" provides supposedly better algorithm then 
{{java.util.Random}}

bq. IMHO that should support generic types + primitive types

I've just committed sampling and shuffling for a generic list.
Comments welcome about the code currently in branch "RNG-30__sampling" (of 
"Commons RNG").


> Array shuffling
> ---
>
> Key: LANG-1272
> URL: https://issues.apache.org/jira/browse/LANG-1272
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Priority: Minor
> Fix For: 3.6
>
>
> I'd like to suggest the addition of methods in ArrayUtils shuffling the 
> content of an array (Objects or primitives). This would be similar to the 
> {{java.util.Collections.shuffle()}} methods.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1272) Array shuffling

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15667588#comment-15667588
 ] 

Gilles commented on LANG-1272:
--

bq. A. Why not use Collections.shuffle in the implementation?
Because "Commons RNG" provides supposedly better algorithm then 
{{java.util.Random}}

bq. IMHO that should support generic types + primitive types

I've just committed sampling and shuffling for a generic list.
Comments welcome about the code currently in branch "RNG-30__sampling" (of 
"Commons RNG").


> Array shuffling
> ---
>
> Key: LANG-1272
> URL: https://issues.apache.org/jira/browse/LANG-1272
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Priority: Minor
> Fix For: 3.6
>
>
> I'd like to suggest the addition of methods in ArrayUtils shuffling the 
> content of an array (Objects or primitives). This would be similar to the 
> {{java.util.Collections.shuffle()}} methods.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MATH-1393) Deprecate functionality available in "Commons RNG"

[Gilles (JIRA)]

Gilles created MATH-1393:


 Summary: Deprecate functionality available in "Commons RNG"
 Key: MATH-1393
 URL: https://issues.apache.org/jira/browse/MATH-1393
 Project: Commons Math
  Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
 Fix For: 4.0


Code that is moved to "Commons RNG" should be deprecated/removed in "Commons 
Math".

This includes:
* Sampling from distributions (in package {{o.a.c.m.distribution}})
* {{nextPermutation}} and {{nextSample}} (in class 
{{o.a.c.m.random.RandomUtils}})
* array shuffling (in class {{o.a.c.m.util.MathArrays}})



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DAEMON-346) Compile PROCRUN with Data Execution Prevention (DEP) flag

[Hsehdar (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15667019#comment-15667019
 ] 

Hsehdar commented on DAEMON-346:


Thanks [~markt] for the update.

> Compile PROCRUN with Data Execution Prevention (DEP) flag
> -
>
> Key: DAEMON-346
> URL: https://issues.apache.org/jira/browse/DAEMON-346
> Project: Commons Daemon
>  Issue Type: Wish
>  Components: Procrun
>Affects Versions: 1.0.15
>Reporter: Hsehdar
>Priority: Critical
>  Labels: build
> Fix For: 1.1
>
>
> h3. What was the activity?
> We are using PROCRUN to run Java app as service. This is distributed across a 
> network (more than 15,000). Our security team highlighted
> *Executables not compiled following best practices.*
> The application(s) and/or dll(s) are not compiled with
> modern day OS controls such as: ASLR, NX, or DEP.
> Although vulnerability was not discovered, if in the
> future there is one, remote code execution may be
> possible due to lack of operating system controls enabled
> on these executables.
> Is PROCRUN not compiled using DEP?
> PS: This is a not configuration/support request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #211: Fixed possible infinite loop in random of RandomStr...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/211
  

[![Coverage 
Status](https://coveralls.io/builds/8830039/badge)](https://coveralls.io/builds/8830039)

Coverage increased (+0.02%) to 93.58% when pulling 
**5779612199c76bd218223dc7da4446bf6760640d on 
allquantor:bugfix/infinite-loop-random** into 
**0f6a292a29fedd49741310cd517ac4ba907bf8d4 on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (DAEMON-346) Compile PROCRUN with Data Execution Prevention (DEP) flag

[Mark Thomas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1525#comment-1525
 ] 

Mark Thomas commented on DAEMON-346:


The plan, such as it is, is:
1. Fix all open bugs
2. Consider fixing all the open enhancement requests (simple requests with 
patches are likely to get fixed. Complex requests without patches are likely 
not to get fixed)
3. Release 1.1 

In terms of timescale, hopefully the next month or so. This is currently top of 
my TODO list but it depends what other tasks appear.

Help in terms of patches for open issues very much appreciated.

> Compile PROCRUN with Data Execution Prevention (DEP) flag
> -
>
> Key: DAEMON-346
> URL: https://issues.apache.org/jira/browse/DAEMON-346
> Project: Commons Daemon
>  Issue Type: Wish
>  Components: Procrun
>Affects Versions: 1.0.15
>Reporter: Hsehdar
>Priority: Critical
>  Labels: build
> Fix For: 1.1
>
>
> h3. What was the activity?
> We are using PROCRUN to run Java app as service. This is distributed across a 
> network (more than 15,000). Our security team highlighted
> *Executables not compiled following best practices.*
> The application(s) and/or dll(s) are not compiled with
> modern day OS controls such as: ASLR, NX, or DEP.
> Although vulnerability was not discovered, if in the
> future there is one, remote code execution may be
> possible due to lack of operating system controls enabled
> on these executables.
> Is PROCRUN not compiled using DEP?
> PS: This is a not configuration/support request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DAEMON-346) Compile PROCRUN with Data Execution Prevention (DEP) flag

[Hsehdar (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1515#comment-1515
 ] 

Hsehdar commented on DAEMON-346:


[~markt] Can you throw light on 1.1 release plan.

> Compile PROCRUN with Data Execution Prevention (DEP) flag
> -
>
> Key: DAEMON-346
> URL: https://issues.apache.org/jira/browse/DAEMON-346
> Project: Commons Daemon
>  Issue Type: Wish
>  Components: Procrun
>Affects Versions: 1.0.15
>Reporter: Hsehdar
>Priority: Critical
>  Labels: build
> Fix For: 1.1
>
>
> h3. What was the activity?
> We are using PROCRUN to run Java app as service. This is distributed across a 
> network (more than 15,000). Our security team highlighted
> *Executables not compiled following best practices.*
> The application(s) and/or dll(s) are not compiled with
> modern day OS controls such as: ASLR, NX, or DEP.
> Although vulnerability was not discovered, if in the
> future there is one, remote code execution may be
> possible due to lack of operating system controls enabled
> on these executables.
> Is PROCRUN not compiled using DEP?
> PS: This is a not configuration/support request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DAEMON-346) Compile PROCRUN with Data Execution Prevention (DEP) flag

[Hsehdar (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1505#comment-1505
 ] 

Hsehdar commented on DAEMON-346:


Thanks [~markt]

> Compile PROCRUN with Data Execution Prevention (DEP) flag
> -
>
> Key: DAEMON-346
> URL: https://issues.apache.org/jira/browse/DAEMON-346
> Project: Commons Daemon
>  Issue Type: Wish
>  Components: Procrun
>Affects Versions: 1.0.15
>Reporter: Hsehdar
>Priority: Critical
>  Labels: build
> Fix For: 1.1
>
>
> h3. What was the activity?
> We are using PROCRUN to run Java app as service. This is distributed across a 
> network (more than 15,000). Our security team highlighted
> *Executables not compiled following best practices.*
> The application(s) and/or dll(s) are not compiled with
> modern day OS controls such as: ASLR, NX, or DEP.
> Although vulnerability was not discovered, if in the
> future there is one, remote code execution may be
> possible due to lack of operating system controls enabled
> on these executables.
> Is PROCRUN not compiled using DEP?
> PS: This is a not configuration/support request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)