[9] RFR: 8176183: sun/security/mscapi/SignedObjectChain.java fails on Windows

Weijun Wang weijun.wang at oracle.com
Thu Mar 9 01:57:54 UTC 2017



On 03/09/2017 09:55 AM, Artem Smotrakov wrote:
> Hi Max,
>
> I am not sure if SunMSCAPI has higher priority than SunJCE, SUN, etc on
> Windows. But this test is for SunMSCAPI provider, so we explicitly set
> this provider for Signature.

OK. You fix is good then.

What I was saying that even if SunMSCAPI is not the preferred provider, 
after you call Signature.getInstance("SHA256withRSA") the actual 
provider is not finally determined. When you call sig.init(key, SIGN), 
it will choose key's provider as its own provider.

At least this is how to I understand it.

Thanks
Max

>
> Artem
>
>
> On 03/08/2017 04:50 PM, Weijun Wang wrote:
>> I remember Signature is able to automatically switch to the correct
>> provider when its init(key) is called. Does this mean you don't need
>> to care about Signature.getInstance(alg,provider)?
>>
>> Thanks
>> Max
>>
>> On 03/09/2017 05:52 AM, Artem Smotrakov wrote:
>>> Hello,
>>>
>>> The test fails with "Key type not supported" error on Windows only with
>>> SunMSCAPI provider. It happens because the test passes an incompatible
>>> key object to Signature instance. Please see more details in
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8176183?focusedCommentId=14058876&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14058876
>>>
>>>
>>>
>>> The following patch updates Chain.java (which is used by
>>> SignedObjectChain.java) to use specified security provider for both key
>>> generation and singing.
>>>
>>> I ran all tests which depend on Chain.java on all generic platforms,
>>> they worked fine.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176183
>>>
>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8176183/webrev.00/
>>>
>>> Artem
>>>
>



More information about the security-dev mailing list