jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: securerandom.source value change in Java 8 vs Java 7
Date Thu, 19 Jan 2017 16:58:33 GMT
Am 18.01.2017 um 22:56 schrieb Philippe Mouawad:
> Hi Rainer,
> Thanks a lot for your answer.
>
> For reference the bug you mention is mentioned here:
> http://security.stackexchange.com/questions/40633/java-
> securerandom-doesnt-block-how
>
> So if I understand you correctly, don't you think we should advise users of
> JMeter to use /dev/urandom as we're switching to Java 8 and my
> understanding is that it can introduce blocking behaviour ?

So for the forthcoming 3.2 since we only support it on Java 8 I'd say 
let's add

-Djava.security.egd=file:/dev/urandom

to the startup commandline in the start script. It looks less strange 
than the /dev/./urandom variant and it does solve the blocking problem 
for Java 8. Using real blocking randomness should not be necessary for 
JMeter.

If people ask for JMeter before 3.2 then the best advice would be to use

-Djava.security.egd=file:/dev/./urandom

because that will work independent of Java version.

Regards,

Rainer

> On Wed, Jan 18, 2017 at 10:51 PM, Rainer Jung <rainer.jung@kippdata.de>
> wrote:
>
>> Am 18.01.2017 um 17:54 schrieb Philippe Mouawad:
>>
>>> Hello,
>>> Anybody knows why in  Java 8 on Mac OSX / Linux / Windows (but is it ) (at
>>> least in last update but maybe in others)  version:
>>>
>>>    - securerandom.source=file:/dev/random
>>>
>>> While in last Java 7 version:
>>>
>>>    - securerandom.source=file:/dev/urandom
>>>
>>> From my experience this could have very bad performance on Linux servers
>>> for example and could block.
>>>
>>> Is it because something has changed in Java 8 ?
>>> Reading the comments in java.security file, I don't see / understand what.
>>>
>>> Thanks for any feedback.
>>>
>>
>> Note that due to a JVM bug (I'm inclined to call it a bug) for Java up
>> until version 7 although file:/dev/urandom is configured it will actually
>> use file:/dev/randum (no "u"). That's why one typically finds the
>> suggestion to use file:/dev/./urandom or file:/dev//urandom instead (any
>> URL that is semantically equivalent to file:/dev/urandom but not stringwise
>> identical will do).
>>
>> For Java 8 the bug got fixed but the same time they changed the default
>> maybe to not switch the effective default behavior. So now one again needs
>> a non-default setting to ensure non-blocking behavior. For java 8,
>> file:/dev/uranom will do, but the old workaround file:/dev/./urandom
>> suggested for Java 7 will still do for Java 8.
>>
>> Regards,
>>
>> Rainer

Mime
View raw message