Code review request: 6733443: JCA/JCE init does not completely reset the delayed provider selection mechanism. (original) (raw)
Neil Richards neil.richards at ngmr.net
Wed Aug 8 12:19:56 UTC 2012
- Previous message (by thread): hg: jdk8/tl/jdk: 7189533: GetJavaProperties should free temporary file if subsequent allocations fails
- Next message (by thread): Code review request: 6733443: JCA/JCE init does not completely reset the delayed provider selection mechanism.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Valerie, Thank you for agreeing to take a look at this suggested change.
Please get back to me as soon as you have any questions, comments or observations on this.
Thanks, Neil
On Fri, 2012-07-27 at 17:15 -0700, Valerie (Yu-Ching) Peng wrote:
Neil,
Thanks for the feedback, I will take a look and let you know my thoughts sometime next week. Valerie 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 > * java.security.Signature > 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]http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html#DelayedSelect > [2]http://bugs.sun.com/bugdatabase/viewbug.do?bugid=6733443 > [3]http://cr.openjdk.java.net/~ngmr/6733443/webrev.00/ >
-- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
- Previous message (by thread): hg: jdk8/tl/jdk: 7189533: GetJavaProperties should free temporary file if subsequent allocations fails
- Next message (by thread): Code review request: 6733443: JCA/JCE init does not completely reset the delayed provider selection mechanism.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]