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

Valerie Peng valerie.peng at oracle.com
Tue May 17 20:09:33 UTC 2016


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?
- "alternateName" should be "alternativeNames" now that it contains 
multiple values?
- 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.
- 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()?

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

<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?

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



More information about the security-dev mailing list