[11u] RFR: 8243029: Rewrite javax/net/ssl/compatibility/Compatibility.java with a flexible interop test framework
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Thu Jul 23 09:04:49 UTC 2020
Hi Matthias
> Seems jdk11 does only know the name of TLS_CHACHA20_POLY1305_SHA256 but nothing more , the real support came with jdk12.
> Some other folks were struggeling with this too :
> https://jira.mariadb.org/browse/CONJ-721
>
> Maybe there is a chance to backport it to jdk11 in future (of course it is a separate issue) ?
On the one side, it would be good if all VMs supported the same certificates.
On the other side, this is a functional change, e.g. as "8140466: ChaCha20 and Poly1305
TLS Cipher Suites" requires a CSR. As you probably noted, there are
quite some resistances against downporting functional changes ...
see the Shenandoah discussion.
After my initial RFR, a fix for the test was pushed to jdk/jdk:
https://bugs.openjdk.java.net/browse/JDK-8245005
javax/net/ssl/compatibility/BasicConnectTest.java failed with No enum constant
With this fix the issues I see are fixed. It should be downported, too.
> Could you file a separate bug for the readme, I guess this needs fixing in jdk/jdk too .
The follow up fix also corrects the test name in the README I had
complained about in my first RFR.
Also, I figured that I need not specivy -m to run manual tests, it
sufficies to remove -a from the command line.
Still mentioning this in the README would be usedufl, but I don't
feel like opening a change only for this.
I did two adaptions to the change, though:
http://cr.openjdk.java.net/~goetz/wr20/8243029-ssl_test_framework-jdk11/02/
Find the incremental patch below.
Best regards,
Goetz.
--- a/test/jdk/javax/net/ssl//compatibility/HrrTest.java
+++ b/test/jdk/javax/net/ssl//compatibility/HrrTest.java
@@ -88,8 +88,7 @@
List<TestCase<ExtUseCase>> testCases = new ArrayList<>();
for (CipherSuite cipherSuite : new CipherSuite[] {
CipherSuite.TLS_AES_128_GCM_SHA256,
- CipherSuite.TLS_AES_256_GCM_SHA384,
- CipherSuite.TLS_CHACHA20_POLY1305_SHA256}) {
+ CipherSuite.TLS_AES_256_GCM_SHA384}) {
testCases.add(createTestCase(cipherSuite));
}
return testCases;
--- a/test/jdk/javax/net/ssl//compatibility/README
+++ b/test/jdk/javax/net/ssl//compatibility/README
@@ -21,9 +21,9 @@
##### Summary #####
This test is used to check the interop compatibility on JSSE among different
-JDK releases. The oldest version supported by the test is JDK 7. Some of Java
+JDK releases. The oldest version supported by the test is JDK 8. Some of Java
source files, like JdkInfoUtils.java, JdkProcServer.java and JdkProcClient.java,
-use only JDK 7-compliant language features and APIs, in order to allowing
+use only JDK 8-compliant language features and APIs, in order to allowing
different JDK releases can load and run associated classes.
##### Usage #####
@@ -47,7 +47,6 @@
##### Usage Examples #####
$ cat /path/to/jdkList
-/path/to/jdk7
/path/to/jdk8
/path/to/jdk9
/path/to/jdk10
@@ -57,6 +56,6 @@
-Dtest.jdk.list.file=/path/to/jdkList \
$JDK_WS/jdk/test/javax/net/ssl/compatibility/Compatibility.java
The above example uses a file "/path/to/jdkList" to contain the paths of local
-different JDK builds through 7 to 10. The execution uses each of JDK builds as
+different JDK builds through 8 to 10. The execution uses each of JDK builds as
server and client respectively. And it enables SSL debug flag, and tests the
full parameter value set.
More information about the jdk-updates-dev
mailing list