[8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location

[Alexey Bakhtin]

Hello Martin,

As I mentioned before, I expect no regression with ORIGINAL TLSv1.2 implementation after Step 9 .
On this Step, I do not expect all test pass on the new TLSv1.3 implementation because of difference in the Cipher Suites, ordering, protocols and so on.
So, on this Step should not be any regression if run with original TLSv1.2 implementation
I just found one test issue caused by latest test relocation to the sun/net/www/protocol/https directory.
Test sun/net/www/protocol/https/HttpsURLConnection/B6216082.java is fixed (the changes in this test only).
Updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v3/
GIT diff : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v3/jdk.git.diff

On the Step 10 I removed all tests failed with NEW TLSv1.3 implementation. So remaining test passed with ORIGINAL TLSv1.2 and NEW TLSv1.3 implementations.

Note 1: NEW TLSv1.3 implementations passes with new keystore files only  - javax/net/ssl/etc/keystore and javax/net/ssl/etc/trustore
Note 2: sun/security/ssl/HandshakeHash/HandshakeHashCloneExhaustion.java fails because of javax/net/ssl/templates/SSLSocketTemplate.java removed on this Step. This test passed after step 11 because of new  SSLSocketTemplate.java is added.

On the Step 11 tests are updated from JDK 11.07. After this step all test should pass with the NEW TLSv1.3 implementation

Regards
Alexey

> On 29 Jul 2020, at 00:24, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Alexey,
> 
> On 7/27/20 2:47 AM, Alexey Bakhtin wrote:
>>> 3) Should we expect all tests passing in Step 9? If not, why? I read
>>> 'no regression' in your first comment but that does not say whether
>>> they are all passing or not.
>> 
>> I can not say all test passed, because of three test fails on the original TLSv1.2 implementation
>> and original test file location :
>> - javax/net/ssl/ciphersuites/DisabledAlgorithms.java
>> - sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/PreferredKey.java
>> - sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java
>> These test still fails after relocation with original TLSv1.2 implementation.
>> This is a reason I wrote “no regression” instead of all test passed.
>> 
> 
> I've found some regressions after Webrev.02 on sun/security/ssl tests
> category. A couple of examples:
> 
> CustomizedDefaultProtocols.java:
> ....................................
> 
> * Passing in JDK-8 (located in
> sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java)
> and failing in Webrev.02 (located in
> sun/security/ssl/SSLContextImpl/CustomizedDefaultProtocols.java).
> Apparently, TLSv13 is not among the expected protocols in the test
> assertions.
> 
> LengthCheckTest.java
> ....................................
> 
> * Passing in JDK-8 (located in
> sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java)
> and failing in Webrev.02 (located in
> sun/security/ssl/ClientHandshaker/LengthCheckTest.java). Apparently,
> after Step 1 ProtocolVersion.valueOf changed the signature to receive
> 'byte' arguments instead of 'int'; and that's preventing the test from
> compiling.
> 
> ....................................
> 
> There are around 15 more in this category. I've not tested other categories.
> 
> Am I doing something wrong? Is the expectation of having no regressions
> still correct for Step 9? I'm not very surprised by these results and
> it's not my expectation for tests to pass until Step 11 (where they are
> updated to work with the new TLS engine). In case there is one still
> failing after Step 11, then we can analyze it. What do you think?
> 
> Thanks,
> Martin.-
>