Re: RFR 7191662: JCE providers should be located via ServiceLoader
Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. There are other discussions ongoing and we should be able to reach a decision in a day or two. Will update the list again. Thanks, Valerie On 06/01/15 16:39, Magnus Ihse Bursie wrote: On 2015-05-29 00:10, Valerie Peng wrote: Please find comments in line... On 5/27/2015 3:42 PM, Mandy Chung wrote: Valerie, Did you see my comment yesterday? http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html Yes, we exchanged emails after this above one. I will follow up your latest one later today. Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let’s remove the META-INF files in the first push and the build change. The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. I’ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev Ok. Thanks, Valerie I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? /Magnus . Mandy On May 27, 2015, at 3:29 PM, Valerie Pengvalerie.p...@oracle.com wrote: Hi, build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. The rest of source code changes are reviewed by my team already. Thanks, Valerie (Java Security Team)
Re: Building sunpkcs11.jar
The provider built from OpenJDK workspace is unsigned. It can't be used with Oracle 7u4 JRE which require crypto provider to be signed for export/import conformance. If Your company has a JCE code signing keypair, you can sign the provider built using OpenJDK with that keypair and then use it w/ Oracle 7u4 JRE. Thanks, Valerie On 05/23/12 08:54, Deneau, Tom wrote: I want to be able to modify and rebuild lib/ext/sunpkcs11.jar. When I do a make all; make images everything completes successfully. With javap, I can see my modified class in the build/linux-amd64/j2sdk-image/jre/lib/ext When I use this built ext directory as a replacement of the Oracle 7U4 JRE, and run some code that does KeyGenerator gen = KeyGenerator.getInstance(AES); I get Test1,java.security.NoSuchAlgorithmException: AES KeyGenerator not available at javax.crypto.KeyGenerator.init(KeyGenerator.java:158) at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:207) This code runs successfully with the regular Oracle 7U4 JRE. Am I missing something in the build process? -- Tom Deneau
Re: Building sunpkcs11.jar
There is no such flag; otherwise it'd be an easy way to circumvent existing checks for enforcing export/import control. Cryptographic vendors who develop JCE providers can apply for JCE code signing certificates through a process documented in the JCE guide. The easiest route may be just to test against your OpenJDK build since the JCE framework in the OpenJDK can accept unsigned providers. Valerie On 05/25/12 15:13, Deneau, Tom wrote: Valerie -- I don't believe we have a JCE code signing keypair (where would we have gotten one?) Is there any test flag that tells the Oracle 7u4 jre to not require a signed crypto provider -- Tom -Original Message- From: Valerie (Yu-Ching) Peng [mailto:valerie.p...@oracle.com] Sent: Friday, May 25, 2012 12:11 PM To: Deneau, Tom Cc: build-dev@openjdk.java.net Subject: Re: Building sunpkcs11.jar The provider built from OpenJDK workspace is unsigned. It can't be used with Oracle 7u4 JRE which require crypto provider to be signed for export/import conformance. If Your company has a JCE code signing keypair, you can sign the provider built using OpenJDK with that keypair and then use it w/ Oracle 7u4 JRE. Thanks, Valerie On 05/23/12 08:54, Deneau, Tom wrote: I want to be able to modify and rebuild lib/ext/sunpkcs11.jar. When I do a make all; make images everything completes successfully. With javap, I can see my modified class in the build/linux-amd64/j2sdk-image/jre/lib/ext When I use this built ext directory as a replacement of the Oracle 7U4 JRE, and run some code that does KeyGenerator gen = KeyGenerator.getInstance(AES); I get Test1,java.security.NoSuchAlgorithmException: AES KeyGenerator not available at javax.crypto.KeyGenerator.init(KeyGenerator.java:158) at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:207) This code runs successfully with the regular Oracle 7U4 JRE. Am I missing something in the build process? -- Tom Deneau
