[8u] RFR : TLSv1.3 protocol support

Martin Balao mbalao at redhat.com
Tue May 19 22:09:26 UTC 2020


Hi,

I verified the following changes on Step 1:

 * SunJSSE.java
  * TLSv1.3 protocol definition added.
  * The hook that adds 'Object' as a template parameter is not necessary
because in JDK-8 it's already there
   * JDK-8 does not have 8078468 that removes it
  * No additional changes in 8196584
  * Ok

 * java.security-os
  * Verified that the file was updated for all supported OSs
  * Verified that the content is identical to java.security in 8196584
  * Ok

 * All files in the changeset are new files, except for the 6
java-security-os modifications
 * Ok

 * All new files are within sun/security/ssl directory, as planned
 * Ok

 * Files once Step 1 is applied that are not present in JDK 11.0.7
  * krb5 directory (with KerberosClientKeyExchangeImpl.java,
KerberosPreMasterSecret.java and Krb5ProxyImpl.java inside)
  * KerberosClientKeyExchange.java
  * Krb5Helper.java
  * Krb5Proxy.java
  * I'm ok with keeping the Kerberos code, as said in [0].

 * All the files in JDK 11.0.7 are identical to those added by Step 1,
except for:
  * DTLSInputRecord.java
   * Not added by Step 1
   * If we are going to have a patch that removes DTLS (Step 2), I
suggest to add this file now and remove it later. Looks to me that not
adding this file now is mixing some parts of Step 2, and making it
harder to understand for the one who looks at Step 1 only.
  * DTLSOutputRecord.java
   * Not added by Step 1 - see above
  * DTLSRecord.java
   * Not added by Step 1 - see above
  * EphemeralKeyManager.java
   * This should be fixed in Step 0, in my opinion
  * HelloVerifyRequest.java
   * Why?
  * SunJSSE.java
   * Ok, we will accept this for the reasons stated in [1].
  * JsseJce.java
   * Even though the Kerberos part won't be removed, I suggest to align
all the trivial format changes; so when backporting future changes we
avoid unnecessary conflicts there.
  * KeyManagerFactoryImpl.java
   * This should be fixed in Step 0, in my opinion

Overall, I suggest as a general criteria to avoid including steps 'from
the future' even if that means adding a file to be removed later. Even
though I can understand the exceptions we did for Kerberos and
SunJSSE.java, they are still around my head... I'm not 100% convinced.

On a final note, I suggest to open different JIRA bugs for each Step. We
can handle each Step as a Subtask of a Master ticket. We will have 10
separate reviews, against each proposal.

Thanks,
Martin.-

--
[0] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011735.html
[1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011717.html



More information about the jdk8u-dev mailing list