Code review request: 6733443: JCA/JCE init does not completely reset the delayed provider selection mechanism.

Valerie (Yu-Ching) Peng valerie.peng at
Fri Jul 27 17:15:59 PDT 2012


Thanks for the feedback, I will take a look and let you know my thoughts 
sometime next week.


On 07/23/12 21:13, Neil Richards wrote:
> Hi all,
> The PKCS11 documentation [1] describes how the selection of a security
> provider implementation is (re-)performed each time any initialization
> (init*) method is called on objects of the classes:
>        * javax.crypto.Cipher
>        * javax.crypto.KeyAgreement
>        * javax.crypto.Mac
>        *
> so that a suitable implementation is chosen for the Key object given to
> these initialization methods.
> This behaviour, whose description was introduced in Java 5, is entirely
> sensible (from a user's point of view), I think.
> However, the (Sun/Oracle/OpenJDK) implementation was not modified to
> actually implement the described behaviour.
> Java bug 6733443 was raised to report the discrepancy [2].
> I have created a webrev [3] with suggested changes to make the
> implementation conform to the described behaviour.
> It also holds a testcase for the change, which has a bespoke (minimally
> implemented) test-specific Provider implementation and associated
> classes. These implementations contain function just sufficient for the
> tests' needs, to support things to the point of initialization. All
> other functions are stubbed out.
> Also, the (invocation of the) tests for Cipher, KeyAgreement&  Mac are
> currently commented out, as they will only work when the provider is
> held in a signed jar file, and I wasn't sure how to accomplish that in a
> jtreg test.
> However, I have successfully run all these tests using versions of the
> Cipher, KeyAgreement&  Mac classes which have been mildly hacked to
> remove their check to JceSecurity.canUseProvider() in chooseProvider().
> Please review the suggested fix and let me your thoughts on it.
> Thanks,
> Neil
> [1]
> [2]
> [3]

More information about the security-dev mailing list