RFR 8024253: ThreadLocal random can use SecureRandom for the initial seed
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
> 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.
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