Re: [concurrency-interest] ThreadLocalRandom clinit troubles

I support Peter at al's plan to add an API that ThreadLocalRandom et al can use to get some system entropy without unbounded class dependency loading. It should not surprise anyone that at Google, we are most interested in running on Linux, so while we're waiting for a proper fix to happen we are

Re: [concurrency-interest] ThreadLocalRandom clinit troubles

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()

Re: [concurrency-interest] ThreadLocalRandom clinit troubles

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 comin

Re: ThreadLocalRandom clinit troubles

Hi Sean, Alex Here's a sum-up post: http://mail.openjdk.java.net/pipermail/security-dev/2014-June/010700.html Regards, Peter On 07/14/2014 04:44 PM, Sean Mullan wrote: I don't see a pointer to the webrev/patch -- did you forget to include it? --Sean On 07/11/2014 07:33 PM, Martin Buchholz

Re: ThreadLocalRandom clinit troubles

I don't see a pointer to the webrev/patch -- did you forget to include it? --Sean On 07/11/2014 07:33 PM, 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 when

Re: ThreadLocalRandom clinit troubles

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 lik

Re: ThreadLocalRandom clinit troubles

On 6/26/2014 4:10 PM, Doug Lea wrote: This seems to be the best idea yet, assuming that people are OK with the changes to sun.security.provider.SeedGenerator and NativeSeedGenerator.java I've been meaning to review this thread, but have been chasing several urgent escalations. Brad

Re: ThreadLocalRandom clinit troubles

Peter: Thanks very much for attacking the shocking impact/complexity of getting a few seed bits. On 06/25/2014 01:41 PM, Peter Levart wrote: Peeking around in the sun.security.provider package, I found there already is a minimal internal infrastructure for obtaining random seed. It's encapsula

Re: ThreadLocalRandom clinit troubles

To sum-up: We have a problem with TLR initialization since by default it uses networking code to compute initial "seeder" value which can execute user code in at least two situations: - when "sun.net.spi.nameservice.provider" system property is defined to use custom NameService provider - whe

Re: ThreadLocalRandom clinit troubles

On 06/24/2014 06:01 PM, Martin Buchholz wrote: On Tue, Jun 24, 2014 at 7:03 AM, Peter Levart > wrote: I would rather use SecureRandom.generateSeed() instance method instead of SecureRandom.nextBytes(). Why? Because every SecureRandom instance has

Re: ThreadLocalRandom clinit troubles

Hi Martin, On 06/22/2014 07:12 PM, Martin Buchholz wrote: We know that loading the networking machinery is problematic. On Linux we would be content to hard-code a read from /dev/urandom, which is safer and strictly more random than the existing network hardware determination, but y'all will re

Re: ThreadLocalRandom clinit troubles

Martin, Thanks for filing. I was positive there was already a bug for this, but for the life of me I can't find it now. There's some other more minor cleanup that needs to take place, but seems like I've been in escalation/firefighting mode for more than a year now and it hasn't bubbled to