Hello,
Please review this patch for SecureRandom tests which may fail with
timeout because SeedGenerator. generateSeed() may block on /dev/random.
The tests now use /dev/urandom instead. They also run in othervm mode
since "java.security.egd" system property seems to be read once while
initialization of security providers, see
sun/security/provider/SunEntries.java for details.
I was not able to reproduce
sun/security/provider/SecureRandom/StrongSecureRandom.java failure. This
test sets "securerandom.source" to "/dev/urandom", but
"java.security.egd" system property may override it (see comments in
java.security file). I just updated the test to reset
"java.security.egd" system property.
The patch also fixes https://bugs.openjdk.java.net/browse/JDK-8156606
Most of other SecureRandom tests modify security properties (for example
"securerandom.drbg.config"), and then restore them. It seems to be fine
if some properties can be updated at runtime. But it still may affect
other tests which run in the same JVM if the original value was not
restored properly. For example, see
java/security/SecureRandom/GetInstanceTest.java:
http://hg.openjdk.java.net/jdk9/dev/jdk/file/f0c1d4d90df6/test/java/security/SecureRandom/GetInstanceTest.java#l80
...
Security.setProperty(STRONG_ALG_SEC_PROP, "DRBG:SUN");
sr = matchExc(() -> SecureRandom.getInstanceStrong(),
PASS, NoSuchAlgorithmException.class,
"PASS - Undefined security Property "
+ "'securerandom.strongAlgorithms'");
checkAttributes(sr, "DRBG");
Security.setProperty(STRONG_ALG_SEC_PROP, origDRBGConfig);
...
It doesn't use try-finally block to restore the security property. So
the risk that it may affect other tests is higher. It may be better to
run all tests which modify system/security properties to run in othervm
mode to avoid potential issues. Although it would slow down test execution.
Bugs:
https://bugs.openjdk.java.net/browse/JDK-8157344
https://bugs.openjdk.java.net/browse/JDK-8156606
Webrev: http://cr.openjdk.java.net/~asmotrak/8157344/webrev.00/
Artem
