RFR 8155847: SHA groups needed for jdk.security.provider.preferred

[Anthony Scarpino]

On 05/17/2016 01:09 PM, Valerie Peng wrote:
> Hi Tony,
>
> Here are some comments/questions:
> <ProviderList.java>
> - make PreferredEntry class static? Are these fields accessed directly
> by other classes? If not, then we can mark them private?

Yes they can be private and the class static.

> - "alternateName" should be "alternativeNames" now that it contains
> multiple values?

sure

> - In the match method, ls it really necessary to print value of (t,a) on
> line 739 for all alternateName values? It's already printed out earlier.

removing that part of the debug is fine.

> - with the current webrev, the Group.XXX entries will have type = null,
> algorithm = null, its toString() will print out [, null: provName].
> Doesn't seem quite right? Maybe it's worthwhile to keep the type and
> algorithm but then detect and special handling it in the match()?

I was trying to avoid using another variable, but I admit the debug 
prints suffer without a boolean.  I added a boolean called "group" that 
will be the check.

>
> <PreferredProviderTest.java>
> - line 81 - 85, shouldn't it be "SunJCE" instead of "SUN"? Would this
> not lead to a test failure?

Yes.. thanks..

>
> <java.security>
> - So, as we add more algorithms, say RSA or DSA signatures using
> SHA-512/224 or SHA-3 family of digests to the default list of providers,
> then we update the values here again (Currently, Group.SHA2 contains
> different values to the rest of SHA2 application (Hmac, Signature)
> groups) and again file CCCs for this? Would this limit our capability to
> add more algorithms to update releases?

We would have to file a CCC for the change to the config, but there 
would be no problems with adding to updates.  Anything that doesn't 
match a preferred provider entry is passed onto the normal security 
provider list for processing.

>
> Thanks,
> Valerie
>
> On 5/11/2016 3:46 PM, Anthony Scarpino wrote:
>> Hi
>>
>> I need a review of my changes to jdk.security.preferred.provider to
>> add Groups.  This makes it a lot cleaner for support a group of
>> algorithms that are very similar, such as SHA2 (aka SHA224, SHA256,
>> SHA384, ... )
>>
>> http://cr.openjdk.java.net/~ascarpino/8155847/webrev/
>>
>> thanks
>>
>> Tony