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
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
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
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
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()
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
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
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
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
- when
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
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
On 06/19/2014 08:04 PM, Martin Buchholz wrote:
On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman alan.bate...@oracle.com
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
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
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
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
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
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
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
On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman alan.bate...@oracle.com
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
19 matches
Mail list logo
