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