accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2943) Usage of SecureRandom with "SUN" as RNG provider causes lots of failures
Date Tue, 01 Jul 2014 16:02:24 GMT


ASF GitHub Bot commented on ACCUMULO-2943:

Github user busbey commented on the pull request:
    please make sure your commit is against the current head of the earliest dev branch the
jira is filed against.  It looks like some of your pom changes are out of date.

> Usage of SecureRandom with "SUN" as RNG provider causes lots of failures
> ------------------------------------------------------------------------
>                 Key: ACCUMULO-2943
>                 URL:
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: build
>    Affects Versions: 1.6.0
>         Environment: IBM JVM
>            Reporter: Hayden Marchant
>            Assignee: Hayden Marchant
>             Fix For: 1.6.1, 1.7.0
> Both & org.apache.accumulo.core.file.rfile.RFileTest
have lots of failures due to calls to SEcureRandom with Random Number Generator Provider hard-coded
as Sun. The IBM JVM has it's own built in RNG Provider called IBMJCE. 2 issues - hard-coded
calls to SecureRandom.getInstance(<algo>,"SUN") and also default value in Property class
is "SUN". 
> Options for proposals:
> 1. Add mechanism to override default Property through System property through new annotator
in Property class. Only usage will be by Property.CRYPTO_SECURE_RNG_PROVIDER
> The default is SUN, as coded in the Property class. 
> Some of the unit tests explicitly call SecureRandom.getInstance() with SUN as provider.
Others rely on the default value, which is SUN (and do not rely on accumulo-site.xml in which
this can be overridden). For the system tests, I propose adding an override through a System
property. For regular execution of accumulo, accumulo-site.xml can include the adjusted default.
However, system tests will also fall on same problem.
> Another solution would be to have a factory class which supplies JVM specific behaviour,
such as default NRG provider - this could be used by the Property class to retrieve this value
based on the for java.vendor etc.....

This message was sent by Atlassian JIRA

View raw message