RFR 8024253: ThreadLocal random can use SecureRandom for the initial seed

Peter Levart peter.levart at gmail.com
Mon Sep 16 14:39:03 UTC 2013

On 09/16/2013 04:25 PM, Alan Bateman wrote:
> On 16/09/2013 15:00, Paul Sandoz wrote:
>> Hi Peter,
>> Nice observation about name resolving.
>> On my MacBook, if i switch off the wifi, then 7 addresses are 
>> returned 4 for the en0 and 3 for lo0. Seems overkill to use all of 
>> them and the sub-interefaces, if any. I agree with Doug, selecting 
>> the first interface's MAC address is probably sufficient.
> We periodically come across environments where they are a lot (as in 
> hundreds) of network interfaces configured and might indeed be 
> overkill to use bits from all of them.
> On getHardwareAddress then there are platforms where you need to be 
> root or have special privileges to get the mac address so this is one 
> reason why it might return null. I see Doug's patch handles this and 
> I'm just mentioning in that it may not be source of bits in some 
> environments.
> For the security manager case there is a permission check to avoid 
> leaking details about the environment to untrusted code. So to be 
> useful when running with a security manager will require it to be done 
> as a privileged action.
> -Alan.


So perhaps the right strategy would be to get the hardware address of 
the 1st interface that has it, but don't bother to search more than N 
interfaces (if 1st N interfaces don't return HW address then it is a 
good chance that OS security does not allow accessing them). Testing at 
least 2 interfaces would allow to skip over loopback in environments 
where it is returned as 1st interface. Other kinds of interfaces that 
don't have hardware address are some Point-to-Point interfaces (VPN 
interfaces for example).


More information about the core-libs-dev mailing list