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: [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: 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: [concurrency-interest] ThreadLocalRandom clinit troubles

Hi Peter, Irrc, ServiceLoader.load(NameServiceDescriptor.class) uses Thread.contextClassLoader to load the services. Depending how late the NameServices is getting initialized, perhaps it can be used to circumvent the loader available at clinit of InetAddress. I am not sure it could be a real secu

Re: [concurrency-interest] ThreadLocalRandom clinit troubles

I wonder why just don't use the /dev/random if available on *nix - implemented by sun.security.provider.NativePRNG or sun.security.mscapi.PRNG() on Windows that calls CryptGenRandom. Both support SecureRandomSpi.engineGenerateSeed(int) that provides an arbitrary amount of entropy. Although the appr

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

Re: ThreadLocalRandom clinit troubles

On 20/06/2014 15:02, Peter Levart wrote: And, as Martin pointed out, it seems to be used for tests that exercise particular responses from NameService API to test the behaviour of JDK classes. It would be a shame for those tests to go away. We've been talking about removing it for many years b

Re: ThreadLocalRandom clinit troubles

On 06/20/2014 03:00 PM, Alan Bateman wrote: On 20/06/2014 12:20, Peter Levart wrote: Hi, A patch that solves this is a patch to InetAddress. We can't suppress initialization of InetAddress as part of NetworkInterface initialization, but we can suppress initialization of NameService provider

Re: ThreadLocalRandom clinit troubles

On 20/06/2014 12:20, Peter Levart wrote: Hi, A patch that solves this is a patch to InetAddress. We can't suppress initialization of InetAddress as part of NetworkInterface initialization, but we can suppress initialization of NameService providers as part of InetAddress initialization by mo

Re: [concurrency-interest] ThreadLocalRandom clinit troubles

I'm in favor of Peters approach ( I would need to do a more detailed review though ). Looking up name service providers during initialization of InetAddress has been the cause of several issues in the past. I agree with Stanimir's point about TCCL, but I don't think we should try to do anyth

Re: ThreadLocalRandom clinit troubles

On 06/20/2014 11:10 AM, Peter Levart wrote: Perhaps a more lazy initialization of NetworkInterface class that does not trigger initialization of NS providers could help. We just need to invoke two methods on NetworkInterface: - static NetworkInterface.getNetworkInterfaces() - instance NetworkI

Re: ThreadLocalRandom clinit troubles

On 06/19/2014 08:04 PM, Martin Buchholz wrote: On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman wrote: On 19/06/2014 05:25, Martin Buchholz wrote: ThreadLocalRandom's clinit method creates an intermediate broken state of ThreadLocalRandom and then proceeds to run some networking code to get som

Re: ThreadLocalRandom clinit troubles

On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman wrote: > On 19/06/2014 05:25, Martin Buchholz wrote: > >> ThreadLocalRandom's clinit method creates an intermediate broken state of >> ThreadLocalRandom and then proceeds to run some networking code to get >> some >> more machine-specific entropy in i

Re: ThreadLocalRandom clinit troubles

On 19/06/2014 05:25, Martin Buchholz wrote: ThreadLocalRandom's clinit method creates an intermediate broken state of ThreadLocalRandom and then proceeds to run some networking code to get some more machine-specific entropy in initialSeed(). This will fail if the networking code ever recursively

Re: [concurrency-interest] ThreadLocalRandom clinit troubles

On 06/19/2014 08:32 AM, Stanimir Simeonoff wrote: I wonder why just don't use the /dev/random if available on *nix - implemented by sun.security.provider.NativePRNG or sun.security.mscapi.PRNG() on Windows that calls CryptGenRandom. Both support SecureRandomSpi.engineGenerateSeed(int) that provid

Re: ThreadLocalRandom clinit troubles

Hi Martin, What version of TLR are you looking at? As far as I remmember, the InetAddress-related code to obtain initial seed has been replaced by NetworkInterface.getHardwareAddress(). Is this still triggering the initialization of InetAddress or is this the case of using "java.util.secureRa