Hello , Applied in commit r1780108. Regards On Thu, Jan 19, 2017 at 5:58 PM, Rainer Jung <rainer.j...@kippdata.de> wrote:
> 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.j...@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 >>> >> -- Cordialement. Philippe Mouawad.
