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

[Thomas Lußnig]

On 23.05.2015 10:59, Vincent Ryan wrote:
> The aim of this enhancement is to address a specific compatibility risk for JKS and
> not to offer a general purpose mechanism for loading any keystore type. In general,
> the keystore type should match the keystore file format.
>
> In JDK 9 there is a new probe mechanism for keystores that is more similar to
> what you are proposing. The advantage of that mechanism is that the keystore
> type will exactly match the keystore file format.
When there is already an new probe mechanism for keystore detetion, why
do not backport/use it ?
Why build this limited version for one single usecase instead of using
the more gerneral solution ?
>
>> On 23 May 2015, at 09:42, Thomas Lußnig <openjdk at suche.org> wrote:
>>
>> Hi,
>>
>> 1) Would it not be an good idea to check the first bytes of the message
>> so that the dual class already know what type the stream is
>> and there is no unnecessary instanciation of exceptions and engine class?
>> 2) If we add an "smart" keystore why we limit it to two types? I do not
>> see any reason why it should not be possible to add other store types to:
>> - JCEKS
>> - PKCS11
>> It could be extended via securit property
>> java.security.smartKeystore.<N>.type = PKCS11
>> java.security.smartKeystore.<N>.magic = <HexSequence> (Optional for
>> Performance)
>> java.security.smartKeystore.<N>.engineClass = CanonicalEngine Class Name
>>
>> This would be only an small code change but an usefull improvement.
>>
>> Gruß Thomas
>>
>>
>> On 22.05.2015 22:01, Sean Mullan wrote:
>>> Looks fine to me.
>>>
>>> --Sean
>>>
>>> On 05/22/2015 03:10 PM, Vincent Ryan wrote:
>>>> 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/