[8u] request for review: 8062552 Support keystore type detection for JKS and PKCS12 keystores

[Vincent Ryan]

Thanks Thomas and Sean for your review comments.

KeyStoreDelegator matches the JDK 9 version. I’ve moved it to the sun.security.package and modified it as suggested.
I also made JavaKeyStore package-private but DualFormatJKS needs to remain public.
The cert in trusted.pem is an arbitrary X.509 cert and I’ve added a comment in the TestKeystoreCompat test.

A new webrev is available at:
  http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/ <http://cr.openjdk.java.net/~vinnie/8062552/webrev.02/>



> On 22 May 2015, at 16:27, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Just a couple of other comments:
> 
> - Both JavaKeyStore and JavaKeyStore$DualFormatJKS can be package-private since they are only referenced from SunEntries which is in the same package. I would also move KeyStoreDelegator into sun.security.provider and make it package-private.
> 
> - Can you add a comment describing the contents of the trusted.pem cert in case we need to re-create it at some point in the future?
> 
> - In KeyStoreDelegator, I think most/all of the fields can be made final.
> 
> --Sean
> 
> On 05/21/2015 11:44 AM, Vincent Ryan wrote:
>> Please review this enhancement to JDK 8u that addresses a compatibility risk for certain applications that access
>> keystores across JDK 8 and JDK 9 releases. The issue arises because the default keystore type is now PKCS12 in
>> JDK 9 but is JKS in earlier releases. The problem can occur when a keystore is created on JDK 9 using the default
>> keystore type but accessed on JDK 8 also using the default keystore type. This keystore type mismatch results in
>> an error.
>> 
>> The change introduces a keystore compatibility mode for JKS keystores where both JKS and PKCS12 file formats are
>> understood. Similar behaviour is already present in JDK 9 (JEP-229). The keystore.type.compat security property
>> controls whether the mode is enabled or not. By default it is enabled.
>> 
>> This enhancement enables at risk applications to continue to function across JDK 8 and JDK 9 without requiring any
>> application code changes.
>> 
>> Thanks.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8062552
>> Webrev: http://cr.openjdk.java.net/~vinnie/8062552/webrev.01/
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150522/a39f7538/attachment-0001.html>