hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14089) Remove unnecessary draw of system entropy from RecoverableZooKeeper
Date Wed, 15 Jul 2015 22:04:05 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628835#comment-14628835

Andrew Purtell commented on HBASE-14089:

bq. Should we just add -Djava.security.egd=file:/dev/./urandom to the command line flags if
/dev/urandom exits?

We want SecureRandom, where it is used with necessity in SSL and encryption code, to draw
from /dev/random. Changing the device to /dev/urandom would not be advisable.  There's nothing
wrong with use of SecureRandom where it's appropriate. I think what RZK is doing doesn't require
guaranteed high quality randomness so we can just use Random's PRNG instead. 

-Djava.security.egd=file:/dev/./urandom is useful for testing mostly in my opinion.

> Remove unnecessary draw of system entropy from RecoverableZooKeeper
> -------------------------------------------------------------------
>                 Key: HBASE-14089
>                 URL: https://issues.apache.org/jira/browse/HBASE-14089
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Andrew Purtell
>            Assignee: Andrew Purtell
>            Priority: Minor
>             Fix For: 2.0.0, 0.98.14, 1.2.0, 1.1.2, 1.3.0, 1.0.3
>         Attachments: HBASE-14089.patch
> I had a look at instances where we use SecureRandom, which could block if insufficient
entropy, in the 0.98 and master branch code. (Random in contrast is a PRNG seeded by System#nanoTime,
it doesn't draw from system entropy.) Most uses are in encryption related code, our native
encryption and SSL, but we do also use SecureRandom for salting znode metadata in RecoverableZooKeeper#appendMetadata,
which is called whenever we do setData. Conceivably we could block unexpectedly when constructing
data to write out to a znode if entropy gets too low until more is available. 

This message was sent by Atlassian JIRA

View raw message