Thank you Max for the review.
This seems to be true that the actual provider may be selected when
Signature.init() is called. At least, I see that
Signature.engineInitSign() may call chooseProvider() method.
http://hg.openjdk.java.net/jdk9/dev/jdk/file/a54e33fc0f2d/src/java.base/share/classes/java/security/Signature.java#l1197
Artem
On 03/08/2017 05:57 PM, Weijun Wang wrote:
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
