date:20170228

[jira] [Created] (NET-619) SubnetUtils creates a binary netmask in a bad way

2017-02-28 Thread Makoto Sakaguchi (JIRA)

Makoto Sakaguchi created NET-619:


 Summary: SubnetUtils creates a binary netmask in a bad way
 Key: NET-619
 URL: https://issues.apache.org/jira/browse/NET-619
 Project: Commons Net
  Issue Type: Improvement
Reporter: Makoto Sakaguchi
Priority: Minor


SubnetUtils runs a for-loop to create a binary netmask.

However, the way has been difficult to understand the program.
I suggest to replace with a bit-shift, and it has been made a poll request on 
GitHub.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect

2017-02-28 Thread Gilles (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15889124#comment-15889124
 ] 

Gilles commented on MATH-1405:
--

Thanks a lot for the report.

Could you create patches against the "master" branch? I.e.
* set up the example as a Junit test case (and check that it fails with the 
development version of the library),
* insert your proposed fix (see below)

By "temporary solution", do you mean that there could be problem in adopting it?

I'd suggest to instantiate the RNG outside the loop, as follows (see 
http://commons.apache.org/rng and the distribution class in the development 
version of Commons Math)
{code}
import org.apache.commons.rng.UniformRandomProvider;
import org.apache.commons.rng.simple.RandomSource;
// ...
final UniformRandomProvider rng = RandomSource.create(RandomSource.TWO_CMRES);
do {
  final RealDistribution.Sampler sampler =
  new UniformRealDistribution(-minDelta, minDelta).createSampler(rng);
  jitter(x, sampler);
  jitter(y, sampler);
  ties = hasTies(x, y);
  ct++;
  minDelta *= 2;
} while (ties && ct < 1000);
{code}

Since {{jitter}} is private and used for this single purpose, it would probably 
be better, performance-wise, to modify it to use the RNG directly; its 
signature would thus become:
{code}
private static void jitter(double[] data, UniformRandomProvider rng, double 
delta) {
for (int i = 0; i < data.length; i++) {
final double d = delta * (2 * rng.nextDouble() - 1);
data[i] += d;
}
}
{code}


> Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have 
> significant effect
> 
>
> Key: MATH-1405
> URL: https://issues.apache.org/jira/browse/MATH-1405
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Daniil Finkel
>
> For samples that do not exceed LARGE_SAMPLE_PRODUCT with their product and 
> relatively large values, a minDelta can be calculated in fixTies() that is 
> too small to have any effect on the "tied" values. This results in a 
> MathInternalError, as the jiggling with the ineffective minDelta fails to fix 
> the ties.
> The following arrays exhibit this behavior when run with 
> kolmogorovSmirnovTest(x, y) in 3.6.1
> x = [1.3750969645841487, 1.0845460746754014, 1.3693352427126644, 
> 1.329688765445783, 1.3392109491039106, 1.3532766470312723, 
> 1.3187287426697727, 1.386273031970554, 1.3416950149276097, 
> 1.0510872606482404, 1.3532766470312723, 1.3075923871137798, 
> 1.3862730319705543, 1.3814421433922548, 1.0527927570919202, 
> 1.3847314864464313, 1.319362658529506, 1.3579238253227275, 
> 1.2455452272301641, 1.329688765445783, 1.3827781646781876, 
> 1.0755168081687903, 1.2566273460024566, 1.3099622795250825, 
> 1.357440924560318, 1.3519397370266515, 1.0927347979524134, 
> 1.3566357346921618, 1.238800036669969, 1.2931730628634528, 1.048463407884969, 
> 1.3779471642491719, 1.2978533797116658, 1.376230881554943, 1.166901202345226, 
> 1.3690425182006263, 1.166901202345226, 1.2953476417603207, 
> 1.0827945761165951, 1.2942406680885112, 1.224414840377028, 
> 1.3910905417259205, 1.303231085263425, 1.348635183816037, 1.3750969645841487, 
> 1.049648651501274, 1.3119534979602083, 1.0446033225080773, 
> 1.0494686631294756, 1.3862026705844126, 1.2719496963348844, 
> 1.3489938748102903, 1.3780468374004164, 1.3884878389662338, 
> 1.3352682241994538, 1.3348722240568909, 1.3921944407986777, 
> 1.0476833161122294, 1.0845460746754008, 1.344165352323966, 1.298548179079665, 
> 1.1979240079667628, 1.3539078973394736, 1.3187287426697725, 
> 1.082794576116595, 1.3779471642491719, 1.3771347858434184, 
> 1.3921944407986777, 1.193793081523992, 1.362050393265006, 1.076638744462226, 
> 1.3551174562135766, 1.3393693468578751, 1.2470361076952952, 
> 1.3696023478216113, 1.3750969645841487, 1.2964734722088322, 
> 1.2953476417603207, 1.2470361076952952, 1.382661263313539, 
> 1.3862026705844126, 1.3771240109822156, 1.25443884328785, 1.3136690818105938, 
> 1.3853832858443051, 1.3486351838160378, 1.348026557887345, 
> 1.0604869883721861, 1.3352682241994536, 1.3480480718535308, 
> 1.3363233390543028, 1.154658436584056, 1.3921944407986775, 
> 1.1979240079667626, 1.3620503932650059, 1.0881358731694244, 
> 1.369042518200626, 1.3532766470312723, 1.2890012831575908, 1.3735565244300663]
> and
> y = [1.1262991662205104, 1.3136690818105938, 1.0446033225080773, 
> 1.3551174562135764, 1.3032310852634252, 1.3806258468851462, 
> 1.227061245983, 1.2719496963348844, 1.3601566259413194, 
> 1.3756888280688913, 1.3475322202511097, 1.1937930815239919, 
> 1.0510872606482404, 1.3441653523239654, 1.359738761905118, 
> 1.3382152957887032, 1.0766387444622263, 1.1937930815239919, 
> 1.0820779503060238, 1.1448104521200428, 1.3853832858443051,

[jira] [Resolved] (LANG-1265) Build failures when building with Java 9 EA

2017-02-28 Thread Pascal Schumacher (JIRA)


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

Pascal Schumacher resolved LANG-1265.
-
Resolution: Fixed
  Assignee: Pascal Schumacher

> Build failures when building with Java 9 EA
> ---
>
> Key: LANG-1265
> URL: https://issues.apache.org/jira/browse/LANG-1265
> Project: Commons Lang
>  Issue Type: Bug
>Reporter: Benedikt Ritter
>Assignee: Pascal Schumacher
> Fix For: 3.6
>
>
> When building with Java 9 EA I get: 
> {code}
> Failed tests:
>  
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_AD:304->FastDateParserTest.testLocales:342
>  Locale no failed with /////ss// era AD
> java.text.ParseException: Unparseable date: 
> 2003/februar/0010/0012//00/AM/mandag
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_BC:309->FastDateParserTest.testLocales:342
>  Locale no failed with /////ss// era BC
> java.text.ParseException: Unparseable date: 
> 2003/februar/0010/0012//00/AM/lørdag
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_AD:284->FastDateParserTest.testLocales:342
>  Locale no failed with //////ss// era AD
> java.text.ParseException: Unparseable date: 
> AD/2003/februar/0010/0012//00/AM/mandag
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_BC:289->FastDateParserTest.testLocales:342
>  Locale qu_EC failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun 
> puquy/0010/0012//00/a.m./Sábado"
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_AD:314->FastDateParserTest.testLocales:342
>  Locale no failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_BC:319->FastDateParserTest.testLocales:342
>  Locale no failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_AD:294->FastDateParserTest.testLocales:342
>  Locale no failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_BC:299->FastDateParserTest.testLocales:342
>  Locale qu_EC failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
>   FastDateParserTest.testLocales_LongNoEra_AD:304->testLocales:342 Locale no 
> failed with /////ss// era AD
> java.text.ParseException: Unparseable date: 
> 2003/februar/0010/0012//00/AM/mandag
>   FastDateParserTest.testLocales_LongNoEra_BC:309->testLocales:342 Locale no 
> failed with /////ss// era BC
> java.text.ParseException: Unparseable date: 
> 2003/februar/0010/0012//00/AM/lørdag
>   FastDateParserTest.testLocales_Long_AD:284->testLocales:342 Locale no 
> failed with //////ss// era AD
> java.text.ParseException: Unparseable date: 
> AD/2003/februar/0010/0012//00/AM/mandag
>   FastDateParserTest.testLocales_Long_BC:289->testLocales:342 Locale qu_EC 
> failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun 
> puquy/0010/0012//00/a.m./Sábado"
>   FastDateParserTest.testLocales_ShortNoEra_AD:314->testLocales:342 Locale no 
> failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
>   FastDateParserTest.testLocales_ShortNoEra_BC:319->testLocales:342 Locale no 
> failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
>   FastDateParserTest.testLocales_Short_AD:294->testLocales:342 Locale no 
> failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
>   FastDateParserTest.testLocales_Short_BC:299->testLocales:342 Locale qu_EC 
> failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
> Tests in error:
>   LocaleUtilsTest.testParseAllLocales:578 » IllegalArgument Invalid locale 
> forma...
>   
> FastDateFormat_ParserTest>FastDateParserTest.testParses:252->FastDateParserTest.validateSdfFormatFdpParseEquality:228
>  » Parse
>   FastDateFormat_ParserTest>FastDateParserTest.testTzParses:275 » Parse 
> Unparsea...
>   FastDateParserTest.testParses:252->validateSdfFormatFdpParseEquality:228 » 
> Parse
>   FastDateParserTest.testTzParses:275 » Parse Unparseable date: 2000/02/10 
> 北美东部标...
> Tests run: 3882, Failures: 16,

[jira] [Commented] (LANG-1265) Build failures when building with Java 9 EA

2017-02-28 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on LANG-1265:
--

Github user asfgit closed the pull request at:

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


> Build failures when building with Java 9 EA
> ---
>
> Key: LANG-1265
> URL: https://issues.apache.org/jira/browse/LANG-1265
> Project: Commons Lang
>  Issue Type: Bug
>Reporter: Benedikt Ritter
> Fix For: 3.6
>
>
> When building with Java 9 EA I get: 
> {code}
> Failed tests:
>  
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_AD:304->FastDateParserTest.testLocales:342
>  Locale no failed with /////ss// era AD
> java.text.ParseException: Unparseable date: 
> 2003/februar/0010/0012//00/AM/mandag
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_BC:309->FastDateParserTest.testLocales:342
>  Locale no failed with /////ss// era BC
> java.text.ParseException: Unparseable date: 
> 2003/februar/0010/0012//00/AM/lørdag
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_AD:284->FastDateParserTest.testLocales:342
>  Locale no failed with //////ss// era AD
> java.text.ParseException: Unparseable date: 
> AD/2003/februar/0010/0012//00/AM/mandag
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_BC:289->FastDateParserTest.testLocales:342
>  Locale qu_EC failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun 
> puquy/0010/0012//00/a.m./Sábado"
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_AD:314->FastDateParserTest.testLocales:342
>  Locale no failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_BC:319->FastDateParserTest.testLocales:342
>  Locale no failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_AD:294->FastDateParserTest.testLocales:342
>  Locale no failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
>   
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_BC:299->FastDateParserTest.testLocales:342
>  Locale qu_EC failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
>   FastDateParserTest.testLocales_LongNoEra_AD:304->testLocales:342 Locale no 
> failed with /////ss// era AD
> java.text.ParseException: Unparseable date: 
> 2003/februar/0010/0012//00/AM/mandag
>   FastDateParserTest.testLocales_LongNoEra_BC:309->testLocales:342 Locale no 
> failed with /////ss// era BC
> java.text.ParseException: Unparseable date: 
> 2003/februar/0010/0012//00/AM/lørdag
>   FastDateParserTest.testLocales_Long_AD:284->testLocales:342 Locale no 
> failed with //////ss// era AD
> java.text.ParseException: Unparseable date: 
> AD/2003/februar/0010/0012//00/AM/mandag
>   FastDateParserTest.testLocales_Long_BC:289->testLocales:342 Locale qu_EC 
> failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun 
> puquy/0010/0012//00/a.m./Sábado"
>   FastDateParserTest.testLocales_ShortNoEra_AD:314->testLocales:342 Locale no 
> failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
>   FastDateParserTest.testLocales_ShortNoEra_BC:319->testLocales:342 Locale no 
> failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
>   FastDateParserTest.testLocales_Short_AD:294->testLocales:342 Locale no 
> failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
>   FastDateParserTest.testLocales_Short_BC:299->testLocales:342 Locale qu_EC 
> failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
> Tests in error:
>   LocaleUtilsTest.testParseAllLocales:578 » IllegalArgument Invalid locale 
> forma...
>   
> FastDateFormat_ParserTest>FastDateParserTest.testParses:252->FastDateParserTest.validateSdfFormatFdpParseEquality:228
>  » Parse
>   FastDateFormat_ParserTest>FastDateParserTest.testTzParses:275 » Parse 
> Unparsea...
>   FastDateParserTest.testParses:252->validateSdfFormatFdpParseEquality:228 » 
> Parse
>   FastDateParserTest.testTzParses:275 » Parse Unparseable date: 2000/02/10 
>

[GitHub] commons-lang pull request #244: LANG-1265: Build failures when building with...

2017-02-28 Thread asfgit

Github user asfgit closed the pull request at:

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


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

[GitHub] commons-lang pull request #247: JUnit imports

2017-02-28 Thread asfgit

Github user asfgit closed the pull request at:

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


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

[GitHub] commons-lang issue #247: JUnit imports

2017-02-28 Thread kinow

Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/247
  
:+1: 


---
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] [Comment Edited] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect

2017-02-28 Thread Daniil Finkel (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15888931#comment-15888931
 ] 

Daniil Finkel edited comment on MATH-1405 at 2/28/17 9:58 PM:
--

A temporary solution I've found is, in fixTies(), pulling the RealDistribution 
Object creation inside the do-while loop, and doubling the minDelta with every 
iteration until it's large enough:

{code}
do {
LOGGER.warn("using minDelta: {}", minDelta);
// Add jitter using a fixed seed (so same arguments always give 
same results),
// low-initialization-overhead generator
final RealDistribution dist = new UniformRealDistribution(new 
JDKRandomGenerator(100), -minDelta, minDelta);

jitter(x, dist);
jitter(y, dist);
ties = hasTies(x, y);
ct++;
minDelta *= 2;
} while (ties && ct < 1000);
{code}


was (Author: dfinkel):
A temporary solution I've found is, in fixTies(), pulling the RealDistribution 
Object creation inside the do-while loop, and doubling the minDelta with every 
iteration until it's large enough:

`do {
LOGGER.warn("using minDelta: {}", minDelta);
// Add jitter using a fixed seed (so same arguments always give 
same results),
// low-initialization-overhead generator
final RealDistribution dist = new UniformRealDistribution(new 
JDKRandomGenerator(100), -minDelta, minDelta);

jitter(x, dist);
jitter(y, dist);
ties = hasTies(x, y);
ct++;
minDelta *= 2;
} while (ties && ct < 1000);
`

> Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have 
> significant effect
> 
>
> Key: MATH-1405
> URL: https://issues.apache.org/jira/browse/MATH-1405
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Daniil Finkel
>
> For samples that do not exceed LARGE_SAMPLE_PRODUCT with their product and 
> relatively large values, a minDelta can be calculated in fixTies() that is 
> too small to have any effect on the "tied" values. This results in a 
> MathInternalError, as the jiggling with the ineffective minDelta fails to fix 
> the ties.
> The following arrays exhibit this behavior when run with 
> kolmogorovSmirnovTest(x, y) in 3.6.1
> x = [1.3750969645841487, 1.0845460746754014, 1.3693352427126644, 
> 1.329688765445783, 1.3392109491039106, 1.3532766470312723, 
> 1.3187287426697727, 1.386273031970554, 1.3416950149276097, 
> 1.0510872606482404, 1.3532766470312723, 1.3075923871137798, 
> 1.3862730319705543, 1.3814421433922548, 1.0527927570919202, 
> 1.3847314864464313, 1.319362658529506, 1.3579238253227275, 
> 1.2455452272301641, 1.329688765445783, 1.3827781646781876, 
> 1.0755168081687903, 1.2566273460024566, 1.3099622795250825, 
> 1.357440924560318, 1.3519397370266515, 1.0927347979524134, 
> 1.3566357346921618, 1.238800036669969, 1.2931730628634528, 1.048463407884969, 
> 1.3779471642491719, 1.2978533797116658, 1.376230881554943, 1.166901202345226, 
> 1.3690425182006263, 1.166901202345226, 1.2953476417603207, 
> 1.0827945761165951, 1.2942406680885112, 1.224414840377028, 
> 1.3910905417259205, 1.303231085263425, 1.348635183816037, 1.3750969645841487, 
> 1.049648651501274, 1.3119534979602083, 1.0446033225080773, 
> 1.0494686631294756, 1.3862026705844126, 1.2719496963348844, 
> 1.3489938748102903, 1.3780468374004164, 1.3884878389662338, 
> 1.3352682241994538, 1.3348722240568909, 1.3921944407986777, 
> 1.0476833161122294, 1.0845460746754008, 1.344165352323966, 1.298548179079665, 
> 1.1979240079667628, 1.3539078973394736, 1.3187287426697725, 
> 1.082794576116595, 1.3779471642491719, 1.3771347858434184, 
> 1.3921944407986777, 1.193793081523992, 1.362050393265006, 1.076638744462226, 
> 1.3551174562135766, 1.3393693468578751, 1.2470361076952952, 
> 1.3696023478216113, 1.3750969645841487, 1.2964734722088322, 
> 1.2953476417603207, 1.2470361076952952, 1.382661263313539, 
> 1.3862026705844126, 1.3771240109822156, 1.25443884328785, 1.3136690818105938, 
> 1.3853832858443051, 1.3486351838160378, 1.348026557887345, 
> 1.0604869883721861, 1.3352682241994536, 1.3480480718535308, 
> 1.3363233390543028, 1.154658436584056, 1.3921944407986775, 
> 1.1979240079667626, 1.3620503932650059, 1.0881358731694244, 
> 1.369042518200626, 1.3532766470312723, 1.2890012831575908, 1.3735565244300663]
> and
> y = [1.1262991662205104, 1.3136690818105938, 1.0446033225080773, 
> 1.3551174562135764, 1.3032310852634252, 1.3806258468851462, 
> 1.227061245983, 1.2719496963348844, 1.3601566259413194, 
> 1.3756888280688913, 1.3475322202511097, 1.1937930815239919, 
> 1.0510872606482404, 1.3441653523239654, 1.359738761905118, 
> 1.3382152957887032,

[jira] [Comment Edited] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect

2017-02-28 Thread Daniil Finkel (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15888931#comment-15888931
 ] 

Daniil Finkel edited comment on MATH-1405 at 2/28/17 9:55 PM:
--

A temporary solution I've found is, in fixTies(), pulling the RealDistribution 
Object creation inside the do-while loop, and doubling the minDelta with every 
iteration until it's large enough:

`do {
LOGGER.warn("using minDelta: {}", minDelta);
// Add jitter using a fixed seed (so same arguments always give 
same results),
// low-initialization-overhead generator
final RealDistribution dist = new UniformRealDistribution(new 
JDKRandomGenerator(100), -minDelta, minDelta);

jitter(x, dist);
jitter(y, dist);
ties = hasTies(x, y);
ct++;
minDelta *= 2;
} while (ties && ct < 1000);
`


was (Author: dfinkel):
A temporary solution I've found is, in fixTies(), pulling the RealDistribution 
Object creation inside the do-while loop, and doubling the minDelta with every 
iteration until it's large enough:

`do {
LOGGER.warn("using minDelta: {}", minDelta);
// Add jitter using a fixed seed (so same arguments always give 
same results),
// low-initialization-overhead generator
final RealDistribution dist = new UniformRealDistribution(new 
JDKRandomGenerator(100), -minDelta, minDelta);

jitter(x, dist);
jitter(y, dist);
ties = hasTies(x, y);
ct++;
minDelta *= 2;
} while (ties && ct < 1000);`

> Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have 
> significant effect
> 
>
> Key: MATH-1405
> URL: https://issues.apache.org/jira/browse/MATH-1405
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Daniil Finkel
>
> For samples that do not exceed LARGE_SAMPLE_PRODUCT with their product and 
> relatively large values, a minDelta can be calculated in fixTies() that is 
> too small to have any effect on the "tied" values. This results in a 
> MathInternalError, as the jiggling with the ineffective minDelta fails to fix 
> the ties.
> The following arrays exhibit this behavior when run with 
> kolmogorovSmirnovTest(x, y) in 3.6.1
> x = [1.3750969645841487, 1.0845460746754014, 1.3693352427126644, 
> 1.329688765445783, 1.3392109491039106, 1.3532766470312723, 
> 1.3187287426697727, 1.386273031970554, 1.3416950149276097, 
> 1.0510872606482404, 1.3532766470312723, 1.3075923871137798, 
> 1.3862730319705543, 1.3814421433922548, 1.0527927570919202, 
> 1.3847314864464313, 1.319362658529506, 1.3579238253227275, 
> 1.2455452272301641, 1.329688765445783, 1.3827781646781876, 
> 1.0755168081687903, 1.2566273460024566, 1.3099622795250825, 
> 1.357440924560318, 1.3519397370266515, 1.0927347979524134, 
> 1.3566357346921618, 1.238800036669969, 1.2931730628634528, 1.048463407884969, 
> 1.3779471642491719, 1.2978533797116658, 1.376230881554943, 1.166901202345226, 
> 1.3690425182006263, 1.166901202345226, 1.2953476417603207, 
> 1.0827945761165951, 1.2942406680885112, 1.224414840377028, 
> 1.3910905417259205, 1.303231085263425, 1.348635183816037, 1.3750969645841487, 
> 1.049648651501274, 1.3119534979602083, 1.0446033225080773, 
> 1.0494686631294756, 1.3862026705844126, 1.2719496963348844, 
> 1.3489938748102903, 1.3780468374004164, 1.3884878389662338, 
> 1.3352682241994538, 1.3348722240568909, 1.3921944407986777, 
> 1.0476833161122294, 1.0845460746754008, 1.344165352323966, 1.298548179079665, 
> 1.1979240079667628, 1.3539078973394736, 1.3187287426697725, 
> 1.082794576116595, 1.3779471642491719, 1.3771347858434184, 
> 1.3921944407986777, 1.193793081523992, 1.362050393265006, 1.076638744462226, 
> 1.3551174562135766, 1.3393693468578751, 1.2470361076952952, 
> 1.3696023478216113, 1.3750969645841487, 1.2964734722088322, 
> 1.2953476417603207, 1.2470361076952952, 1.382661263313539, 
> 1.3862026705844126, 1.3771240109822156, 1.25443884328785, 1.3136690818105938, 
> 1.3853832858443051, 1.3486351838160378, 1.348026557887345, 
> 1.0604869883721861, 1.3352682241994536, 1.3480480718535308, 
> 1.3363233390543028, 1.154658436584056, 1.3921944407986775, 
> 1.1979240079667626, 1.3620503932650059, 1.0881358731694244, 
> 1.369042518200626, 1.3532766470312723, 1.2890012831575908, 1.3735565244300663]
> and
> y = [1.1262991662205104, 1.3136690818105938, 1.0446033225080773, 
> 1.3551174562135764, 1.3032310852634252, 1.3806258468851462, 
> 1.227061245983, 1.2719496963348844, 1.3601566259413194, 
> 1.3756888280688913, 1.3475322202511097, 1.1937930815239919, 
> 1.0510872606482404, 1.3441653523239654, 1.359738761905118, 
> 1.3382152957887032,

[jira] [Commented] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect

2017-02-28 Thread Daniil Finkel (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15888931#comment-15888931
 ] 

Daniil Finkel commented on MATH-1405:
-

A temporary solution I've found is, in fixTies(), pulling the RealDistribution 
Object creation inside the do-while loop, and doubling the minDelta with every 
iteration until it's large enough:

`do {
LOGGER.warn("using minDelta: {}", minDelta);
// Add jitter using a fixed seed (so same arguments always give 
same results),
// low-initialization-overhead generator
final RealDistribution dist = new UniformRealDistribution(new 
JDKRandomGenerator(100), -minDelta, minDelta);

jitter(x, dist);
jitter(y, dist);
ties = hasTies(x, y);
ct++;
minDelta *= 2;
} while (ties && ct < 1000);`

> Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have 
> significant effect
> 
>
> Key: MATH-1405
> URL: https://issues.apache.org/jira/browse/MATH-1405
> Project: Commons Math
>  Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Daniil Finkel
>
> For samples that do not exceed LARGE_SAMPLE_PRODUCT with their product and 
> relatively large values, a minDelta can be calculated in fixTies() that is 
> too small to have any effect on the "tied" values. This results in a 
> MathInternalError, as the jiggling with the ineffective minDelta fails to fix 
> the ties.
> The following arrays exhibit this behavior when run with 
> kolmogorovSmirnovTest(x, y) in 3.6.1
> x = [1.3750969645841487, 1.0845460746754014, 1.3693352427126644, 
> 1.329688765445783, 1.3392109491039106, 1.3532766470312723, 
> 1.3187287426697727, 1.386273031970554, 1.3416950149276097, 
> 1.0510872606482404, 1.3532766470312723, 1.3075923871137798, 
> 1.3862730319705543, 1.3814421433922548, 1.0527927570919202, 
> 1.3847314864464313, 1.319362658529506, 1.3579238253227275, 
> 1.2455452272301641, 1.329688765445783, 1.3827781646781876, 
> 1.0755168081687903, 1.2566273460024566, 1.3099622795250825, 
> 1.357440924560318, 1.3519397370266515, 1.0927347979524134, 
> 1.3566357346921618, 1.238800036669969, 1.2931730628634528, 1.048463407884969, 
> 1.3779471642491719, 1.2978533797116658, 1.376230881554943, 1.166901202345226, 
> 1.3690425182006263, 1.166901202345226, 1.2953476417603207, 
> 1.0827945761165951, 1.2942406680885112, 1.224414840377028, 
> 1.3910905417259205, 1.303231085263425, 1.348635183816037, 1.3750969645841487, 
> 1.049648651501274, 1.3119534979602083, 1.0446033225080773, 
> 1.0494686631294756, 1.3862026705844126, 1.2719496963348844, 
> 1.3489938748102903, 1.3780468374004164, 1.3884878389662338, 
> 1.3352682241994538, 1.3348722240568909, 1.3921944407986777, 
> 1.0476833161122294, 1.0845460746754008, 1.344165352323966, 1.298548179079665, 
> 1.1979240079667628, 1.3539078973394736, 1.3187287426697725, 
> 1.082794576116595, 1.3779471642491719, 1.3771347858434184, 
> 1.3921944407986777, 1.193793081523992, 1.362050393265006, 1.076638744462226, 
> 1.3551174562135766, 1.3393693468578751, 1.2470361076952952, 
> 1.3696023478216113, 1.3750969645841487, 1.2964734722088322, 
> 1.2953476417603207, 1.2470361076952952, 1.382661263313539, 
> 1.3862026705844126, 1.3771240109822156, 1.25443884328785, 1.3136690818105938, 
> 1.3853832858443051, 1.3486351838160378, 1.348026557887345, 
> 1.0604869883721861, 1.3352682241994536, 1.3480480718535308, 
> 1.3363233390543028, 1.154658436584056, 1.3921944407986775, 
> 1.1979240079667626, 1.3620503932650059, 1.0881358731694244, 
> 1.369042518200626, 1.3532766470312723, 1.2890012831575908, 1.3735565244300663]
> and
> y = [1.1262991662205104, 1.3136690818105938, 1.0446033225080773, 
> 1.3551174562135764, 1.3032310852634252, 1.3806258468851462, 
> 1.227061245983, 1.2719496963348844, 1.3601566259413194, 
> 1.3756888280688913, 1.3475322202511097, 1.1937930815239919, 
> 1.0510872606482404, 1.3441653523239654, 1.359738761905118, 
> 1.3382152957887032, 1.0766387444622263, 1.1937930815239919, 
> 1.0820779503060238, 1.1448104521200428, 1.3853832858443051, 1.28757746537949, 
> 1.298548179079665, 1.067255392172351, 1.3168701741293156, 1.3910905417259205, 
> 1.2908594990421354, 1.3750969645841487, 1.329688765445783, 1.386649365275275, 
> 1.285486511663053, 1.2566273460024566, 1.323664826995234, 1.3862730319705538, 
> 1.049346328049449]
> which produce minDelta = 1.11022302462516E-016



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NET-616) Heap Inspection: Passwords can be revealed from heap

2017-02-28 Thread Sebb (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15888909#comment-15888909
 ] 

Sebb commented on NET-616:
--

Fixing Base64#encodeBase64StringUnChunked would not solve the problem, as the 
password is passed in using a String.

AFAICT large parts of the NET code would have to be rewritten to allow bytes 
(or chars?) to be used instead of a String

> Heap Inspection: Passwords can be revealed from heap
> 
>
> Key: NET-616
> URL: https://issues.apache.org/jira/browse/NET-616
> Project: Commons Net
>  Issue Type: Bug
>  Components: IMAP
>Affects Versions: 3.6
>Reporter: Donald Kwakkel
>
> password is used as string in 
> src/main/java/org/apache/commons/net/imap/AuthenticatingIMAPClient.java. This 
> should be passed as bytes and be cleaned after usage.
> Abstract:
> The method newStringUtf8() in Base64.java stores sensitive data in a String 
> object, making it impossible to reliably purge the data from memory.
> Explanation:
> Sensitive data (such as passwords, social security numbers, credit card 
> numbers etc) stored in memory can be leaked if memory is not cleared after 
> use. Often, Strings are used store sensitive data, however, since String 
> objects are immutable, removing the value of a String from memory can only be 
> done by the JVM garbage collector. The garbage collector is not required to 
> run unless the JVM is low on memory, so there is no guarantee as to when 
> garbage collection will take place. In the event of an application crash, a 
> memory dump of the application might reveal sensitive data.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect

2017-02-28 Thread Daniil Finkel (JIRA)

Daniil Finkel created MATH-1405:
---

 Summary: Kolmogorov-Smirnov fixTies can set minDelta too small for 
jiggler to have significant effect
 Key: MATH-1405
 URL: https://issues.apache.org/jira/browse/MATH-1405
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.6.1
Reporter: Daniil Finkel


For samples that do not exceed LARGE_SAMPLE_PRODUCT with their product and 
relatively large values, a minDelta can be calculated in fixTies() that is too 
small to have any effect on the "tied" values. This results in a 
MathInternalError, as the jiggling with the ineffective minDelta fails to fix 
the ties.

The following arrays exhibit this behavior when run with 
kolmogorovSmirnovTest(x, y) in 3.6.1

x = [1.3750969645841487, 1.0845460746754014, 1.3693352427126644, 
1.329688765445783, 1.3392109491039106, 1.3532766470312723, 1.3187287426697727, 
1.386273031970554, 1.3416950149276097, 1.0510872606482404, 1.3532766470312723, 
1.3075923871137798, 1.3862730319705543, 1.3814421433922548, 1.0527927570919202, 
1.3847314864464313, 1.319362658529506, 1.3579238253227275, 1.2455452272301641, 
1.329688765445783, 1.3827781646781876, 1.0755168081687903, 1.2566273460024566, 
1.3099622795250825, 1.357440924560318, 1.3519397370266515, 1.0927347979524134, 
1.3566357346921618, 1.238800036669969, 1.2931730628634528, 1.048463407884969, 
1.3779471642491719, 1.2978533797116658, 1.376230881554943, 1.166901202345226, 
1.3690425182006263, 1.166901202345226, 1.2953476417603207, 1.0827945761165951, 
1.2942406680885112, 1.224414840377028, 1.3910905417259205, 1.303231085263425, 
1.348635183816037, 1.3750969645841487, 1.049648651501274, 1.3119534979602083, 
1.0446033225080773, 1.0494686631294756, 1.3862026705844126, 1.2719496963348844, 
1.3489938748102903, 1.3780468374004164, 1.3884878389662338, 1.3352682241994538, 
1.3348722240568909, 1.3921944407986777, 1.0476833161122294, 1.0845460746754008, 
1.344165352323966, 1.298548179079665, 1.1979240079667628, 1.3539078973394736, 
1.3187287426697725, 1.082794576116595, 1.3779471642491719, 1.3771347858434184, 
1.3921944407986777, 1.193793081523992, 1.362050393265006, 1.076638744462226, 
1.3551174562135766, 1.3393693468578751, 1.2470361076952952, 1.3696023478216113, 
1.3750969645841487, 1.2964734722088322, 1.2953476417603207, 1.2470361076952952, 
1.382661263313539, 1.3862026705844126, 1.3771240109822156, 1.25443884328785, 
1.3136690818105938, 1.3853832858443051, 1.3486351838160378, 1.348026557887345, 
1.0604869883721861, 1.3352682241994536, 1.3480480718535308, 1.3363233390543028, 
1.154658436584056, 1.3921944407986775, 1.1979240079667626, 1.3620503932650059, 
1.0881358731694244, 1.369042518200626, 1.3532766470312723, 1.2890012831575908, 
1.3735565244300663]

and

y = [1.1262991662205104, 1.3136690818105938, 1.0446033225080773, 
1.3551174562135764, 1.3032310852634252, 1.3806258468851462, 1.227061245983, 
1.2719496963348844, 1.3601566259413194, 1.3756888280688913, 1.3475322202511097, 
1.1937930815239919, 1.0510872606482404, 1.3441653523239654, 1.359738761905118, 
1.3382152957887032, 1.0766387444622263, 1.1937930815239919, 1.0820779503060238, 
1.1448104521200428, 1.3853832858443051, 1.28757746537949, 1.298548179079665, 
1.067255392172351, 1.3168701741293156, 1.3910905417259205, 1.2908594990421354, 
1.3750969645841487, 1.329688765445783, 1.386649365275275, 1.285486511663053, 
1.2566273460024566, 1.323664826995234, 1.3862730319705538, 1.049346328049449]

which produce minDelta = 1.11022302462516E-016



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (NET-618) System Information Leak in ftp parser

2017-02-28 Thread Sebb (JIRA)


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

Sebb resolved NET-618.
--
   Resolution: Fixed
Fix Version/s: 3.7

Thanks for the report - probably left-over debug

URL: http://svn.apache.org/viewvc?rev=1784819=rev
Log:
NET-618 System Information Leak in ftp parser

Modified:
commons/proper/net/trunk/src/changes/changes.xml

commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/parser/MVSFTPEntryParser.java


> System Information Leak in ftp parser
> -
>
> Key: NET-618
> URL: https://issues.apache.org/jira/browse/NET-618
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.6
>Reporter: Donald Kwakkel
>Priority: Minor
> Fix For: 3.7
>
>
> Exception is printed to console in 
> src/main/java/org/apache/commons/net/ftp/parser/MVSFTPEntryParser.java which 
> can leak system information:
> {code}
> private boolean parseMemberList(FTPFile file, String entry) {
> if (matches(entry)) {
> file.setRawListing(entry);
> String name = group(1);
> String datestr = group(2) + " " + group(3);
> file.setName(name);
> file.setType(FTPFile.FILE_TYPE);
> try {
> file.setTimestamp(super.parseTimestamp(datestr));
> } catch (ParseException e) {
> e.printStackTrace();
> // just ignore parsing errors.
> // TODO check this is ok
> return false; // this is a parsing failure too.
> }
> return true;
> }
> return false;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] commons-lang pull request #247: JUnit imports

2017-02-28 Thread mureinik

GitHub user mureinik opened a pull request:

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

JUnit imports

The `junit.framework` package has been deprecated, and should no longer
be used.

This patch fixes the one remaining import from it to statically import
`org.junit.Assert.assertNull` instead.

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

$ git pull https://github.com/mureinik/commons-lang junit

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

https://github.com/apache/commons-lang/pull/247.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 #247


commit 1aaa66937f6c16e0b5055354ab2bd595d679e9ae
Author: Allon Mureinik 
Date:   2017-02-28T21:17:51Z

JUnit imports

The junit.framework package has been deprecated, and should no longer
be used.

This patch fixes the one remaining import from it to statically import
org.junit.Assert.assertNull instead.




---
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] (NET-401) FTP class uses BufferedReader for control channel, which does not follow the standard

2017-02-28 Thread Chris Collins (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15888531#comment-15888531
 ] 

Chris Collins commented on NET-401:
---

Currently running into an issue with the CRLFLineReader hanging up or reading 
too far when processing a banner that has a mix of CR/LF and just LF in it from 
a Cisco Ironport WSA appliance.

Sometimes the reader goes to far and picks up a null, and other times (with a 
different banner config) it doesn't go far enough and hangs indefinitely.

Is there a RFC documented somewhere on line termination for FTP, and banners in 
particular? I plan on opening an issue on this with supporting data, but just 
wanted to start at the source.

> FTP class uses BufferedReader for control channel, which does not follow the 
> standard
> -
>
> Key: NET-401
> URL: https://issues.apache.org/jira/browse/NET-401
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 2.2
>Reporter: Sebb
> Fix For: 3.0
>
>
> The FTP class uses BufferedReader for wrapping the control channel, and uses 
> its readLine() for getting responses from the server.
> The FTP protocol requires CRLF at the end of lines, but 
> Bufferedreader#readLine() also allows bare CR and LF terminators, which could 
> potentially be included in a server reply.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NET-618) System Information Leak in ftp parser

2017-02-28 Thread Donald Kwakkel (JIRA)

Donald Kwakkel created NET-618:
--

 Summary: System Information Leak in ftp parser
 Key: NET-618
 URL: https://issues.apache.org/jira/browse/NET-618
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 3.6
Reporter: Donald Kwakkel
Priority: Minor


Exception is printed to console in 
src/main/java/org/apache/commons/net/ftp/parser/MVSFTPEntryParser.java which 
can leak system information:
{code}
private boolean parseMemberList(FTPFile file, String entry) {
if (matches(entry)) {
file.setRawListing(entry);
String name = group(1);
String datestr = group(2) + " " + group(3);
file.setName(name);
file.setType(FTPFile.FILE_TYPE);
try {
file.setTimestamp(super.parseTimestamp(datestr));
} catch (ParseException e) {
e.printStackTrace();
// just ignore parsing errors.
// TODO check this is ok
return false; // this is a parsing failure too.
}
return true;
}

return false;
}
{code}





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NET-617) Heap Inspection: Passwords can be revealed from heap for ExtendedPop3Client

2017-02-28 Thread Donald Kwakkel (JIRA)

Donald Kwakkel created NET-617:
--

 Summary: Heap Inspection: Passwords can be revealed from heap for 
ExtendedPop3Client
 Key: NET-617
 URL: https://issues.apache.org/jira/browse/NET-617
 Project: Commons Net
  Issue Type: Bug
  Components: POP3
Affects Versions: 3.6
Reporter: Donald Kwakkel


In src/main/java/org/apache/commons/net/pop3/ExtendedPOP3Client.java password 
is a String. This should be bytes and be cleared after usage.
 
Similair issue as https://issues.apache.org/jira/browse/NET-616

Mitigation: proper protect memory of os process and heap dumps.

Abstract:

The method auth() in ExtendedPOP3Client.java stores sensitive data in a String 
object, making it impossible to reliably purge the data from memory.


Explanation:

Sensitive data (such as passwords, social security numbers, credit card numbers 
etc) stored in memory can be leaked if memory is not cleared after use. Often, 
Strings are used store sensitive data, however, since String objects are 
immutable, removing the value of a String from memory can only be done by the 
JVM garbage collector. The garbage collector is not required to run unless the 
JVM is low on memory, so there is no guarantee as to when garbage collection 
will take place. In the event of an application crash, a memory dump of the 
application might reveal sensitive data.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NET-616) Heap Inspection: Passwords can be revealed from heap

2017-02-28 Thread Donald Kwakkel (JIRA)

Donald Kwakkel created NET-616:
--

 Summary: Heap Inspection: Passwords can be revealed from heap
 Key: NET-616
 URL: https://issues.apache.org/jira/browse/NET-616
 Project: Commons Net
  Issue Type: Bug
  Components: IMAP
Affects Versions: 3.6
Reporter: Donald Kwakkel


password is used as string in 
src/main/java/org/apache/commons/net/imap/AuthenticatingIMAPClient.java. This 
should be passed as bytes and be cleaned after usage.

Abstract:

The method newStringUtf8() in Base64.java stores sensitive data in a String 
object, making it impossible to reliably purge the data from memory.


Explanation:

Sensitive data (such as passwords, social security numbers, credit card numbers 
etc) stored in memory can be leaked if memory is not cleared after use. Often, 
Strings are used store sensitive data, however, since String objects are 
immutable, removing the value of a String from memory can only be done by the 
JVM garbage collector. The garbage collector is not required to run unless the 
JVM is low on memory, so there is no guarantee as to when garbage collection 
will take place. In the event of an application crash, a memory dump of the 
application might reveal sensitive data.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MATH-1404) Test failure which occur with LC_ALL=en_US.UTF8, but not with LC_ALL=de_DE.UTF-8

2017-02-28 Thread Gilles (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15887903#comment-15887903
 ] 

Gilles commented on MATH-1404:
--

This test can fail with probability 0.01 even if the distribution of the random 
numbers is uniform.

If you run the test several times, you should get successes and failures that 
are not correlated to the local settings.


> Test failure which occur with LC_ALL=en_US.UTF8, but not with 
> LC_ALL=de_DE.UTF-8
> 
>
> Key: MATH-1404
> URL: https://issues.apache.org/jira/browse/MATH-1404
> Project: Commons Math
>  Issue Type: Bug
>Reporter: Karl Richter
>
>  Specifying `LC_ALL=en_US.UTF-8` causes test failures like 
> `RandomUtilsDataGeneratorJDKSecureRandomTest>RandomUtilsDataGeneratorAbstractTest.testNextLongNegativeRange:99->RandomUtilsDataGeneratorAbstractTest.checkNextLongUniform:130
>  Chisquare test failed p-value = 0.0082266579945659 chisquare statistic = 
> 25.3040006.` which don't seem to occur with `LC_ALL=de_DE.UTF-8`, see 
> https://travis-ci.org/krichter722/commons-math/jobs/205896548 for details



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MATH-1404) Test failure which occur with LC_ALL=en_US.UTF8, but not with LC_ALL=de_DE.UTF-8

2017-02-28 Thread Karl Richter (JIRA)

Karl Richter created MATH-1404:
--

 Summary: Test failure which occur with LC_ALL=en_US.UTF8, but not 
with LC_ALL=de_DE.UTF-8
 Key: MATH-1404
 URL: https://issues.apache.org/jira/browse/MATH-1404
 Project: Commons Math
  Issue Type: Bug
Reporter: Karl Richter


 Specifying `LC_ALL=en_US.UTF-8` causes test failures like 
`RandomUtilsDataGeneratorJDKSecureRandomTest>RandomUtilsDataGeneratorAbstractTest.testNextLongNegativeRange:99->RandomUtilsDataGeneratorAbstractTest.checkNextLongUniform:130
 Chisquare test failed p-value = 0.0082266579945659 chisquare statistic = 
25.3040006.` which don't seem to occur with `LC_ALL=de_DE.UTF-8`, see 
https://travis-ci.org/krichter722/commons-math/jobs/205896548 for details



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NET-619) SubnetUtils creates a binary netmask in a bad way

[jira] [Commented] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect

[jira] [Resolved] (LANG-1265) Build failures when building with Java 9 EA

[jira] [Commented] (LANG-1265) Build failures when building with Java 9 EA

[GitHub] commons-lang pull request #244: LANG-1265: Build failures when building with...

[GitHub] commons-lang pull request #247: JUnit imports

[GitHub] commons-lang issue #247: JUnit imports

[jira] [Comment Edited] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect

[jira] [Comment Edited] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect

[jira] [Commented] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect

[jira] [Commented] (NET-616) Heap Inspection: Passwords can be revealed from heap

[jira] [Created] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect

[jira] [Resolved] (NET-618) System Information Leak in ftp parser

[GitHub] commons-lang pull request #247: JUnit imports

[jira] [Commented] (NET-401) FTP class uses BufferedReader for control channel, which does not follow the standard

[jira] [Created] (NET-618) System Information Leak in ftp parser

[jira] [Created] (NET-617) Heap Inspection: Passwords can be revealed from heap for ExtendedPop3Client

[jira] [Created] (NET-616) Heap Inspection: Passwords can be revealed from heap

[jira] [Commented] (MATH-1404) Test failure which occur with LC_ALL=en_US.UTF8, but not with LC_ALL=de_DE.UTF-8

[jira] [Created] (MATH-1404) Test failure which occur with LC_ALL=en_US.UTF8, but not with LC_ALL=de_DE.UTF-8

20 matches

Site Navigation

Mail list logo

Footer information