Re Re: [14] RFR 8162628: Migrate cacerts keystore from JKS

[Weijun Wang]

> On Aug 16, 2019, at 2:49 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> 
>>>>   https://cr.openjdk.java.net/~weijun/8162628/webrev.00
>>>> 

>>> KeyStoreDelegator:
>>> * Please avoid iterating a list like an array and using List#get(int).
>> 
>> But I have 2 lists. It is a Pair but Java does not have it, and I don't like Map::Entry very much.
> 
> Granted, by why not use two iterators then?

How?

> 
>>> 
>>> I will also pass a pretty large cacerts with public CA and our CAs and
>>> see wether your parser doesn't choke on it.
> 
> Did you get a change to parse the file I have sent you?

Yes I tried. keytool -list accepts it and is using SHA-256 fingerprint as aliases.

> 
>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement.
> 
> Commons Codec has a Base64InputStream. Maybe the entire file should be read as a stream with specific substreams
> for the base64 parts? That is, of course, much more coding work.

If the certs are to be parsed at loading, I'll see if I can inline a BASE64 decoder inside so it recognizes everything from BASE64 chars, -----'s, and @alias. If the cert parsing can be delayed I'll see if there is a quicker way to find the end of the cert (maybe read the first few bytes and get the length).

> 
> Looking forward for your improvements.
> 
> Do you see a change to backport this code to 11 and 8, but not changing the default keystore type? With that
> this great change could be available way earlier than Java 17 for most LTS people.

There is no need to change the default keystore type if keystore.type.compat=true and we allows a PEM keystore to be loadable as a JKS keystore.

I cannot say if this can be backported. It depends on the policy. On the other hand, you also know there are other vendors of JDK that could have different policies.

Thanks,
Max

> 
> Regards,
> 
> Michael