[concurrency-interest] ThreadLocalRandom clinit troubles

[Bernd]

SecureRandom is unfortunatelly pretty  complex. It is interpreting the seed
url in some way (the configuration you mentioned behave very special since
Java 6) , it is mixing seed and continues data and it reorders the
implementations used.

JEP 123 intended to clear things, but getInstanceStrong() (which nobody
uses?!) did not improve things IMHO.

Bernd

PS: I think the webrev changed since then, but the mail from Brad describes
the problem well:
http://mail.openjdk.java.net/pipermail/security-dev/2013-January/006288.html
Am 14.07.2014 21:05 schrieb "Oleksandr Otenko" <oleksandr.otenko at oracle.com
>:

>  Can someone summarize what happened?
>
> SecureRandom used to get entropy from /dev/random, which is configurable
> through a policy file to /dev/urandom. Has this changed?
>
> Alex
>
> On 12/07/2014 00:33, Martin Buchholz wrote:
>
>  Thanks to Peter for digging into the secure seed generator classes and
> coming up with a patch.  Openjdk security folks, please review.  I confess
> to getting lost whenever I try to orient myself in the twisty maze of seed
> generator implementation files.
>
>  Anyways, it seems important to have prngs like ThreadLocalRandom be able
> to get a few bits of seed entropy without loading hundreds of classes and
> without occupying any file descriptors permanently.  Perhaps at Google we
> will go back to writing some simple non-portable startup code to read
> /dev/urandom until openjdk security team comes up with a more principled
> solution (but one that doesn't drag in too much machinery).
>
>
> _______________________________________________
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20140714/0c661c6d/attachment.htm>