From anthony.scarpino at oracle.com Wed Feb 1 00:40:45 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 31 Jan 2017 16:40:45 -0800 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: <6197daea-7b3b-5167-d8d3-b747f42c6054@oracle.com> References: <7f3ecacd-bc30-3b59-0fc5-2409042c1bd9@oracle.com> <588F2408.9080204@oracle.com> <76389b6d-b369-59d8-e604-b9f3bde8ed20@oracle.com> <6197daea-7b3b-5167-d8d3-b747f42c6054@oracle.com> Message-ID: <7b461e30-0222-76a7-f372-01d16e81e542@oracle.com> I see what you are saying.. It's a simple change that I can make on the on my workspace.. I won't rev the webrev, but here is the change. 377 debug.println(key + ": " + e.getMessage()); Tony On 01/31/2017 09:28 AM, Se?n Coffey wrote: > Hi Tony, > > Thanks for the update. I see your new webrev. I guess my point is that > if we're in verbose logging mode, then we should log the message from > the exception(.getMessage()) rather than the more (vague) "uses a > disabled algorithm" logged message. > > I see the new code now iterating over the permittedAlgs Map - that will > certainly benefit logging. > > regards, > Sean. > > On 30/01/2017 18:21, Anthony Scarpino wrote: >> Hi Sean, >> >> Actually Sean M and I were talking about that offline on thursday. >> That file is changing a lot. >> >> The three sections you mention have changed a lot, but the general >> idea is the disabled algorithms are captured and reported after all >> the checks were done. This is because the we can have multiple >> signatures and one of them maybe allowed. Throwing an exception on >> the first failure would not pick up a possible second signature that >> was allowed. >> >> thanks >> >> Tony >> >> On 01/30/2017 03:31 AM, Se?n Coffey wrote: >>> src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java >>> >>> CertPathValidatorException is caught 3 times in new code but we're not >>> printing out the exact algorithm that caused the exception. AFAIK, that >>> should be in the exception message. Would it be possible to use >>> something e.getMessage() call to print more detail ? You'd have to check >>> for null also. >>> >>> 371 } catch(CertPathValidatorException e) { >>> 372 if (debug != null) { >>> 373 debug.println(key + " uses a disabled >>> algorithm."); >>> 374 } >>> >>> Spacing issue on line 371 of same file : >>> >>>> 371 } catch(CertPathValidatorException e) { >>> >>> Regards, >>> Sean. >>> >>> On 26/01/17 21:57, Sean Mullan wrote: >>>> Looks good, mostly minor stuff so far, just have one other file I need >>>> more time to review: >>>> >>>> * java.security >>>> >>>> Update description of new constraints to match CCC. >>>> >>>> * PKIXExtendedParameters.java >>>> >>>> Update class description (it is out-of-date). >>>> >>>> * CertConstraintParameters.java >>>> >>>> 2 * Copyright (c) 2016, 2017 Oracle and/or its affiliates. All rights >>>> reserved. >>>> >>>> Should be a comma after 2017. >>>> >>>> * AlgorithmChecker.java >>>> >>>> 278 String currSigAlg = >>>> ((X509Certificate)cert).getSigAlgName(); >>>> >>>> Just use x509Cert.getSigAlgName() instead >>>> >>>> * SignatureFileVerifier.java >>>> >>>> 294 Timestamp[] timestamp = new Timestamp[newSigners.length]; >>>> >>>> "timestamps" would be more clear as a variable name >>>> >>>> 299 System.out.println("Timestamp[" + (i - 1) + "] = >>>> " + >>>> >>>> debug.println >>>> >>>> --Sean >>>> >>>> On 1/23/17 6:27 PM, Anthony Scarpino wrote: >>>>> Hi, >>>>> >>>>> I need a code review of this change that brings more detail >>>>> constraints >>>>> checking and control to certpath and jar disabled algorithm Security >>>>> properties. >>>>> >>>>> http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ >>>>> >>>>> thanks >>>>> >>>>> Tony >>> >> > From valerie.peng at oracle.com Wed Feb 1 01:51:31 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 31 Jan 2017 17:51:31 -0800 Subject: RFR [9] 8173708: Re-enable AES cipher with CFB128 mode for Ucrypto provider Message-ID: <4d35f999-951d-13f2-9b96-468e88a0209e@oracle.com> Hi Brad, Would you have time to review this trivial Ucrypto config file update? It's related to the Solaris fix that you relayed to me. Given that some of our test machines may still run pre-S11.3 releases and that JDK 9 is already at Rampdown 1 phase, I updated the test to ignore the exception for CFB128 mode to minimize the possible impact of re-enabling these Ucrypto algorithms. Webrev: http://cr.openjdk.java.net/~valeriep/8173708/webrev.00/ Thanks, Valerie From sergei.kovalev at oracle.com Wed Feb 1 15:24:44 2017 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 1 Feb 2017 18:24:44 +0300 Subject: RFR(S): 8173763: Two security tests fail with message: "java.security.NoSuchAlgorithmException: EC KeyFactory not available" Message-ID: Hi team, Please review a small fix for tests. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8173763 WebReview: http://cr.openjdk.java.net/~skovalev/8173763/webrev.00/ Issue: Two tests failing during execution with module limitation by "--limit-modules" command line option. Solution: declare dependency on jdk.crypto.ec module. The issue is similar to https://bugs.openjdk.java.net/browse/JDK-8173478. -- With best regards, Sergei -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Wed Feb 1 11:07:21 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 12:07:21 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> Message-ID: <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: http://cr.openjdk.java.net/~dnsimon/8145337/ -Doug > On 30 Jan 2017, at 22:53, Mandy Chung wrote: > >> >> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >> >> >>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>> >>> >>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>> >>>> I?ve extended the webrev with that change - please re-review: >>>> >>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>> >>> >>> +1 >> >> Thanks. Is that a ?Reviewed?? >> > > Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. > > Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. > >> I think I should get at least one sign-off from the security team. >> > > Hope Sean will review this one. Please send an updated webrev. > >> Also, since this is effectively making jdk.vm.compiler an upgradeable module, > > No it does not. > >> what?s the implication for it being a hash-checked module? > > When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module > >> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. > > JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. > > Mandy > >> >> -Doug >> >>> >>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>> >>> >>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>> >>>> BTW, I never answered your question: >>>> >>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>> >>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>> >>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>> >>> Mandy From sean.mullan at oracle.com Wed Feb 1 19:36:53 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 1 Feb 2017 14:36:53 -0500 Subject: RFR(S): 8173763: Two security tests fail with message: "java.security.NoSuchAlgorithmException: EC KeyFactory not available" In-Reply-To: References: Message-ID: <16da372c-aa7b-ba2f-ac2d-03783745d5c8@oracle.com> Looks fine to me. --Sean On 2/1/17 10:24 AM, Sergei Kovalev wrote: > Hi team, > > Please review a small fix for tests. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8173763 > WebReview: http://cr.openjdk.java.net/~skovalev/8173763/webrev.00/ > > Issue: Two tests failing during execution with module limitation by > "--limit-modules" command line option. > Solution: declare dependency on jdk.crypto.ec module. > > The issue is similar to https://bugs.openjdk.java.net/browse/JDK-8173478. > -- > With best regards, > Sergei From sean.mullan at oracle.com Wed Feb 1 19:54:43 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 1 Feb 2017 14:54:43 -0500 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> Message-ID: Couple of comments: - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. --Sean On 2/1/17 6:07 AM, Doug Simon wrote: > I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: > > http://cr.openjdk.java.net/~dnsimon/8145337/ > > -Doug > >> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >> >>> >>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>> >>> >>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>> >>>> >>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>> >>>>> I?ve extended the webrev with that change - please re-review: >>>>> >>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>> >>>> >>>> +1 >>> >>> Thanks. Is that a ?Reviewed?? >>> >> >> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >> >> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >> >>> I think I should get at least one sign-off from the security team. >>> >> >> Hope Sean will review this one. Please send an updated webrev. >> >>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >> >> No it does not. >> >>> what?s the implication for it being a hash-checked module? >> >> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >> >>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >> >> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >> >> Mandy >> >>> >>> -Doug >>> >>>> >>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>> >>>> >>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>> >>>>> BTW, I never answered your question: >>>>> >>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>> >>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>> >>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>> >>>> Mandy > From vladimir.kozlov at oracle.com Wed Feb 1 21:19:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Feb 2017 13:19:50 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> Message-ID: <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> AOT tool jaotc does not run with SecurityManager. We assume it runs in secure environment and it does not access any external resources. Thanks Vladimir > On Feb 1, 2017, at 12:03 PM, Doug Simon wrote: > > >> On 1 Feb 2017, at 20:54, Sean Mullan wrote: >> >> Couple of comments: >> >> - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. > > Thanks - I removed it. > >> - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. > > Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file? > > -Doug > >>> On 2/1/17 6:07 AM, Doug Simon wrote: >>> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >>> >>> http://cr.openjdk.java.net/~dnsimon/8145337/ >>> >>> -Doug >>> >>>>> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >>>>> >>>>> >>>>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>>>> >>>>> >>>>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>>>> >>>>>> >>>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>>>> >>>>>>> I?ve extended the webrev with that change - please re-review: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>>>> >>>>>> >>>>>> +1 >>>>> >>>>> Thanks. Is that a ?Reviewed?? >>>>> >>>> >>>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >>>> >>>> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >>>> >>>>> I think I should get at least one sign-off from the security team. >>>>> >>>> >>>> Hope Sean will review this one. Please send an updated webrev. >>>> >>>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >>>> >>>> No it does not. >>>> >>>>> what?s the implication for it being a hash-checked module? >>>> >>>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >>>> >>>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >>>> >>>> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >>>> >>>> Mandy >>>> >>>>> >>>>> -Doug >>>>> >>>>>> >>>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>>>> >>>>>> >>>>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>>>> >>>>>>> BTW, I never answered your question: >>>>>>> >>>>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>>>> >>>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>>>> >>>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>>>> >>>>>> Mandy >>> > From sean.mullan at oracle.com Wed Feb 1 22:17:07 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 1 Feb 2017 17:17:07 -0500 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> Message-ID: <317ffefa-5535-0a0c-0ad7-7e61260b26d0@oracle.com> On 2/1/17 4:27 PM, Doug Simon wrote: > Can I now consider this change reviewed and integrate it? Yes. --Sean From mandy.chung at oracle.com Thu Feb 2 02:12:26 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Feb 2017 18:12:26 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89! A429E0AE00@oracle.com> Message-ID: <970E0BAE-2DFA-4B30-8B4B-A730391308D5@oracle.com> > On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: > > I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: > > http://cr.openjdk.java.net/~dnsimon/8145337/ Looks good. Mandy From Alan.Bateman at oracle.com Thu Feb 2 08:09:11 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Feb 2017 08:09:11 +0000 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <970E0BAE-2DFA-4B30-8B4B-A730391308D5@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89! A429E0AE00@oracle.com> <970E0BAE-2DFA-4B30-8B4B-A730391308D5@oracle.com> Message-ID: <913dc879-1b70-8530-7992-f06bc8674237@oracle.com> On 02/02/2017 02:12, Mandy Chung wrote: >> On Feb 1, 2017, at 3:07 AM, Doug Simon wrote: >> >> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >> >> http://cr.openjdk.java.net/~dnsimon/8145337/ > Looks good. > Looks okay to me too. -Alan. From sean.mullan at oracle.com Thu Feb 2 18:35:03 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 2 Feb 2017 13:35:03 -0500 Subject: RFR: 8173827: Remove forRemoval=true from several deprecated security APIs Message-ID: Please review this change to undo, or remove the forRemoval=true element from the Deprecated annotation of a number of security APIs. Since marking these APIs for removal in a future version of SE, it has since been reported that some external applications/code are still using these APIs, and there is concern that there may not be enough advance notice to adapt their code to transition away from these legacy APIs and/or replace them with newer APIs before they would be removed. bug: https://bugs.openjdk.java.net/browse/JDK-8173827 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8173827/webrev.00/ Thanks, Sean From claes.redestad at oracle.com Thu Feb 2 21:22:36 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 02 Feb 2017 22:22:36 +0100 Subject: RFR: 8173827: Remove forRemoval=true from several deprecated security APIs In-Reply-To: References: Message-ID: <0496AFC7-6F65-45E8-8B09-AAA2B0FF077E@oracle.com> -1 AFAIU, forRemoval=true is not saying anything about *when* each deprecated method/class will be removed (although there might be an expectation that it should be in the next major release if possible, i.e., 10); if there's concern like here that some known application or library won't be ready for it then I dont see why we shouldnt simply defer the actual removal to some later release rather than drop the intent to remove like this. /Claes Sean Mullan skrev: (2 februari 2017 19:35:03 CET) >Please review this change to undo, or remove the forRemoval=true >element >from the Deprecated annotation of a number of security APIs. Since >marking these APIs for removal in a future version of SE, it has since >been reported that some external applications/code are still using >these >APIs, and there is concern that there may not be enough advance notice >to adapt their code to transition away from these legacy APIs and/or >replace them with newer APIs before they would be removed. > >bug: https://bugs.openjdk.java.net/browse/JDK-8173827 >webrev: http://cr.openjdk.java.net/~mullan/webrevs/8173827/webrev.00/ > >Thanks, >Sean -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Fri Feb 3 00:08:54 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 2 Feb 2017 16:08:54 -0800 Subject: RFR: 8173827: Remove forRemoval=true from several deprecated security APIs In-Reply-To: <0496AFC7-6F65-45E8-8B09-AAA2B0FF077E@oracle.com> References: <0496AFC7-6F65-45E8-8B09-AAA2B0FF077E@oracle.com> Message-ID: <19cde0c9-1894-9290-d2e0-99649e469229@oracle.com> Hi Claes, The text of JEP 277 [1] has the following: > Given the history of deprecation in Java SE, and the emphasis on long term API > compatibility across versions, removal of an API is a matter of serious > concern. Therefore, deprecation with the element |forRemoval=true| should be > applied only when there is a clear and definite plan for removing that API in > the next release of the Java SE platform. It sounds like Sean has identified enough dependencies on these APIs that they shouldn't be removed in JDK 10, so not marking them forRemoval=true in JDK 9 makes sense. s'marks [1] http://openjdk.java.net/jeps/277 On 2/2/17 1:22 PM, Claes Redestad wrote: > -1 > > AFAIU, forRemoval=true is not saying anything about *when* each deprecated > method/class will be removed (although there might be an expectation that it > should be in the next major release if possible, i.e., 10); if there's concern > like here that some known application or library won't be ready for it then I > dont see why we shouldnt simply defer the actual removal to some later release > rather than drop the intent to remove like this. > > /Claes > > > > Sean Mullan skrev: (2 februari 2017 19:35:03 CET) > > Please review this change to undo, or remove the forRemoval=true element > from the Deprecated annotation of a number of security APIs. Since > marking these APIs for removal in a future version of SE, it has since > been reported that some external applications/code are still using these > APIs, and there is concern that there may not be enough advance notice > to adapt their code to transition away from these legacy APIs and/or > replace them with newer APIs before they would be removed. > > bug:https://bugs.openjdk.java.net/browse/JDK-8173827 > webrev:http://cr.openjdk.java.net/~mullan/webrevs/8173827/webrev.00 > / > > Thanks, > Sean > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Feb 3 14:02:16 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 3 Feb 2017 09:02:16 -0500 Subject: RFR: 8173827: Remove forRemoval=true from several deprecated security APIs In-Reply-To: <19cde0c9-1894-9290-d2e0-99649e469229@oracle.com> References: <0496AFC7-6F65-45E8-8B09-AAA2B0FF077E@oracle.com> <19cde0c9-1894-9290-d2e0-99649e469229@oracle.com> Message-ID: On 2/2/17 7:08 PM, Stuart Marks wrote: > Hi Claes, > > The text of JEP 277 [1] has the following: >> Given the history of deprecation in Java SE, and the emphasis on long >> term API compatibility across versions, removal of an API is a matter >> of serious concern. Therefore, deprecation with the element >> |forRemoval=true| should be applied only when there is a clear and >> definite plan for removing that API in the next release of the Java SE >> platform. > It sounds like Sean has identified enough dependencies on these APIs > that they shouldn't be removed in JDK 10, so not marking them > forRemoval=true in JDK 9 makes sense. Correct. There are several Java EE projects that still have dependencies on these APIs, and one of the dependencies is in a standard EE API which would require a specification change: https://java.net/jira/browse/EJB_SPEC-130. We still believe that these APIs should eventually be removed from SE, but we need to make sure these projects and the EE community is prepared for it. Thanks, Sean > s'marks > > > [1] http://openjdk.java.net/jeps/277 > > > > On 2/2/17 1:22 PM, Claes Redestad wrote: >> -1 >> >> AFAIU, forRemoval=true is not saying anything about *when* each >> deprecated method/class will be removed (although there might be an >> expectation that it should be in the next major release if possible, >> i.e., 10); if there's concern like here that some known application or >> library won't be ready for it then I dont see why we shouldnt simply >> defer the actual removal to some later release rather than drop the >> intent to remove like this. >> >> /Claes >> >> >> >> Sean Mullan skrev: (2 februari 2017 19:35:03 >> CET) >> >> Please review this change to undo, or remove the forRemoval=true element >> from the Deprecated annotation of a number of security APIs. Since >> marking these APIs for removal in a future version of SE, it has since >> been reported that some external applications/code are still using these >> APIs, and there is concern that there may not be enough advance notice >> to adapt their code to transition away from these legacy APIs and/or >> replace them with newer APIs before they would be removed. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8173827 >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8173827/webrev.00 >> / >> >> Thanks, >> Sean >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > From claes.redestad at oracle.com Fri Feb 3 15:19:38 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 3 Feb 2017 16:19:38 +0100 Subject: RFR: 8173827: Remove forRemoval=true from several deprecated security APIs In-Reply-To: References: <0496AFC7-6F65-45E8-8B09-AAA2B0FF077E@oracle.com> <19cde0c9-1894-9290-d2e0-99649e469229@oracle.com> Message-ID: <2fba8ce5-294f-01ea-2b4e-e740ec881e03@oracle.com> On 02/03/2017 03:02 PM, Sean Mullan wrote: > On 2/2/17 7:08 PM, Stuart Marks wrote: >> Hi Claes, >> >> The text of JEP 277 [1] has the following: >>> Given the history of deprecation in Java SE, and the emphasis on long >>> term API compatibility across versions, removal of an API is a matter >>> of serious concern. Therefore, deprecation with the element >>> |forRemoval=true| should be applied only when there is a clear and >>> definite plan for removing that API in the next release of the Java SE >>> platform. >> It sounds like Sean has identified enough dependencies on these APIs >> that they shouldn't be removed in JDK 10, so not marking them >> forRemoval=true in JDK 9 makes sense. > > Correct. There are several Java EE projects that still have > dependencies on these APIs, and one of the dependencies is in a > standard EE API which would require a specification change: > https://java.net/jira/browse/EJB_SPEC-130. > > We still believe that these APIs should eventually be removed from SE, > but we need to make sure these projects and the EE community is > prepared for it. Thanks Stuart and Sean for providing more context and motivation here, I've apparently been misled on how to interpret forRemoval. You may count this as an apology and a review. :-) Thanks! /Claes > > Thanks, > Sean > >> s'marks >> >> >> [1] http://openjdk.java.net/jeps/277 >> >> >> >> On 2/2/17 1:22 PM, Claes Redestad wrote: >>> -1 >>> >>> AFAIU, forRemoval=true is not saying anything about *when* each >>> deprecated method/class will be removed (although there might be an >>> expectation that it should be in the next major release if possible, >>> i.e., 10); if there's concern like here that some known application or >>> library won't be ready for it then I dont see why we shouldnt simply >>> defer the actual removal to some later release rather than drop the >>> intent to remove like this. >>> >>> /Claes >>> >>> >>> >>> Sean Mullan skrev: (2 februari 2017 19:35:03 >>> CET) >>> >>> Please review this change to undo, or remove the forRemoval=true >>> element >>> from the Deprecated annotation of a number of security APIs. Since >>> marking these APIs for removal in a future version of SE, it has >>> since >>> been reported that some external applications/code are still >>> using these >>> APIs, and there is concern that there may not be enough advance >>> notice >>> to adapt their code to transition away from these legacy APIs >>> and/or >>> replace them with newer APIs before they would be removed. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8173827 >>> webrev: >>> http://cr.openjdk.java.net/~mullan/webrevs/8173827/webrev.00 >>> / >>> >>> Thanks, >>> Sean >>> >>> >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> From joe.darcy at oracle.com Fri Feb 3 19:21:16 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 3 Feb 2017 11:21:16 -0800 Subject: JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK 10 Message-ID: Hello, After the version update to "10" in JDK 10 ( JDK-8029942 ), various libraries tests failed including: java/lang/module/MultiReleaseJarTest.java java/security/Provider/ProviderVersionCheck.java sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java These tests need to be updated for the new JDK. When it is clear how to do so, I've updated the tests in a way so that they don't need to be updated again for JDK 11. Webrev: http://cr.openjdk.java.net/~darcy/8173903.0/ and patch below. I'll update the other copyrights before pushing. Thanks, -Joe diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java --- a/test/java/lang/module/MultiReleaseJarTest.java Tue Jan 31 19:26:10 2017 -0500 +++ b/test/java/lang/module/MultiReleaseJarTest.java Fri Feb 03 11:18:23 2017 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -65,7 +65,7 @@ private static final String MODULE_INFO = "module-info.class"; - private static final int RELEASE = Runtime.version().major(); + private static final String RELEASE = "" + Runtime.version().major(); // are multi-release JARs enabled? private static final boolean MULTI_RELEASE; @@ -88,8 +88,8 @@ .moduleInfo("module-info.class", descriptor) .resource("p/Main.class") .resource("p/Helper.class") - .resource("META-INF/versions/9/p/Helper.class") - .resource("META-INF/versions/9/p/internal/Helper9.class") + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") .build(); // find the module @@ -131,9 +131,9 @@ .moduleInfo(MODULE_INFO, descriptor1) .resource("p/Main.class") .resource("p/Helper.class") - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2) - .resource("META-INF/versions/9/p/Helper.class") - .resource("META-INF/versions/9/p/internal/Helper9.class") + .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2) + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") .build(); // find the module @@ -161,8 +161,8 @@ Path jar = new JarBuilder(name) .resource("p/Main.class") .resource("p/Helper.class") - .resource("META-INF/versions/9/p/Helper.class") - .resource("META-INF/versions/9/p/internal/Helper9.class") + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") .build(); // find the module @@ -200,7 +200,7 @@ Path jar = new JarBuilder(name) .moduleInfo(MODULE_INFO, descriptor1) - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2) + .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2) .build(); // find the module diff -r 72f33dbfcf3b test/java/security/Provider/ProviderVersionCheck.java --- a/test/java/security/Provider/ProviderVersionCheck.java Tue Jan 31 19:26:10 2017 -0500 +++ b/test/java/security/Provider/ProviderVersionCheck.java Fri Feb 03 11:18:23 2017 -0800 @@ -42,7 +42,7 @@ for (Provider p: Security.getProviders()) { System.out.print(p.getName() + " "); - if (p.getVersion() != 9.0d) { + if (p.getVersion() != 10.0d) { System.out.println("failed. " + "Version received was " + p.getVersion()); failure = true; diff -r 72f33dbfcf3b test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java --- a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Tue Jan 31 19:26:10 2017 -0500 +++ b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Fri Feb 03 11:18:23 2017 -0800 @@ -74,7 +74,8 @@ private static final String KEYPASS = "changeit"; private static final String SIGNED_JAR = "Signed.jar"; private static final String POLICY_FILE = "SignedJar.policy"; - private static final String VERSION_MESSAGE = "I am running on version 9"; + private static final String VERSION = "" + Runtime.version().major(); + private static final String VERSION_MESSAGE = "I am running on version " + VERSION; public static void main(String[] args) throws Throwable { // compile java files in jarContent directory From lance.andersen at oracle.com Fri Feb 3 19:23:54 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 3 Feb 2017 14:23:54 -0500 Subject: JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK 10 In-Reply-To: References: Message-ID: Look good Joe > On Feb 3, 2017, at 2:21 PM, joe darcy wrote: > > Hello, > > After the version update to "10" in JDK 10 ( JDK-8029942 ), various libraries tests failed including: > > java/lang/module/MultiReleaseJarTest.java > java/security/Provider/ProviderVersionCheck.java > sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > > These tests need to be updated for the new JDK. When it is clear how to do so, I've updated the tests in a way so that they don't need to be updated again for JDK 11. > > Webrev: > > http://cr.openjdk.java.net/~darcy/8173903.0/ > > and patch below. I'll update the other copyrights before pushing. > > Thanks, > > -Joe > > > diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java > --- a/test/java/lang/module/MultiReleaseJarTest.java Tue Jan 31 19:26:10 2017 -0500 > +++ b/test/java/lang/module/MultiReleaseJarTest.java Fri Feb 03 11:18:23 2017 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -65,7 +65,7 @@ > > private static final String MODULE_INFO = "module-info.class"; > > - private static final int RELEASE = Runtime.version().major(); > + private static final String RELEASE = "" + Runtime.version().major(); > > // are multi-release JARs enabled? > private static final boolean MULTI_RELEASE; > @@ -88,8 +88,8 @@ > .moduleInfo("module-info.class", descriptor) > .resource("p/Main.class") > .resource("p/Helper.class") > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -131,9 +131,9 @@ > .moduleInfo(MODULE_INFO, descriptor1) > .resource("p/Main.class") > .resource("p/Helper.class") > - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2) > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2) > + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -161,8 +161,8 @@ > Path jar = new JarBuilder(name) > .resource("p/Main.class") > .resource("p/Helper.class") > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -200,7 +200,7 @@ > > Path jar = new JarBuilder(name) > .moduleInfo(MODULE_INFO, descriptor1) > - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2) > + .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2) > .build(); > > // find the module > diff -r 72f33dbfcf3b test/java/security/Provider/ProviderVersionCheck.java > --- a/test/java/security/Provider/ProviderVersionCheck.java Tue Jan 31 19:26:10 2017 -0500 > +++ b/test/java/security/Provider/ProviderVersionCheck.java Fri Feb 03 11:18:23 2017 -0800 > @@ -42,7 +42,7 @@ > > for (Provider p: Security.getProviders()) { > System.out.print(p.getName() + " "); > - if (p.getVersion() != 9.0d) { > + if (p.getVersion() != 10.0d) { > System.out.println("failed. " + "Version received was " + > p.getVersion()); > failure = true; > diff -r 72f33dbfcf3b test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > --- a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Tue Jan 31 19:26:10 2017 -0500 > +++ b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Fri Feb 03 11:18:23 2017 -0800 > @@ -74,7 +74,8 @@ > private static final String KEYPASS = "changeit"; > private static final String SIGNED_JAR = "Signed.jar"; > private static final String POLICY_FILE = "SignedJar.policy"; > - private static final String VERSION_MESSAGE = "I am running on version 9"; > + private static final String VERSION = "" + Runtime.version().major(); > + private static final String VERSION_MESSAGE = "I am running on version " + VERSION; > > public static void main(String[] args) throws Throwable { > // compile java files in jarContent directory > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From paul.sandoz at oracle.com Fri Feb 3 20:28:50 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 3 Feb 2017 12:28:50 -0800 Subject: JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK 10 In-Reply-To: References: Message-ID: <75DD5C54-C507-4A77-89BE-901A4B2DE6EC@oracle.com> +1 Paul. > On 3 Feb 2017, at 11:21, joe darcy wrote: > > Hello, > > After the version update to "10" in JDK 10 ( JDK-8029942 ), various libraries tests failed including: > > java/lang/module/MultiReleaseJarTest.java > java/security/Provider/ProviderVersionCheck.java > sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > > These tests need to be updated for the new JDK. When it is clear how to do so, I've updated the tests in a way so that they don't need to be updated again for JDK 11. > > Webrev: > > http://cr.openjdk.java.net/~darcy/8173903.0/ > > and patch below. I'll update the other copyrights before pushing. > > Thanks, > > -Joe > > > diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java > --- a/test/java/lang/module/MultiReleaseJarTest.java Tue Jan 31 19:26:10 2017 -0500 > +++ b/test/java/lang/module/MultiReleaseJarTest.java Fri Feb 03 11:18:23 2017 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -65,7 +65,7 @@ > > private static final String MODULE_INFO = "module-info.class"; > > - private static final int RELEASE = Runtime.version().major(); > + private static final String RELEASE = "" + Runtime.version().major(); > > // are multi-release JARs enabled? > private static final boolean MULTI_RELEASE; > @@ -88,8 +88,8 @@ > .moduleInfo("module-info.class", descriptor) > .resource("p/Main.class") > .resource("p/Helper.class") > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -131,9 +131,9 @@ > .moduleInfo(MODULE_INFO, descriptor1) > .resource("p/Main.class") > .resource("p/Helper.class") > - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2) > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2) > + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -161,8 +161,8 @@ > Path jar = new JarBuilder(name) > .resource("p/Main.class") > .resource("p/Helper.class") > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -200,7 +200,7 @@ > > Path jar = new JarBuilder(name) > .moduleInfo(MODULE_INFO, descriptor1) > - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2) > + .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2) > .build(); > > // find the module > diff -r 72f33dbfcf3b test/java/security/Provider/ProviderVersionCheck.java > --- a/test/java/security/Provider/ProviderVersionCheck.java Tue Jan 31 19:26:10 2017 -0500 > +++ b/test/java/security/Provider/ProviderVersionCheck.java Fri Feb 03 11:18:23 2017 -0800 > @@ -42,7 +42,7 @@ > > for (Provider p: Security.getProviders()) { > System.out.print(p.getName() + " "); > - if (p.getVersion() != 9.0d) { > + if (p.getVersion() != 10.0d) { > System.out.println("failed. " + "Version received was " + > p.getVersion()); > failure = true; > diff -r 72f33dbfcf3b test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > --- a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Tue Jan 31 19:26:10 2017 -0500 > +++ b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Fri Feb 03 11:18:23 2017 -0800 > @@ -74,7 +74,8 @@ > private static final String KEYPASS = "changeit"; > private static final String SIGNED_JAR = "Signed.jar"; > private static final String POLICY_FILE = "SignedJar.policy"; > - private static final String VERSION_MESSAGE = "I am running on version 9"; > + private static final String VERSION = "" + Runtime.version().major(); > + private static final String VERSION_MESSAGE = "I am running on version " + VERSION; > > public static void main(String[] args) throws Throwable { > // compile java files in jarContent directory > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From valerie.peng at oracle.com Fri Feb 3 22:30:31 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 3 Feb 2017 14:30:31 -0800 Subject: JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK 10 In-Reply-To: References: Message-ID: It seems that ProviderVersionCheck.java is the only one that still has the hardcoded 10?* * The other two are changed to useRuntime.version().major() call. Is this difference intentional? Thanks, Valerie On 2/3/2017 11:21 AM, joe darcy wrote: > Hello, > > After the version update to "10" in JDK 10 ( JDK-8029942 ), various > libraries tests failed including: > > java/lang/module/MultiReleaseJarTest.java > java/security/Provider/ProviderVersionCheck.java > sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > > These tests need to be updated for the new JDK. When it is clear how > to do so, I've updated the tests in a way so that they don't need to > be updated again for JDK 11. > > Webrev: > > http://cr.openjdk.java.net/~darcy/8173903.0/ > > and patch below. I'll update the other copyrights before pushing. > > Thanks, > > -Joe > > > diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java > --- a/test/java/lang/module/MultiReleaseJarTest.java Tue Jan 31 > 19:26:10 2017 -0500 > +++ b/test/java/lang/module/MultiReleaseJarTest.java Fri Feb 03 > 11:18:23 2017 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2016, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -65,7 +65,7 @@ > > private static final String MODULE_INFO = "module-info.class"; > > - private static final int RELEASE = Runtime.version().major(); > + private static final String RELEASE = "" + > Runtime.version().major(); > > // are multi-release JARs enabled? > private static final boolean MULTI_RELEASE; > @@ -88,8 +88,8 @@ > .moduleInfo("module-info.class", descriptor) > .resource("p/Main.class") > .resource("p/Helper.class") > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .resource("META-INF/versions/" + RELEASE + > "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + > "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -131,9 +131,9 @@ > .moduleInfo(MODULE_INFO, descriptor1) > .resource("p/Main.class") > .resource("p/Helper.class") > - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, > descriptor2) > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .moduleInfo("META-INF/versions/" + RELEASE + "/" + > MODULE_INFO, descriptor2) > + .resource("META-INF/versions/" + RELEASE + > "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + > "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -161,8 +161,8 @@ > Path jar = new JarBuilder(name) > .resource("p/Main.class") > .resource("p/Helper.class") > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .resource("META-INF/versions/" + RELEASE + > "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + > "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -200,7 +200,7 @@ > > Path jar = new JarBuilder(name) > .moduleInfo(MODULE_INFO, descriptor1) > - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, > descriptor2) > + .moduleInfo("META-INF/versions/" + RELEASE + "/" + > MODULE_INFO, descriptor2) > .build(); > > // find the module > diff -r 72f33dbfcf3b > test/java/security/Provider/ProviderVersionCheck.java > --- a/test/java/security/Provider/ProviderVersionCheck.java Tue Jan > 31 19:26:10 2017 -0500 > +++ b/test/java/security/Provider/ProviderVersionCheck.java Fri Feb > 03 11:18:23 2017 -0800 > @@ -42,7 +42,7 @@ > > for (Provider p: Security.getProviders()) { > System.out.print(p.getName() + " "); > - if (p.getVersion() != 9.0d) { > + if (p.getVersion() != 10.0d) { > System.out.println("failed. " + "Version received was > " + > p.getVersion()); > failure = true; > diff -r 72f33dbfcf3b > test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > --- > a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > Tue Jan 31 19:26:10 2017 -0500 > +++ > b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > Fri Feb 03 11:18:23 2017 -0800 > @@ -74,7 +74,8 @@ > private static final String KEYPASS = "changeit"; > private static final String SIGNED_JAR = "Signed.jar"; > private static final String POLICY_FILE = "SignedJar.policy"; > - private static final String VERSION_MESSAGE = "I am running on > version 9"; > + private static final String VERSION = "" + > Runtime.version().major(); > + private static final String VERSION_MESSAGE = "I am running on > version " + VERSION; > > public static void main(String[] args) throws Throwable { > // compile java files in jarContent directory > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Feb 6 03:00:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Feb 2017 13:00:20 +1000 Subject: JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK 10 In-Reply-To: References: Message-ID: <4092f26c-a928-d953-bf86-540817e9f8e2@oracle.com> Hi Joe, On 4/02/2017 5:21 AM, joe darcy wrote: > Hello, > > After the version update to "10" in JDK 10 ( JDK-8029942 ), various > libraries tests failed including: > > java/lang/module/MultiReleaseJarTest.java > java/security/Provider/ProviderVersionCheck.java Shouldn't the hardwired 10.0d (was 9.0d) be obtained from current runtime information? Cheers, David > sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > > These tests need to be updated for the new JDK. When it is clear how to > do so, I've updated the tests in a way so that they don't need to be > updated again for JDK 11. > > Webrev: > > http://cr.openjdk.java.net/~darcy/8173903.0/ > > and patch below. I'll update the other copyrights before pushing. > > Thanks, > > -Joe > > > diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java > --- a/test/java/lang/module/MultiReleaseJarTest.java Tue Jan 31 > 19:26:10 2017 -0500 > +++ b/test/java/lang/module/MultiReleaseJarTest.java Fri Feb 03 > 11:18:23 2017 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -65,7 +65,7 @@ > > private static final String MODULE_INFO = "module-info.class"; > > - private static final int RELEASE = Runtime.version().major(); > + private static final String RELEASE = "" + Runtime.version().major(); > > // are multi-release JARs enabled? > private static final boolean MULTI_RELEASE; > @@ -88,8 +88,8 @@ > .moduleInfo("module-info.class", descriptor) > .resource("p/Main.class") > .resource("p/Helper.class") > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .resource("META-INF/versions/" + RELEASE + > "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + > "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -131,9 +131,9 @@ > .moduleInfo(MODULE_INFO, descriptor1) > .resource("p/Main.class") > .resource("p/Helper.class") > - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, > descriptor2) > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .moduleInfo("META-INF/versions/" + RELEASE + "/" + > MODULE_INFO, descriptor2) > + .resource("META-INF/versions/" + RELEASE + > "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + > "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -161,8 +161,8 @@ > Path jar = new JarBuilder(name) > .resource("p/Main.class") > .resource("p/Helper.class") > - .resource("META-INF/versions/9/p/Helper.class") > - .resource("META-INF/versions/9/p/internal/Helper9.class") > + .resource("META-INF/versions/" + RELEASE + > "/p/Helper.class") > + .resource("META-INF/versions/" + RELEASE + > "/p/internal/HelperNew.class") > .build(); > > // find the module > @@ -200,7 +200,7 @@ > > Path jar = new JarBuilder(name) > .moduleInfo(MODULE_INFO, descriptor1) > - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, > descriptor2) > + .moduleInfo("META-INF/versions/" + RELEASE + "/" + > MODULE_INFO, descriptor2) > .build(); > > // find the module > diff -r 72f33dbfcf3b test/java/security/Provider/ProviderVersionCheck.java > --- a/test/java/security/Provider/ProviderVersionCheck.java Tue Jan > 31 19:26:10 2017 -0500 > +++ b/test/java/security/Provider/ProviderVersionCheck.java Fri Feb > 03 11:18:23 2017 -0800 > @@ -42,7 +42,7 @@ > > for (Provider p: Security.getProviders()) { > System.out.print(p.getName() + " "); > - if (p.getVersion() != 9.0d) { > + if (p.getVersion() != 10.0d) { > System.out.println("failed. " + "Version received was " + > p.getVersion()); > failure = true; > diff -r 72f33dbfcf3b > test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > --- > a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > Tue Jan 31 19:26:10 2017 -0500 > +++ > b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java > Fri Feb 03 11:18:23 2017 -0800 > @@ -74,7 +74,8 @@ > private static final String KEYPASS = "changeit"; > private static final String SIGNED_JAR = "Signed.jar"; > private static final String POLICY_FILE = "SignedJar.policy"; > - private static final String VERSION_MESSAGE = "I am running on > version 9"; > + private static final String VERSION = "" + Runtime.version().major(); > + private static final String VERSION_MESSAGE = "I am running on > version " + VERSION; > > public static void main(String[] args) throws Throwable { > // compile java files in jarContent directory > From vincent.x.ryan at oracle.com Mon Feb 6 16:29:04 2017 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 6 Feb 2017 16:29:04 +0000 Subject: [9] 8173956: KeyStore regression due to default keystore being changed to PKCS12 Message-ID: <8BFEE20B-787B-4318-A48E-16D2F5B7ABA3@oracle.com> Please review this fix to correct support for mixed-case aliases in PKCS12 keystores. Thanks. Webrev: http://cr.openjdk.java.net/~vinnie/8173956/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8173956 From xuelei.fan at oracle.com Mon Feb 6 17:09:06 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 6 Feb 2017 09:09:06 -0800 Subject: [9] 8173956: KeyStore regression due to default keystore being changed to PKCS12 In-Reply-To: <8BFEE20B-787B-4318-A48E-16D2F5B7ABA3@oracle.com> References: <8BFEE20B-787B-4318-A48E-16D2F5B7ABA3@oracle.com> Message-ID: <30655cfe-b7ed-6091-b56c-39242ac50b6b@oracle.com> Looks fine to me. Xuelei On 2/6/2017 8:29 AM, Vincent Ryan wrote: > Please review this fix to correct support for mixed-case aliases in PKCS12 keystores. > Thanks. > > Webrev: http://cr.openjdk.java.net/~vinnie/8173956/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8173956 > From anthony.scarpino at oracle.com Mon Feb 6 19:26:17 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 6 Feb 2017 11:26:17 -0800 Subject: RFR 8173410: Add commented config line for jdk.security.provider.preferred Message-ID: <5778acd2-42d7-7dc2-58fc-232ed71e6c82@oracle.com> Please review this change for Solaris SPARC configurations to add an optional configuration line. There are a few minor changes which didn't change any content. Changing some "#"'s for a bit more consistency and readability across the file. Also moving an RMI entry to the end that was merged right in the middle of the disabled algorithms section. http://cr.openjdk.java.net/~ascarpino/8173410/webrev/ thanks Tony From sean.mullan at oracle.com Mon Feb 6 20:17:50 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 6 Feb 2017 15:17:50 -0500 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: References: Message-ID: <40efbe09-569e-caf4-2d24-73a0916e5fa3@oracle.com> Hi Tony, Here are my comments on the latest webrev: * SignerInfo.java 355 try { 356 JAR_DISABLED_CHECK.permits(digestAlgname, cparams); 357 } catch (CertPathValidatorException e) { 358 throw new SignatureException(e.getMessage(), e); 359 } It's a little odd this throws a CPVE because there is no certificate being checked here. * AlgorithmChecker.java 278 String currSigAlg = ((X509Certificate)cert).getSigAlgName(); Just use x509cert.getSigAlgName() instead. * SignatureFileVerifier.java 145 System.err.println("key = " + name + " == name " + name); leftover debug? 265 // Algorithms that have been checked if they are weak. 266 private Map permittedAlgs= new HashMap<>(); 267 // TSA timestamp of signed jar. The newest timestamp is used. If there was 268 // no TSA timestamp used when signed, current time is used ("null"). 269 private Timestamp timestamp = null; can you move these lines up to the top of the class where other variables are declared? // Algorithms that have been checked if they are weak. 266 private Map permittedAlgs= new HashMap<>(); It might be better to have a Map> where the key is the header (*-DIGEST*) and the value is a list of weak algs. This way you could avoid the need for the getWeakAlgorithms method and just get the weak list of algs out of the map directly. An empty list or null value would indicate the header is ok. 302 /* Look for the latest timestamp in the signature block */ s/the latest timestamp/the latest timestamp or no timestamp/ * java.security Missing spaces between words on lines 646-648 (ex: algorithmin) * Main.java 640 void rey verifyJar(String jarName) typo? * PKIXExtendedParameters.java Update class description to reflect this contains more than a timestamp. --Sean On 1/30/17 6:57 PM, Anthony Scarpino wrote: > On 01/23/2017 03:27 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this change that brings more detail constraints >> checking and control to certpath and jar disabled algorithm Security >> properties. >> >> http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ >> >> thanks >> >> Tony > > Updated review > > http://cr.openjdk.java.net/~ascarpino/8160655/webrev.01/ > > It address the comments and has a different SignatureFileVerifier.java > > Tony > From sibabrata.sahoo at oracle.com Tue Feb 7 09:26:37 2017 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Tue, 7 Feb 2017 01:26:37 -0800 (PST) Subject: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: <9deec53c-b568-448d-9d29-be596a2a8814@default> Message-ID: <1b626955-9a81-41de-89cc-7df9dfc57ad7@default> Hi Sean, Please find the updated webrev at: http://cr.openjdk.java.net/~ssahoo/8168075/webrev.01/ It includes the following changes, 1) valid.policy, uses 'grant codebase "executable jar path"'. 2) In ClassLoaderTest.java, @bug renamed from 8168423 to 8168075. 3) In ClassLoaderTest.java, the code comments has been removed from @summary section. But it retains the same at line: 91-102. Thanks, Siba -----Original Message----- From: Sean Mullan Sent: Friday, January 27, 2017 12:07 AM To: Sibabrata Sahoo; Adam Petcher; security-dev at openjdk.java.net Subject: Re: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization Hi Siba, In valid.policy, use 'grant codeBase "file:${test.classes}/*"' so that only the tests are granted the needed permissions. In ClassLoaderTest.java, the @bug should be 8168075. Also, the @summary contains a bunch of lines (29-39) that should probably just be code comments. Seems fine otherwise. --Sean On 1/11/17 10:33 AM, Sibabrata Sahoo wrote: > Hi Adam/Sean, > > > > This patch is waiting for your review. > > > > Thanks, > > Siba > > > > *From:*Sibabrata Sahoo > *Sent:* Friday, December 02, 2016 6:56 PM > *To:* Sean Mullan; security-dev at openjdk.java.net > *Subject:* [9] RFR: 8168423: Test Task: Custom system class loader + > security manager + malformed policy file = recursive initialization > > > > Hi, > > > > Please review the patch for, > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8168423 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8168423/webrev.00/ > > > > Description: > > This webrev address all possible cases for Classloader with > SecurityManager having combination of valid/malformed policy file. > This Test is going to fail until JDK-8168075 get fixed. In the mean > time, it can be used to verify the fix for JDK-8168075. > > > > Here is the generic Logic behind generating all possible Test cases > with different combination of policy file, class loader and module types. > > for(policyFile : {"NO_POLICY", "VALID", "MALFORMED"}) { > > for(classLoader : {"SystemClassLoader", "CustomClassLoader"}){ > > // It uses possible set of regular/modular jars to generate all > possible Test cases in -cp and -module-path. > > for(clientModuletype : {"STRICT", "AUTO", "UNKNOWN"}) { > > for(classLoaderModuleType : {"STRICT", "AUTO", "UNKNOWN"}) > { > > Create and run java command line for each possible > Test cases and verify result. > > } > > } > > } > > } > > > > Thanks, > > Siba > > > From sean.coffey at oracle.com Tue Feb 7 15:25:40 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 7 Feb 2017 15:25:40 +0000 Subject: RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups Message-ID: The recent JDK-8148516 enhancement causes issue for JDKs without EC support. It's primarily an issue for JDK 6u which doesn't have SunEC but this still needs to be fixed in all release families. bug report : https://bugs.openjdk.java.net/browse/JDK-8173783 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8173783.jdk9/webrev/ regards, Sean. From xuelei.fan at oracle.com Tue Feb 7 17:20:25 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 Feb 2017 09:20:25 -0800 Subject: RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups In-Reply-To: References: Message-ID: <72b9e6a7-7f3a-caca-d456-13c2e4ec5748@oracle.com> Looks fine to me. Thanks, Xuelei On 2/7/2017 7:25 AM, Se?n Coffey wrote: > The recent JDK-8148516 enhancement causes issue for JDKs without EC > support. It's primarily an issue for JDK 6u which doesn't have SunEC but > this still needs to be fixed in all release families. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8173783 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8173783.jdk9/webrev/ > > regards, > Sean. > From ecki at zusammenkunft.net Tue Feb 7 18:58:23 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 7 Feb 2017 18:58:23 +0000 (UTC) Subject: RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups In-Reply-To: <72b9e6a7-7f3a-caca-d456-13c2e4ec5748@oracle.com> References: <72b9e6a7-7f3a-caca-d456-13c2e4ec5748@oracle.com> Message-ID: <2C80812C54F23E38.FCE89047-CD08-46DF-B32B-318C9A3E1B37@mail.outlook.com> Should it use Debug.println? Gruss Bernd -- http://bernd.eckenfels.net On Tue, Feb 7, 2017 at 7:51 PM +0100, "Xuelei Fan" wrote: Looks fine to me. Thanks, Xuelei On 2/7/2017 7:25 AM, Se?n Coffey wrote: > The recent JDK-8148516 enhancement causes issue for JDKs without EC > support. It's primarily an issue for JDK 6u which doesn't have SunEC but > this still needs to be fixed in all release families. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8173783 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8173783.jdk9/webrev/ > > regards, > Sean. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Tue Feb 7 19:15:14 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 7 Feb 2017 11:15:14 -0800 Subject: RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups In-Reply-To: References: Message-ID: Nit, I don't like the wording of 196-7. You have either jdk.tls.namedGroups or if not defined, you have the default values. In that case, this is going to print "Property defined: null" Maybe something along the lines of: "Initialized [jdk.tls.namedGroups|default] list contains " + "no available elliptic curves." + (property.exists() ? " " + property : "") where [jdk.tls.namedGroups|default] is the branch you took to arrive at the list value. Brad On 2/7/2017 7:25 AM, Se?n Coffey wrote: > The recent JDK-8148516 enhancement causes issue for JDKs without EC > support. It's primarily an issue for JDK 6u which doesn't have SunEC but > this still needs to be fixed in all release families. > > bug report : https://bugs.openjdk.java.net/browse/JDK-8173783 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8173783.jdk9/webrev/ > > regards, > Sean. > From bradford.wetmore at oracle.com Tue Feb 7 19:21:09 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 7 Feb 2017 11:21:09 -0800 Subject: RFR 8173410: Add commented config line for jdk.security.provider.preferred In-Reply-To: <5778acd2-42d7-7dc2-58fc-232ed71e6c82@oracle.com> References: <5778acd2-42d7-7dc2-58fc-232ed71e6c82@oracle.com> Message-ID: Thanks for making the comment formating consistent. Why did you move the RMI Registry Serial Filter? Offhand, this seems gratuitous, and will make ift more difficult for folks trying to maintain a single or slightly modified java.security across release families. Looks good otherwise. Brad On 2/6/2017 11:26 AM, Anthony Scarpino wrote: > Please review this change for Solaris SPARC configurations to add an > optional configuration line. > > There are a few minor changes which didn't change any content. Changing > some "#"'s for a bit more consistency and readability across the file. > Also moving an RMI entry to the end that was merged right in the middle > of the disabled algorithms section. > > http://cr.openjdk.java.net/~ascarpino/8173410/webrev/ > > thanks > > Tony > From adam.petcher at oracle.com Tue Feb 7 19:50:02 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 7 Feb 2017 14:50:02 -0500 Subject: RFR 8006259: Test example vectors from NIST SP 800-38A Message-ID: <4ae41476-b0a7-629a-5527-5897db412372@oracle.com> This change adds a test which executes example vectors from NIST SP 800-38A to check AES in various modes of operation. The test pulls in all of the providers and runs the appropriate vectors for all supported modes of operation on each provider. It passes on all platforms on JPRT, and I confirmed that it exercises OracleUcrypto and SunPKCS11 on Solaris. The CFB1 mode is included even though no provider seems to support it at this time. http://cr.openjdk.java.net/~apetcher/8006259/webrev.00/ From anthony.scarpino at oracle.com Tue Feb 7 20:07:16 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 7 Feb 2017 12:07:16 -0800 Subject: RFR 8173410: Add commented config line for jdk.security.provider.preferred In-Reply-To: References: <5778acd2-42d7-7dc2-58fc-232ed71e6c82@oracle.com> Message-ID: As I mentioned below, the RMI entry was merged from a closed repo into the middle of the disabled algorithms section. It was the merger's fault for not paying attention. I'm just trying to fix the problem.. Tony On 02/07/2017 11:21 AM, Bradford Wetmore wrote: > Thanks for making the comment formating consistent. > > Why did you move the RMI Registry Serial Filter? Offhand, this seems > gratuitous, and will make ift more difficult for folks trying to > maintain a single or slightly modified java.security across release > families. > > Looks good otherwise. > > Brad > > > > On 2/6/2017 11:26 AM, Anthony Scarpino wrote: >> Please review this change for Solaris SPARC configurations to add an >> optional configuration line. >> >> There are a few minor changes which didn't change any content. Changing >> some "#"'s for a bit more consistency and readability across the file. >> Also moving an RMI entry to the end that was merged right in the middle >> of the disabled algorithms section. >> >> http://cr.openjdk.java.net/~ascarpino/8173410/webrev/ >> >> thanks >> >> Tony >> From sean.coffey at oracle.com Tue Feb 7 20:59:01 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 7 Feb 2017 20:59:01 +0000 Subject: RFR : 8173783: IllegalArgumentException: jdk.tls.namedGroups In-Reply-To: References: Message-ID: <468d037c-0004-1163-efa5-b18dee8fbba1@oracle.com> Thanks for the comments Brad and Bernd. I've incorporated them into a new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8173783.jdk9.v2/webrev/ Brad - I've tweaked your suggestion further to indicate if the default values were used. > ! "Initialized [jdk.tls.namedGroups|default] list contains " + > ! "no available elliptic curves. " + > ! (property != null ? "(" + property + ")" : "[Default]")); Hope to push once build & test results are back. regards, Sean. On 07/02/2017 19:15, Bradford Wetmore wrote: > Nit, I don't like the wording of 196-7. You have either > jdk.tls.namedGroups or if not defined, you have the default values. > > In that case, this is going to print "Property defined: null" > > Maybe something along the lines of: > > "Initialized [jdk.tls.namedGroups|default] list contains " + > "no available elliptic curves." + > (property.exists() ? " " + property : "") > > where [jdk.tls.namedGroups|default] is the branch you took to arrive > at the list value. > > Brad > > > On 2/7/2017 7:25 AM, Se?n Coffey wrote: >> The recent JDK-8148516 enhancement causes issue for JDKs without EC >> support. It's primarily an issue for JDK 6u which doesn't have SunEC but >> this still needs to be fixed in all release families. >> >> bug report : https://bugs.openjdk.java.net/browse/JDK-8173783 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8173783.jdk9/webrev/ >> >> regards, >> Sean. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Wed Feb 1 20:03:50 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 21:03:50 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> Message-ID: <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> > On 1 Feb 2017, at 20:54, Sean Mullan wrote: > > Couple of comments: > > - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. Thanks - I removed it. > - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file? -Doug > On 2/1/17 6:07 AM, Doug Simon wrote: >> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >> >> http://cr.openjdk.java.net/~dnsimon/8145337/ >> >> -Doug >> >>> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >>> >>>> >>>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>>> >>>> >>>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>>> >>>>> >>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>>> >>>>>> I?ve extended the webrev with that change - please re-review: >>>>>> >>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>>> >>>>> >>>>> +1 >>>> >>>> Thanks. Is that a ?Reviewed?? >>>> >>> >>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >>> >>> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >>> >>>> I think I should get at least one sign-off from the security team. >>>> >>> >>> Hope Sean will review this one. Please send an updated webrev. >>> >>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >>> >>> No it does not. >>> >>>> what?s the implication for it being a hash-checked module? >>> >>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >>> >>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >>> >>> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >>> >>> Mandy >>> >>>> >>>> -Doug >>>> >>>>> >>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>>> >>>>> >>>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>>> >>>>>> BTW, I never answered your question: >>>>>> >>>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>>> >>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>>> >>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>>> >>>>> Mandy >> From doug.simon at oracle.com Wed Feb 1 21:27:47 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 1 Feb 2017 22:27:47 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> <44576DF7-9F0F-4AEA-BF9B-89A429E0AE00@oracle.com> <3BC2EC38-D0B3-49EC-8BD0-FD72138C9369@oracle.com> <0FEF3A7E-DD48-4427-A3F2-3DFB985CF83F@oracle.com> Message-ID: > On 1 Feb 2017, at 22:19, Vladimir Kozlov wrote: > > AOT tool jaotc does not run with SecurityManager. We assume it runs in secure environment and it does not access any external resources. Great. Can I now consider this change reviewed and integrate it? -Doug >> On Feb 1, 2017, at 12:03 PM, Doug Simon wrote: >> >> >>> On 1 Feb 2017, at 20:54, Sean Mullan wrote: >>> >>> Couple of comments: >>> >>> - jdk.vm.ci is already loaded by the boot loader so it is implicitly granted AllPermission and does not need an entry in default.policy. >> >> Thanks - I removed it. >> >>> - all internal APIs in the jdk.vm.compiler module will now be restricted by default by SecurityManager::checkPackageAccess(), so if you have any code or tests running with a SecurityManager that are accessing internal APIs in the jdk.vm.compiler module, you will need to grant them an appropriate "accessClassInPackage" RuntimePermission in addition to any --add-exports option you are using to break through encapsulation. >> >> Vladimir, does the AOT need to run with a SecurityManager and if so, I assume the qualified exports from jdk.vm.compiler to jdk.aot will allow it to run without needed an extra policy file? >> >> -Doug >> >>>> On 2/1/17 6:07 AM, Doug Simon wrote: >>>> I?ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable platform module, this allowing it to be mentioned in default.policy: >>>> >>>> http://cr.openjdk.java.net/~dnsimon/8145337/ >>>> >>>> -Doug >>>> >>>>>> On 30 Jan 2017, at 22:53, Mandy Chung wrote: >>>>>> >>>>>> >>>>>> On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: >>>>>> >>>>>> >>>>>>> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >>>>>>> >>>>>>> >>>>>>>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>>>>>>> >>>>>>>> I?ve extended the webrev with that change - please re-review: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>>>>>>> >>>>>>> >>>>>>> +1 >>>>>> >>>>>> Thanks. Is that a ?Reviewed?? >>>>>> >>>>> >>>>> Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. >>>>> >>>>> Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. >>>>> >>>>>> I think I should get at least one sign-off from the security team. >>>>>> >>>>> >>>>> Hope Sean will review this one. Please send an updated webrev. >>>>> >>>>>> Also, since this is effectively making jdk.vm.compiler an upgradeable module, >>>>> >>>>> No it does not. >>>>> >>>>>> what?s the implication for it being a hash-checked module? >>>>> >>>>> When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module >>>>> >>>>>> It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. >>>>> >>>>> JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. >>>>> >>>>> Mandy >>>>> >>>>>> >>>>>> -Doug >>>>>> >>>>>>> >>>>>>>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>>>>>>> >>>>>>> >>>>>>> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >>>>>>> >>>>>>>> BTW, I never answered your question: >>>>>>>> >>>>>>>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>>>>>>> >>>>>>>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >>>>>>> >>>>>>> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >>>>>>> >>>>>>> Mandy >>>> >> > From Michael.Gardiner at gemalto.com Tue Feb 7 21:29:40 2017 From: Michael.Gardiner at gemalto.com (Gardiner Michael) Date: Tue, 7 Feb 2017 21:29:40 +0000 Subject: TlsRsaPremasterSecretParameterSpec Message-ID: <3FA6BAADF79CCC418D052819A0E408C726105703@A1GTOEMBXV009.gto.a3c.atos.net> Hello Java Security Developers We had a discussion a year and a bit ago about the TlsRsaPremasterSecretParameterSpec being used in a way that doesn't seem to make sense. I've attached the email from 2015, but the same question has arisen. It seems that the JSSE is expecting RSA Ciphers to be able to handle TlsRsaPremasterSecretParameterSpec. Is the TlsRsaPremasterSecretParameterSpec class going to move out of the status of "@deprecated Sun JDK internal use only --- WILL BE REMOVED in a future release" towards something that will be expected of RSA cipher instances to interoperate with the JSSE? This is a blocking issue currently with at least one large customer. We could add some code in our provider to inspect if the parameter spec sent is of the offending type, but I'd really rather not have to handle a deprecated class that was never intended to be used outside of the Sun code base. My current advice to this customer is: 1. Roll back to a previous version of Java that's not affected by this behaviour change 2. Ensure the use of PFS cipher suites so the RSA key is used only for identity and not key exchange But both of those pieces of advice may not be practical in their situation. Regards, Mike Gardiner Systems Security Architect Gemalto -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: "Sean Mullan" Subject: Re: 8028192 Use of PKCS11-NSS provider in FIPS mode broken Date: Mon, 21 Sep 2015 14:15:34 -0500 Size: 4724 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6996 bytes Desc: not available URL: From bradford.wetmore at oracle.com Tue Feb 7 22:22:05 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 7 Feb 2017 14:22:05 -0800 Subject: RFR [9] 8173708: Re-enable AES cipher with CFB128 mode for Ucrypto provider In-Reply-To: <4d35f999-951d-13f2-9b96-468e88a0209e@oracle.com> References: <4d35f999-951d-13f2-9b96-468e88a0209e@oracle.com> Message-ID: <41e36ca4-5c3c-698e-1740-02811ec17fc5@oracle.com> Assuming that 15761286/7121679 is fixed in all of the Solaris versions we'll be supporting (as mentioned in 8173708), then this looks fine. Thanks, Brad On 1/31/2017 5:51 PM, Valerie Peng wrote: > Hi Brad, > > Would you have time to review this trivial Ucrypto config file update? > It's related to the Solaris fix that you relayed to me. > Given that some of our test machines may still run pre-S11.3 releases > and that JDK 9 is already at Rampdown 1 phase, I updated the test to > ignore the exception for CFB128 mode to minimize the possible impact of > re-enabling these Ucrypto algorithms. > > Webrev: http://cr.openjdk.java.net/~valeriep/8173708/webrev.00/ > > Thanks, > Valerie From anthony.scarpino at oracle.com Wed Feb 8 01:09:16 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 7 Feb 2017 17:09:16 -0800 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: <40efbe09-569e-caf4-2d24-73a0916e5fa3@oracle.com> References: <40efbe09-569e-caf4-2d24-73a0916e5fa3@oracle.com> Message-ID: I believe all comments are addressed in the below link http://cr.openjdk.java.net/~ascarpino/8160655/webrev.02/ Everything I didn't comment on inline below was because I hadn't posted an update-to-date webrev.01 at that time. Tony On 02/06/2017 12:17 PM, Sean Mullan wrote: > Hi Tony, > > Here are my comments on the latest webrev: > > * SignerInfo.java > > 355 try { > 356 JAR_DISABLED_CHECK.permits(digestAlgname, > cparams); > 357 } catch (CertPathValidatorException e) { > 358 throw new SignatureException(e.getMessage(), e); > 359 } > > It's a little odd this throws a CPVE because there is no certificate > being checked here. In offline discussions this will have to remain for now. > > * AlgorithmChecker.java > > 278 String currSigAlg = ((X509Certificate)cert).getSigAlgName(); > > Just use x509cert.getSigAlgName() instead. > > * SignatureFileVerifier.java > > 145 System.err.println("key = " + name + " == name " + name); > > leftover debug? > > 265 // Algorithms that have been checked if they are weak. > 266 private Map permittedAlgs= new HashMap<>(); > 267 // TSA timestamp of signed jar. The newest timestamp is used. > If there was > 268 // no TSA timestamp used when signed, current time is used > ("null"). > 269 private Timestamp timestamp = null; > > can you move these lines up to the top of the class where other > variables are declared? > > // Algorithms that have been checked if they are weak. > 266 private Map permittedAlgs= new HashMap<>(); > > It might be better to have a Map> where the key is > the header (*-DIGEST*) and the value is a list of weak algs. This way > you could avoid the need for the getWeakAlgorithms method and just get > the weak list of algs out of the map directly. An empty list or null > value would indicate the header is ok. > > 302 /* Look for the latest timestamp in the signature block */ > > s/the latest timestamp/the latest timestamp or no timestamp/ I changed the comment in a way that I think is more descriptive. > > * java.security > > Missing spaces between words on lines 646-648 (ex: algorithmin) > > * Main.java > > 640 void rey verifyJar(String jarName) > > typo? > > * PKIXExtendedParameters.java > > Update class description to reflect this contains more than a timestamp. > > --Sean > > On 1/30/17 6:57 PM, Anthony Scarpino wrote: >> On 01/23/2017 03:27 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I need a code review of this change that brings more detail constraints >>> checking and control to certpath and jar disabled algorithm Security >>> properties. >>> >>> http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ >>> >>> thanks >>> >>> Tony >> >> Updated review >> >> http://cr.openjdk.java.net/~ascarpino/8160655/webrev.01/ >> >> It address the comments and has a different SignatureFileVerifier.java >> >> Tony >> From anthony.scarpino at oracle.com Wed Feb 8 03:35:36 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 7 Feb 2017 19:35:36 -0800 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: <6d5e3b1f-1a92-4789-fb5b-f88f0fc8f1c9@oracle.com> References: <6d5e3b1f-1a92-4789-fb5b-f88f0fc8f1c9@oracle.com> Message-ID: <4b81e6fb-4d39-a080-173f-0365425e37ba@oracle.com> The two changes are connected, removing the key algorithm check in the second change is linked to changing the permits() in the first change. But I agree that this change is unnecessary.. I'm going to revert it back. thanks Tony On 01/26/2017 01:09 PM, Xuelei Fan wrote: > DisabledAlgorithmConstraints.java > ================================= > public final boolean permits(Set primitives, Key > key) { > - return checkConstraints(primitives, "", key, null); > + try { > + permits(new ConstraintsParameters(key.getAlgorithm(), null, > key, > + null)); > + return true; > + } catch (CertPathValidatorException e) { > + return false; > + } > } > Looks like there are some overlap if this method is not used for cert. > What's the point for this update? > > @@ -172,56 +180,21 @@ > - // check the key algorithm > - if (!permits(primitives, key.getAlgorithm(), null)) { > - return false; > - } > This block cannot be removed as the standard permits() (seel line 130) > still need to this check. > > Otherwise, looks fine to me. > > Xuelei > > On 1/23/2017 3:27 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this change that brings more detail constraints >> checking and control to certpath and jar disabled algorithm Security >> properties. >> >> http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ >> >> thanks >> >> Tony From sean.coffey at oracle.com Wed Feb 8 13:21:13 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 8 Feb 2017 13:21:13 +0000 Subject: TlsRsaPremasterSecretParameterSpec In-Reply-To: <3FA6BAADF79CCC418D052819A0E408C726105703@A1GTOEMBXV009.gto.a3c.atos.net> References: <3FA6BAADF79CCC418D052819A0E408C726105703@A1GTOEMBXV009.gto.a3c.atos.net> Message-ID: What version of JDK 8u are you running with ? There's been a few tweaks in this code area which might help you. https://bugs.openjdk.java.net/browse/JDK-8149017 https://bugs.openjdk.java.net/browse/JDK-8158111 If you can reproduce with 8u121, please log an issue via http://bugreport.java.com/ (or JBS if you have an account) - We need to be aware of such issues. Regards, Sean. On 07/02/17 21:29, Gardiner Michael wrote: > > Hello Java Security Developers > > We had a discussion a year and a bit ago about the > TlsRsaPremasterSecretParameterSpec being used in a way that doesn?t > seem to make sense. I?ve attached the email from 2015, but the same > question has arisen. > > It seems that the JSSE is expecting RSA Ciphers to be able to handle > TlsRsaPremasterSecretParameterSpec. Is the > TlsRsaPremasterSecretParameterSpec class going to move out of the > status of ?@deprecated Sun JDK internal use only --- WILL BE REMOVED > in a future release? towards something that will be expected of RSA > cipher instances to interoperate with the JSSE? > > This is a blocking issue currently with at least one large customer. > We could add some code in our provider to inspect if the parameter > spec sent is of the offending type, but I?d really rather not have to > handle a deprecated class that was never intended to be used outside > of the Sun code base. > > My current advice to this customer is: > > 1.Roll back to a previous version of Java that?s not affected by this > behaviour change > > 2.Ensure the use of PFS cipher suites so the RSA key is used only for > identity and not key exchange > > But both of those pieces of advice may not be practical in their > situation. > > Regards, > > Mike Gardiner > > Systems Security Architect > > Gemalto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Feb 8 16:30:05 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Feb 2017 11:30:05 -0500 Subject: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <1b626955-9a81-41de-89cc-7df9dfc57ad7@default> References: <9deec53c-b568-448d-9d29-be596a2a8814@default> <1b626955-9a81-41de-89cc-7df9dfc57ad7@default> Message-ID: <95f77c24-15fe-81cc-382c-f18ec982466d@oracle.com> On 2/7/17 4:26 AM, Sibabrata Sahoo wrote: > Hi Sean, > > Please find the updated webrev at: http://cr.openjdk.java.net/~ssahoo/8168075/webrev.01/ > > It includes the following changes, > 1) valid.policy, uses 'grant codebase "executable jar path"'. Hmm, the use of '.' in the codebase URL is probably not good practice here and I'm a little concerned it may not always work. Try this instead: grant codeBase "file:${test.classes}/-" A trailing "/-" matches all files (both class and JAR files) in the directory and recursively all files in subdirectories contained in that directory. --Sean > 2) In ClassLoaderTest.java, @bug renamed from 8168423 to 8168075. > 3) In ClassLoaderTest.java, the code comments has been removed from @summary section. But it retains the same at line: 91-102. > > Thanks, > Siba > > -----Original Message----- > From: Sean Mullan > Sent: Friday, January 27, 2017 12:07 AM > To: Sibabrata Sahoo; Adam Petcher; security-dev at openjdk.java.net > Subject: Re: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization > > Hi Siba, > > In valid.policy, use 'grant codeBase "file:${test.classes}/*"' so that only the tests are granted the needed permissions. > > In ClassLoaderTest.java, the @bug should be 8168075. Also, the @summary contains a bunch of lines (29-39) that should probably just be code comments. > > Seems fine otherwise. > > --Sean > > > On 1/11/17 10:33 AM, Sibabrata Sahoo wrote: >> Hi Adam/Sean, >> >> >> >> This patch is waiting for your review. >> >> >> >> Thanks, >> >> Siba >> >> >> >> *From:*Sibabrata Sahoo >> *Sent:* Friday, December 02, 2016 6:56 PM >> *To:* Sean Mullan; security-dev at openjdk.java.net >> *Subject:* [9] RFR: 8168423: Test Task: Custom system class loader + >> security manager + malformed policy file = recursive initialization >> >> >> >> Hi, >> >> >> >> Please review the patch for, >> >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8168423 >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8168423/webrev.00/ >> >> >> >> Description: >> >> This webrev address all possible cases for Classloader with >> SecurityManager having combination of valid/malformed policy file. >> This Test is going to fail until JDK-8168075 get fixed. In the mean >> time, it can be used to verify the fix for JDK-8168075. >> >> >> >> Here is the generic Logic behind generating all possible Test cases >> with different combination of policy file, class loader and module types. >> >> for(policyFile : {"NO_POLICY", "VALID", "MALFORMED"}) { >> >> for(classLoader : {"SystemClassLoader", "CustomClassLoader"}){ >> >> // It uses possible set of regular/modular jars to generate all >> possible Test cases in -cp and -module-path. >> >> for(clientModuletype : {"STRICT", "AUTO", "UNKNOWN"}) { >> >> for(classLoaderModuleType : {"STRICT", "AUTO", "UNKNOWN"}) >> { >> >> Create and run java command line for each possible >> Test cases and verify result. >> >> } >> >> } >> >> } >> >> } >> >> >> >> Thanks, >> >> Siba >> >> >> From sean.mullan at oracle.com Wed Feb 8 17:50:53 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Feb 2017 12:50:53 -0500 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: References: <40efbe09-569e-caf4-2d24-73a0916e5fa3@oracle.com> Message-ID: <4dc5599b-e3b2-a499-5018-aab98c17624d@oracle.com> The update looks good. --Sean On 2/7/17 8:09 PM, Anthony Scarpino wrote: > I believe all comments are addressed in the below link > > http://cr.openjdk.java.net/~ascarpino/8160655/webrev.02/ > > Everything I didn't comment on inline below was because I hadn't posted > an update-to-date webrev.01 at that time. > > Tony > > On 02/06/2017 12:17 PM, Sean Mullan wrote: >> Hi Tony, >> >> Here are my comments on the latest webrev: >> >> * SignerInfo.java >> >> 355 try { >> 356 JAR_DISABLED_CHECK.permits(digestAlgname, >> cparams); >> 357 } catch (CertPathValidatorException e) { >> 358 throw new SignatureException(e.getMessage(), e); >> 359 } >> >> It's a little odd this throws a CPVE because there is no certificate >> being checked here. > > In offline discussions this will have to remain for now. > > >> >> * AlgorithmChecker.java >> >> 278 String currSigAlg = ((X509Certificate)cert).getSigAlgName(); >> >> Just use x509cert.getSigAlgName() instead. >> >> * SignatureFileVerifier.java >> >> 145 System.err.println("key = " + name + " == name " + name); >> >> leftover debug? >> >> 265 // Algorithms that have been checked if they are weak. >> 266 private Map permittedAlgs= new HashMap<>(); >> 267 // TSA timestamp of signed jar. The newest timestamp is used. >> If there was >> 268 // no TSA timestamp used when signed, current time is used >> ("null"). >> 269 private Timestamp timestamp = null; >> >> can you move these lines up to the top of the class where other >> variables are declared? >> >> // Algorithms that have been checked if they are weak. >> 266 private Map permittedAlgs= new HashMap<>(); >> >> It might be better to have a Map> where the key is >> the header (*-DIGEST*) and the value is a list of weak algs. This way >> you could avoid the need for the getWeakAlgorithms method and just get >> the weak list of algs out of the map directly. An empty list or null >> value would indicate the header is ok. >> >> 302 /* Look for the latest timestamp in the signature block */ >> >> s/the latest timestamp/the latest timestamp or no timestamp/ > > I changed the comment in a way that I think is more descriptive. > >> >> * java.security >> >> Missing spaces between words on lines 646-648 (ex: algorithmin) >> >> * Main.java >> >> 640 void rey verifyJar(String jarName) >> >> typo? >> >> * PKIXExtendedParameters.java >> >> Update class description to reflect this contains more than a timestamp. >> >> --Sean >> >> On 1/30/17 6:57 PM, Anthony Scarpino wrote: >>> On 01/23/2017 03:27 PM, Anthony Scarpino wrote: >>>> Hi, >>>> >>>> I need a code review of this change that brings more detail constraints >>>> checking and control to certpath and jar disabled algorithm Security >>>> properties. >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ >>>> >>>> thanks >>>> >>>> Tony >>> >>> Updated review >>> >>> http://cr.openjdk.java.net/~ascarpino/8160655/webrev.01/ >>> >>> It address the comments and has a different SignatureFileVerifier.java >>> >>> Tony >>> > From anthony.scarpino at oracle.com Wed Feb 8 11:33:50 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 8 Feb 2017 03:33:50 -0800 Subject: RFR 8174157: Backout 8151116 Message-ID: Please review this simple backout. I pushed using the wrong bug, so I need to back this out, so I can push under the correct bug (8173410). http://cr.openjdk.java.net/~ascarpino/8174157/webrev/ thanks Tony From sean.mullan at oracle.com Wed Feb 8 18:53:35 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Feb 2017 13:53:35 -0500 Subject: RFR 8174157: Backout 8151116 In-Reply-To: References: Message-ID: Looks fine. --Sean On 2/8/17 6:33 AM, Anthony Scarpino wrote: > Please review this simple backout. I pushed using the wrong bug, so I > need to back this out, so I can push under the correct bug (8173410). > > http://cr.openjdk.java.net/~ascarpino/8174157/webrev/ > > thanks > > Tony From weijun.wang at oracle.com Thu Feb 9 02:26:11 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 9 Feb 2017 10:26:11 +0800 Subject: RFR 8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms In-Reply-To: <46c26a65-7886-3a64-60f1-808ae07cd028@oracle.com> References: <46c26a65-7886-3a64-60f1-808ae07cd028@oracle.com> Message-ID: <32c222a8-18a1-14d6-7f32-13afd0aefae8@oracle.com> An update webrev is at http://cr.openjdk.java.net/~weijun/8171319/webrev.01/ The major change is that every risk warning has a owner now, i.e. instead of just saying "MD5withRSA is weak", it prints out whose algorithm is weak. For example: The generated CRL uses the MD5withRSA signature algorithm which is considered a security risk. Please take a look at the output of the newly added regression test at http://cr.openjdk.java.net/~weijun/8171319/webrev.01/examples.txt Thanks Max On 01/23/2017 06:02 PM, Weijun Wang wrote: > Hi All > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8171319/webrev.00/ > > Warnings are printed to System.err when weak algorithms/keysizes are > detected during the execution, this includes input, output, and any > certs used. > > The detection applies to many keytool functions: > > - generation of certificate, certificate request, CRL > - reading (printing, listing, exporting) of above > - importing of certificate or certificates reply > > The behavior of most functions remains unchanged. The only exception is > "keytool -importcert", where the user must reply to a prompt if weak > algorithms/keysizes are detected, unless -noprompt is specified on the > command line. > > Warnings are either printed at the end, or before a prompt. > > If there are multiple weak points, multiple warnings will be printed. > > The detection is based on the security property > jdk.certpath.disabledAlgorithms. > > For example: > > $ keytool -genkeypair -alias a -dname CN=a -keyalg RSA -sigalg MD5withRSA > > Warning: > The MD5withRSA signature algorithm is considered a security risk. > > $ keytool -keystore ks -storepass changeit -keypass changeit -list > > Keystore type: JKS > Keystore provider: SUN > > Your keystore contains 3 entries > > b, Jan 23, 2017, PrivateKeyEntry, > Certificate fingerprint (SHA-256): > D8:46:B7:0B:8B:97:C2:DE:A2:17:62:01:27:82:2B:CE:B1:9B:12:0B:24:D5:47:BF:BD:54:EE:8A:71:29:2B:CE > > a, Jan 23, 2017, PrivateKeyEntry, > Certificate fingerprint (SHA-256): > 66:70:DF:11:14:A1:96:58:92:F5:6A:10:09:B1:2F:CC:1C:CC:2D:55:47:1D:EE:74:75:AA:26:63:E4:9D:EA:83 > > > Warning: > 's 512-bit RSA key is considered a security risk. > 's MD5withRSA signature algorithm is considered a security risk. > > $ keytool -importcert -alias a -file b+a.certs > > Warning: > Reply #2 of 2's 512-bit RSA key is considered a security risk. > > Install reply anyway? [no]:no > Certificate reply was not installed in keystore > > Thanks > Max From sibabrata.sahoo at oracle.com Thu Feb 9 07:45:18 2017 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 8 Feb 2017 23:45:18 -0800 (PST) Subject: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <95f77c24-15fe-81cc-382c-f18ec982466d@oracle.com> References: <9deec53c-b568-448d-9d29-be596a2a8814@default> <1b626955-9a81-41de-89cc-7df9dfc57ad7@default> <95f77c24-15fe-81cc-382c-f18ec982466d@oracle.com> Message-ID: <2928f456-3fd6-4779-a769-8ce7d10dfa53@default> Hi Sean, Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8168423/webrev.02/ The only change between the previous is, The bugid is reverted back from 8168075 to 8168423. The reason is it fails jcheck with the following message, remote: Bugid 8168075 already used in this repository, in revision 16548 Regarding the following comment on " grant codeBase "file:./jars/*" ", we have already discussed and we are fine here to not make any change. Thanks, Siba -----Original Message----- From: Sean Mullan Sent: Wednesday, February 08, 2017 10:00 PM To: Sibabrata Sahoo; Adam Petcher; security-dev at openjdk.java.net Subject: Re: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization On 2/7/17 4:26 AM, Sibabrata Sahoo wrote: > Hi Sean, > > Please find the updated webrev at: > http://cr.openjdk.java.net/~ssahoo/8168075/webrev.01/ > > It includes the following changes, > 1) valid.policy, uses 'grant codebase "executable jar path"'. Hmm, the use of '.' in the codebase URL is probably not good practice here and I'm a little concerned it may not always work. Try this instead: grant codeBase "file:${test.classes}/-" A trailing "/-" matches all files (both class and JAR files) in the directory and recursively all files in subdirectories contained in that directory. --Sean > 2) In ClassLoaderTest.java, @bug renamed from 8168423 to 8168075. > 3) In ClassLoaderTest.java, the code comments has been removed from @summary section. But it retains the same at line: 91-102. > > Thanks, > Siba > > -----Original Message----- > From: Sean Mullan > Sent: Friday, January 27, 2017 12:07 AM > To: Sibabrata Sahoo; Adam Petcher; security-dev at openjdk.java.net > Subject: Re: [9] RFR: 8168423: Test Task: Custom system class loader + > security manager + malformed policy file = recursive initialization > > Hi Siba, > > In valid.policy, use 'grant codeBase "file:${test.classes}/*"' so that only the tests are granted the needed permissions. > > In ClassLoaderTest.java, the @bug should be 8168075. Also, the @summary contains a bunch of lines (29-39) that should probably just be code comments. > > Seems fine otherwise. > > --Sean > > > On 1/11/17 10:33 AM, Sibabrata Sahoo wrote: >> Hi Adam/Sean, >> >> >> >> This patch is waiting for your review. >> >> >> >> Thanks, >> >> Siba >> >> >> >> *From:*Sibabrata Sahoo >> *Sent:* Friday, December 02, 2016 6:56 PM >> *To:* Sean Mullan; security-dev at openjdk.java.net >> *Subject:* [9] RFR: 8168423: Test Task: Custom system class loader + >> security manager + malformed policy file = recursive initialization >> >> >> >> Hi, >> >> >> >> Please review the patch for, >> >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8168423 >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8168423/webrev.00/ >> >> >> >> Description: >> >> This webrev address all possible cases for Classloader with >> SecurityManager having combination of valid/malformed policy file. >> This Test is going to fail until JDK-8168075 get fixed. In the mean >> time, it can be used to verify the fix for JDK-8168075. >> >> >> >> Here is the generic Logic behind generating all possible Test cases >> with different combination of policy file, class loader and module types. >> >> for(policyFile : {"NO_POLICY", "VALID", "MALFORMED"}) { >> >> for(classLoader : {"SystemClassLoader", "CustomClassLoader"}){ >> >> // It uses possible set of regular/modular jars to generate >> all possible Test cases in -cp and -module-path. >> >> for(clientModuletype : {"STRICT", "AUTO", "UNKNOWN"}) { >> >> for(classLoaderModuleType : {"STRICT", "AUTO", >> "UNKNOWN"}) { >> >> Create and run java command line for each possible >> Test cases and verify result. >> >> } >> >> } >> >> } >> >> } >> >> >> >> Thanks, >> >> Siba >> >> >> From sean.mullan at oracle.com Thu Feb 9 12:50:06 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 9 Feb 2017 07:50:06 -0500 Subject: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <2928f456-3fd6-4779-a769-8ce7d10dfa53@default> References: <9deec53c-b568-448d-9d29-be596a2a8814@default> <1b626955-9a81-41de-89cc-7df9dfc57ad7@default> <95f77c24-15fe-81cc-382c-f18ec982466d@oracle.com> <2928f456-3fd6-4779-a769-8ce7d10dfa53@default> Message-ID: On 2/9/17 2:45 AM, Sibabrata Sahoo wrote: > Hi Sean, > > Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8168423/webrev.02/ > > The only change between the previous is, > > The bugid is reverted back from 8168075 to 8168423. The reason is it fails jcheck with the following message, > remote: Bugid 8168075 already used in this repository, in revision 16548 Ok. > Regarding the following comment on " grant codeBase "file:./jars/*" ", we have already discussed and we are fine here to not make any change. Yes. Looks good to push. --Sean > > Thanks, > Siba > > -----Original Message----- > From: Sean Mullan > Sent: Wednesday, February 08, 2017 10:00 PM > To: Sibabrata Sahoo; Adam Petcher; security-dev at openjdk.java.net > Subject: Re: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization > > On 2/7/17 4:26 AM, Sibabrata Sahoo wrote: >> Hi Sean, >> >> Please find the updated webrev at: >> http://cr.openjdk.java.net/~ssahoo/8168075/webrev.01/ >> >> It includes the following changes, >> 1) valid.policy, uses 'grant codebase "executable jar path"'. > > Hmm, the use of '.' in the codebase URL is probably not good practice here and I'm a little concerned it may not always work. Try this instead: > > grant codeBase "file:${test.classes}/-" > > A trailing "/-" matches all files (both class and JAR files) in the directory and recursively all files in subdirectories contained in that directory. > > --Sean > >> 2) In ClassLoaderTest.java, @bug renamed from 8168423 to 8168075. >> 3) In ClassLoaderTest.java, the code comments has been removed from @summary section. But it retains the same at line: 91-102. >> >> Thanks, >> Siba >> >> -----Original Message----- >> From: Sean Mullan >> Sent: Friday, January 27, 2017 12:07 AM >> To: Sibabrata Sahoo; Adam Petcher; security-dev at openjdk.java.net >> Subject: Re: [9] RFR: 8168423: Test Task: Custom system class loader + >> security manager + malformed policy file = recursive initialization >> >> Hi Siba, >> >> In valid.policy, use 'grant codeBase "file:${test.classes}/*"' so that only the tests are granted the needed permissions. >> >> In ClassLoaderTest.java, the @bug should be 8168075. Also, the @summary contains a bunch of lines (29-39) that should probably just be code comments. >> >> Seems fine otherwise. >> >> --Sean >> >> >> On 1/11/17 10:33 AM, Sibabrata Sahoo wrote: >>> Hi Adam/Sean, >>> >>> >>> >>> This patch is waiting for your review. >>> >>> >>> >>> Thanks, >>> >>> Siba >>> >>> >>> >>> *From:*Sibabrata Sahoo >>> *Sent:* Friday, December 02, 2016 6:56 PM >>> *To:* Sean Mullan; security-dev at openjdk.java.net >>> *Subject:* [9] RFR: 8168423: Test Task: Custom system class loader + >>> security manager + malformed policy file = recursive initialization >>> >>> >>> >>> Hi, >>> >>> >>> >>> Please review the patch for, >>> >>> >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8168423 >>> >>> Webrev: http://cr.openjdk.java.net/~ssahoo/8168423/webrev.00/ >>> >>> >>> >>> Description: >>> >>> This webrev address all possible cases for Classloader with >>> SecurityManager having combination of valid/malformed policy file. >>> This Test is going to fail until JDK-8168075 get fixed. In the mean >>> time, it can be used to verify the fix for JDK-8168075. >>> >>> >>> >>> Here is the generic Logic behind generating all possible Test cases >>> with different combination of policy file, class loader and module types. >>> >>> for(policyFile : {"NO_POLICY", "VALID", "MALFORMED"}) { >>> >>> for(classLoader : {"SystemClassLoader", "CustomClassLoader"}){ >>> >>> // It uses possible set of regular/modular jars to generate >>> all possible Test cases in -cp and -module-path. >>> >>> for(clientModuletype : {"STRICT", "AUTO", "UNKNOWN"}) { >>> >>> for(classLoaderModuleType : {"STRICT", "AUTO", >>> "UNKNOWN"}) { >>> >>> Create and run java command line for each possible >>> Test cases and verify result. >>> >>> } >>> >>> } >>> >>> } >>> >>> } >>> >>> >>> >>> Thanks, >>> >>> Siba >>> >>> >>> From jonathan.patchell at gemalto.com Thu Feb 9 21:14:41 2017 From: jonathan.patchell at gemalto.com (Patchell Jonathan) Date: Thu, 9 Feb 2017 21:14:41 +0000 Subject: TlsRsaPremasterSecretParameterSpec In-Reply-To: References: <3FA6BAADF79CCC418D052819A0E408C726105703@A1GTOEMBXV009.gto.a3c.atos.net> Message-ID: <3CA8E03060A50342A441CA3D5500644D26E564C5@A1GTOEMBXV009.gto.a3c.atos.net> Hi Sean, I am using 8u121 and I have raised a bug at http://bugreport.java.com/. I haven't received any response but the internal review ID was: 9047607. Regards, Jonathan Patchell Senior Software Developer Gemalto From: Se?n Coffey [mailto:sean.coffey at oracle.com] Sent: February-08-17 8:21 AM To: Gardiner Michael ; Patchell Jonathan ; security-dev at openjdk.java.net Subject: Re: TlsRsaPremasterSecretParameterSpec What version of JDK 8u are you running with ? There's been a few tweaks in this code area which might help you. https://bugs.openjdk.java.net/browse/JDK-8149017 https://bugs.openjdk.java.net/browse/JDK-8158111 If you can reproduce with 8u121, please log an issue via http://bugreport.java.com/ (or JBS if you have an account) - We need to be aware of such issues. Regards, Sean. On 07/02/17 21:29, Gardiner Michael wrote: Hello Java Security Developers We had a discussion a year and a bit ago about the TlsRsaPremasterSecretParameterSpec being used in a way that doesn't seem to make sense. I've attached the email from 2015, but the same question has arisen. It seems that the JSSE is expecting RSA Ciphers to be able to handle TlsRsaPremasterSecretParameterSpec. Is the TlsRsaPremasterSecretParameterSpec class going to move out of the status of "@deprecated Sun JDK internal use only --- WILL BE REMOVED in a future release" towards something that will be expected of RSA cipher instances to interoperate with the JSSE? This is a blocking issue currently with at least one large customer. We could add some code in our provider to inspect if the parameter spec sent is of the offending type, but I'd really rather not have to handle a deprecated class that was never intended to be used outside of the Sun code base. My current advice to this customer is: 1. Roll back to a previous version of Java that's not affected by this behaviour change 2. Ensure the use of PFS cipher suites so the RSA key is used only for identity and not key exchange But both of those pieces of advice may not be practical in their situation. Regards, Mike Gardiner Systems Security Architect Gemalto ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Thu Feb 9 23:03:53 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 9 Feb 2017 23:03:53 +0000 Subject: TlsRsaPremasterSecretParameterSpec In-Reply-To: <3CA8E03060A50342A441CA3D5500644D26E564C5@A1GTOEMBXV009.gto.a3c.atos.net> References: <3FA6BAADF79CCC418D052819A0E408C726105703@A1GTOEMBXV009.gto.a3c.atos.net> <3CA8E03060A50342A441CA3D5500644D26E564C5@A1GTOEMBXV009.gto.a3c.atos.net> Message-ID: Thanks Jonathan. This is now tracked as https://bugs.openjdk.java.net/browse/JDK-8174690 We hope to triage this bug and keep updates in the bug report (including proposed fix version goals). You can also contact Oracle support if necessary. regards, Sean. On 09/02/2017 21:14, Patchell Jonathan wrote: > > Hi Sean, > > I am using 8u121 and I have raised a bug at > http://bugreport.java.com/. I haven?t received any response but the > internal review ID was: 9047607. > > Regards, > > Jonathan Patchell > > Senior Software Developer > > Gemalto > > *From:*Se?n Coffey [mailto:sean.coffey at oracle.com] > *Sent:* February-08-17 8:21 AM > *To:* Gardiner Michael ; Patchell > Jonathan ; security-dev at openjdk.java.net > *Subject:* Re: TlsRsaPremasterSecretParameterSpec > > What version of JDK 8u are you running with ? There's been a few > tweaks in this code area which might help you. > > https://bugs.openjdk.java.net/browse/JDK-8149017 > https://bugs.openjdk.java.net/browse/JDK-8158111 > > If you can reproduce with 8u121, please log an issue via > http://bugreport.java.com/ (or JBS if you > have an account) - We need to be aware of such issues. > > Regards, > Sean. > > On 07/02/17 21:29, Gardiner Michael wrote: > > Hello Java Security Developers > > We had a discussion a year and a bit ago about the > TlsRsaPremasterSecretParameterSpec being used in a way that > doesn?t seem to make sense. I?ve attached the email from 2015, > but the same question has arisen. > > It seems that the JSSE is expecting RSA Ciphers to be able to > handle TlsRsaPremasterSecretParameterSpec. Is the > TlsRsaPremasterSecretParameterSpec class going to move out of the > status of ?@deprecated Sun JDK internal use only --- WILL BE > REMOVED in a future release? towards something that will be > expected of RSA cipher instances to interoperate with the JSSE? > > This is a blocking issue currently with at least one large > customer. We could add some code in our provider to inspect if > the parameter spec sent is of the offending type, but I?d really > rather not have to handle a deprecated class that was never > intended to be used outside of the Sun code base. > > My current advice to this customer is: > > 1.Roll back to a previous version of Java that?s not affected by > this behaviour change > > 2.Ensure the use of PFS cipher suites so the RSA key is used only > for identity and not key exchange > > But both of those pieces of advice may not be practical in their > situation. > > Regards, > > Mike Gardiner > > Systems Security Architect > > Gemalto > > ------------------------------------------------------------------------ > This message and any attachments are intended solely for the > addressees and may contain confidential information. Any unauthorized > use or disclosure, either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable > for the message if altered, changed or falsified. If you are not the > intended recipient of this message, please delete it and notify the > sender. > Although all reasonable efforts have been made to keep this > transmission free from viruses, the sender will not be liable for > damages caused by a transmitted virus. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfox at mobileiron.com Fri Feb 10 21:41:05 2017 From: cfox at mobileiron.com (Christopher Fox) Date: Fri, 10 Feb 2017 21:41:05 +0000 Subject: [JDK-8146293] - Proposal to fix RSASSA-PSS AlgorithmChecker constraints for TLS 1.2 Message-ID: Hello, We have been looking into supporting RSASSA-PSS signature algorithms within the chain of an end-entity certificate used for TLS 1.2. The EE certificate itself is not signed with RSASSA-PSS. As mentioned in JDK-8146293, we run into the exception: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints Upon closer inspection we believe there are 2 workarounds for this issue: 1) Update sun.security.provider.certpath.AlgorithmChecker#check(java.security.cert.Certificate, java.util.Collection) to call getSigAlgName from the provided certificate (var1), instead of the converted sun.security.x509.X509CertImpl (var3). Looking at the code in question: public void check(Certificate var1, Collection var2) throws CertPathValidatorException { if(var1 instanceof X509Certificate && this.constraints != null) { X509CertImpl var3 = null; try { var3 = X509CertImpl.toImpl((X509Certificate)var1); } catch (CertificateException var15) { throw new CertPathValidatorException(var15); } PublicKey var4 = var3.getPublicKey(); String var5 = var3.getSigAlgName(); AlgorithmId var6 = null; try { var6 = (AlgorithmId)var3.get("x509.algorithm"); } catch (CertificateException var14) { throw new CertPathValidatorException(var14); } AlgorithmParameters var7 = var6.getParameters(); if(!this.constraints.permits(SIGNATURE_PRIMITIVE_SET, var5, var7)) { throw new CertPathValidatorException("Algorithm constraints check failed: " + var5, (Throwable)null, (CertPath)null, -1, BasicReason.ALGORITHM_CONSTRAINED); } else { .... The problem is that the sun.security.x509.X509CertImpl cannot convert the RSASSA-PSS algorithm OID to its friendly name when var3.getSigAlgName() is called: [cid:6a0141b3-a283-46ca-9db8-115cafc77a07] NOTE: In this case var1 is a instance of org.bouncycastle.jce.provider.X509CertificateObject In our tests, making this change results in a successful TLS connection without further changes: - String var5 = var3.getSigAlgName(); + String var5 = ((X509Certificate)var1).getSigAlgName(); 2) Update sun.security.x509.AlgorithmId to properly map the RSASSA-PSS algorithm OID to its friendly name. We have not experimented with this option, but believe it would have the same outcome, but with more code to change. Any thoughts from the community on which approach would be accepted into the JDK, or alternative suggestions not mentioned here, are appreciated. Thanks, Chris Fox Senior Software Engineer @ MobileIron -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pastedImage.png Type: image/png Size: 11906 bytes Desc: pastedImage.png URL: From sean.mullan at oracle.com Mon Feb 13 14:44:22 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Feb 2017 09:44:22 -0500 Subject: RFR release notes for multiple enhancements: krb5, SASL, JAAS, policytool In-Reply-To: References: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> <656811d6-b474-0ba4-4c71-8d251db2376f@oracle.com> Message-ID: <4c30e60f-2271-95e0-467a-598741577f7d@oracle.com> On 1/19/17 9:20 AM, Weijun Wang wrote: > On 01/19/2017 10:45 AM, Weijun Wang wrote: >> One more: >> >> https://bugs.openjdk.java.net/browse/JDK-8173018 >> (https://bugs.openjdk.java.net/browse/JDK-8076535) >> Deprecate the com.sun.jarsigner package >> >> The `com.sun.jarsigner` package is being deprecated. This includes >> the `ContentSigner` class, the `ContentSignerParameters` interface, and >> the jarsigner command's "-altsigner" and "-altsignerpath" options. Looks good. --Sean From sean.mullan at oracle.com Mon Feb 13 14:51:24 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Feb 2017 09:51:24 -0500 Subject: RFR release notes for multiple enhancements: krb5, SASL, JAAS, policytool In-Reply-To: References: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> <656811d6-b474-0ba4-4c71-8d251db2376f@oracle.com> Message-ID: <25d8b8c5-7d07-609f-7054-3395186afdb6@oracle.com> On 1/19/17 9:20 AM, Weijun Wang wrote: > Another one: > > https://bugs.openjdk.java.net/browse/JDK-8173035 > (https://bugs.openjdk.java.net/browse/JDK-8029904) > Remove com.sun.security.auth.callback.DialogCallbackHandler > > `com.sun.security.auth.callback.DialogCallbackHandler` has been > removed in JDK 9. This class, in the JDK-specific extensions to JAAS, > was deprecated in JDK 8 and previously flagged for removal. Looks good. --Sean From sean.mullan at oracle.com Mon Feb 13 16:25:50 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Feb 2017 11:25:50 -0500 Subject: RFR: 8174837: Add "since=9" to deprecated ContentSigner and ContentSignerParameters classes Message-ID: Could I get a quick code review for this simple fix for https://bugs.openjdk.java.net/browse/JDK-8174837?: diff --git a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java --- a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java +++ b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -38,7 +38,7 @@ * @deprecated This class has been deprecated. */ - at Deprecated + at Deprecated(since="9") public abstract class ContentSigner { /** diff --git a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java --- a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java +++ b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -36,7 +36,7 @@ * @author Vincent Ryan * @deprecated This class has been deprecated. */ - at Deprecated + at Deprecated(since="9") public interface ContentSignerParameters { From vincent.x.ryan at oracle.com Mon Feb 13 16:28:08 2017 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 13 Feb 2017 16:28:08 +0000 Subject: RFR: 8174837: Add "since=9" to deprecated ContentSigner and ContentSignerParameters classes In-Reply-To: References: Message-ID: <69A7EE16-516C-419D-AEF5-CA40D73E60D7@oracle.com> Your fix looks fine. Minor nit with the copyright header in ContentSigner.java: it?s missing a comma after ?2017?. Thanks. > On 13 Feb 2017, at 16:25, Sean Mullan wrote: > > Could I get a quick code review for this simple fix for https://bugs.openjdk.java.net/browse/JDK-8174837?: > > diff --git a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java > --- a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java > +++ b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -38,7 +38,7 @@ > * @deprecated This class has been deprecated. > */ > > - at Deprecated > + at Deprecated(since="9") > public abstract class ContentSigner { > > /** > diff --git a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java > --- a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java > +++ b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -36,7 +36,7 @@ > * @author Vincent Ryan > * @deprecated This class has been deprecated. > */ > - at Deprecated > + at Deprecated(since="9") > public interface ContentSignerParameters { From anthony.scarpino at oracle.com Mon Feb 13 21:47:31 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 13 Feb 2017 13:47:31 -0800 Subject: [RFR] 8174849: Change SHA1 certpath restrictions Message-ID: <6f051195-940f-76f9-8d07-e01eac355453@oracle.com> Hi, I need a quick review on a simple certpath config change. http://cr.openjdk.java.net/~ascarpino/8174849/webrev/ thanks Tony From sean.mullan at oracle.com Mon Feb 13 21:56:15 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Feb 2017 16:56:15 -0500 Subject: [RFR] 8174849: Change SHA1 certpath restrictions In-Reply-To: <6f051195-940f-76f9-8d07-e01eac355453@oracle.com> References: <6f051195-940f-76f9-8d07-e01eac355453@oracle.com> Message-ID: Looks fine. You'll need to add a noreg label to the bug though. --Sean On 2/13/17 4:47 PM, Anthony Scarpino wrote: > Hi, > > I need a quick review on a simple certpath config change. > > http://cr.openjdk.java.net/~ascarpino/8174849/webrev/ > > thanks > > Tony From amy.lu at oracle.com Tue Feb 14 02:48:52 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 14 Feb 2017 10:48:52 +0800 Subject: JDK 9 RFR of JDK-8174887: Problem list javax/net/ssl/DTLS/RespondToRetransmit.java Message-ID: javax/net/ssl/DTLS/RespondToRetransmit.java This test has been observed to fail intermittently with relatively high frequency at macosx (JDK-8169086). Until issue resolved, test should be problem listed for this platform. Also please note that issue originally reported in JDK-8170492. JDK-8170492 has been closed as dup of JDK-8169086, in which another test javax/net/ssl/DTLS/PacketLossRetransmission.java run into the same issue and has already been problem listed. Please review the update to ProblemList.txt. bug: https://bugs.openjdk.java.net/browse/JDK-8174887 Thanks, Amy --- old/test/ProblemList.txt 2017-02-14 10:37:49.000000000 +0800 +++ new/test/ProblemList.txt 2017-02-14 10:37:49.000000000 +0800 @@ -214,6 +214,7 @@ sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 +javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 ############################################################################ From weijun.wang at oracle.com Tue Feb 14 02:53:08 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Feb 2017 10:53:08 +0800 Subject: RFR 8168410: Multiple JCK tests are failing due to SecurityException is not thrown. Message-ID: <9061d2cf-4f6a-13c8-99ee-db32443e4d81@oracle.com> Please take a review at cr.openjdk.java.net/~weijun/8168410/webrev.00 JDK-8164705 introduced a compatibility layer to make sure that when FilePermission on "/pwd/x" is granted you can still read "x". The compatibility layer has 2 parts: 1. Inside our own default policy provider. 2. Inside ProtectionDomain. Multiple JCK tests fail because of #2. After some discussion, we decide to only enable #2 when a new system property jdk.security.filePermCompat is set. This means if user is using a customized policy implementation, the compatibility layer will not work, and granting a FilePermission on "x" will not allow the code reading "/pwd/x" when a security manager is on. Hopefully this is acceptable because: 1. A customized policy implementation is seldom used. 2. After JDK-8164705, we advise users to update their policy file so that the FilePermission path matches how a file is actually accessed. So if an application is reading "/pwd/x", the permission on "/pwd/x" (instead if "x") should be granted. Thanks Max From weijun.wang at oracle.com Tue Feb 14 02:58:05 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Feb 2017 10:58:05 +0800 Subject: RFR: 8174837: Add "since=9" to deprecated ContentSigner and ContentSignerParameters classes In-Reply-To: References: Message-ID: <76e8a10e-8a5c-0ac1-57f0-173df4df4967@oracle.com> Change looks fine. Thanks Max On 02/14/2017 12:25 AM, Sean Mullan wrote: > Could I get a quick code review for this simple fix for > https://bugs.openjdk.java.net/browse/JDK-8174837?: > > diff --git > a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java > b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java > --- a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java > +++ b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -38,7 +38,7 @@ > * @deprecated This class has been deprecated. > */ > > - at Deprecated > + at Deprecated(since="9") > public abstract class ContentSigner { > > /** > diff --git > a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java > b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java > > --- > a/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java > > +++ > b/src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameters.java > > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -36,7 +36,7 @@ > * @author Vincent Ryan > * @deprecated This class has been deprecated. > */ > - at Deprecated > + at Deprecated(since="9") > public interface ContentSignerParameters { From Xuelei.Fan at Oracle.Com Tue Feb 14 04:20:26 2017 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Mon, 13 Feb 2017 20:20:26 -0800 Subject: JDK 9 RFR of JDK-8174887: Problem list javax/net/ssl/DTLS/RespondToRetransmit.java In-Reply-To: References: Message-ID: looks fine to me. Thanks! Xuelei > On Feb 13, 2017, at 6:48 PM, Amy Lu wrote: > > javax/net/ssl/DTLS/RespondToRetransmit.java > > This test has been observed to fail intermittently with relatively high frequency at macosx (JDK-8169086). Until issue resolved, test should be problem listed for this platform. > > Also please note that issue originally reported in JDK-8170492. JDK-8170492 has been closed as dup of JDK-8169086, in which another test javax/net/ssl/DTLS/PacketLossRetransmission.java run into the same issue and has already been problem listed. > > Please review the update to ProblemList.txt. > > bug: https://bugs.openjdk.java.net/browse/JDK-8174887 > > Thanks, > Amy > > --- old/test/ProblemList.txt 2017-02-14 10:37:49.000000000 +0800 > +++ new/test/ProblemList.txt 2017-02-14 10:37:49.000000000 +0800 > @@ -214,6 +214,7 @@ > sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all > > javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 > +javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 > > ############################################################################ > > From ecki at zusammenkunft.net Tue Feb 14 07:33:50 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 14 Feb 2017 07:33:50 +0000 (UTC) Subject: [RFR] 8174849: Change SHA1 certpath restrictions In-Reply-To: <6f051195-940f-76f9-8d07-e01eac355453@oracle.com> References: <6f051195-940f-76f9-8d07-e01eac355453@oracle.com> Message-ID: <2C80812C54F23E38.2395E5D5-861C-4C43-9873-884CE41BF6F1@mail.outlook.com> Hello, The bug does not explain why. I would understand to completely deny SHA1 (I.e. Unconditionally), but allowing it seems strange, especially without a justification. Gruss Bernd -- http://bernd.eckenfels.net On Mon, Feb 13, 2017 at 10:57 PM +0100, "Anthony Scarpino" wrote: Hi, I need a quick review on a simple certpath config change. http://cr.openjdk.java.net/~ascarpino/8174849/webrev/ thanks Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Feb 14 10:55:33 2017 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 14 Feb 2017 18:55:33 +0800 Subject: RFR 8174909: Doc error in SecureRandom Message-ID: <1bc12ebf-e66e-02f7-a057-2f6340db5c1c@oracle.com> Please review this doc bug diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java --- a/src/java.base/share/classes/java/security/DrbgParameters.java +++ b/src/java.base/share/classes/java/security/DrbgParameters.java @@ -53,8 +53,8 @@ * for CTR_DRBG. Please note that it is not the algorithm used in * {@link SecureRandom#getInstance}, which we will call a * SecureRandom algorithm below), - *
  • optionally features, including prediction resistance - * and reseeding supports. + *
  • optional features, including prediction resistance + * and reseeding supports, *
  • highest security strength. * *

    diff --git a/src/java.base/share/classes/java/security/SecureRandom.java b/src/java.base/share/classes/java/security/SecureRandom.java --- a/src/java.base/share/classes/java/security/SecureRandom.java +++ b/src/java.base/share/classes/java/security/SecureRandom.java @@ -64,8 +64,8 @@ *

       * SecureRandom r1 = new SecureRandom();
       * SecureRandom r2 = SecureRandom.getInstance("NativePRNG");
    - * SecureRandom r3 = SecureRandom("DRBG",
    - *         DrbgParameters.Instantiation(128, RESEED_ONLY, null));
    + * SecureRandom r3 = SecureRandom.getInstance("DRBG", + * DrbgParameters.instantiation(128, RESEED_ONLY, null)); *
    * *

    The third statement above returns a {@code SecureRandom} object of the Thanks Max From sean.mullan at oracle.com Tue Feb 14 12:26:28 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Feb 2017 07:26:28 -0500 Subject: RFR 8174909: Doc error in SecureRandom In-Reply-To: <1bc12ebf-e66e-02f7-a057-2f6340db5c1c@oracle.com> References: <1bc12ebf-e66e-02f7-a057-2f6340db5c1c@oracle.com> Message-ID: Looks good. --Sean On 2/14/17 5:55 AM, Wang Weijun wrote: > Please review this doc bug > > diff --git > a/src/java.base/share/classes/java/security/DrbgParameters.java > b/src/java.base/share/classes/java/security/DrbgParameters.java > --- a/src/java.base/share/classes/java/security/DrbgParameters.java > +++ b/src/java.base/share/classes/java/security/DrbgParameters.java > @@ -53,8 +53,8 @@ > * for CTR_DRBG. Please note that it is not the algorithm used in > * {@link SecureRandom#getInstance}, which we will call a > * SecureRandom algorithm below), > - *

  • optionally features, including prediction resistance > - * and reseeding supports. > + *
  • optional features, including prediction resistance > + * and reseeding supports, > *
  • highest security strength. > * > *

    > diff --git a/src/java.base/share/classes/java/security/SecureRandom.java > b/src/java.base/share/classes/java/security/SecureRandom.java > --- a/src/java.base/share/classes/java/security/SecureRandom.java > +++ b/src/java.base/share/classes/java/security/SecureRandom.java > @@ -64,8 +64,8 @@ > *

    >   * SecureRandom r1 = new SecureRandom();
    >   * SecureRandom r2 = SecureRandom.getInstance("NativePRNG");
    > - * SecureRandom r3 = SecureRandom("DRBG",
    > - *         DrbgParameters.Instantiation(128, RESEED_ONLY, null));
    > + * SecureRandom r3 = SecureRandom.getInstance("DRBG", > + * DrbgParameters.instantiation(128, RESEED_ONLY, null)); > *
    > * > *

    The third statement above returns a {@code SecureRandom} object > of the > > Thanks > Max From sean.mullan at oracle.com Tue Feb 14 13:07:38 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Feb 2017 08:07:38 -0500 Subject: [RFR] 8174849: Change SHA1 certpath restrictions In-Reply-To: <2C80812C54F23E38.2395E5D5-861C-4C43-9873-884CE41BF6F1@mail.outlook.com> References: <6f051195-940f-76f9-8d07-e01eac355453@oracle.com> <2C80812C54F23E38.2395E5D5-861C-4C43-9873-884CE41BF6F1@mail.outlook.com> Message-ID: <79319f5c-530e-9c5a-4b57-0c6078372174@oracle.com> On 2/14/17 2:33 AM, Bernd Eckenfels wrote: > Hello, > > The bug does not explain why. I would understand to completely deny SHA1 > (I.e. Unconditionally), but allowing it seems strange, especially > without a justification. The initial disabling of SHA-1 certificates in JDK 9 is too broad and affects all certificates. The compatibility risk at this time is too high to make that change. We are working on an updated plan which will focus initially on TLS Server certificates. More details will be provided later. Thanks, Sean > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > > > > On Mon, Feb 13, 2017 at 10:57 PM +0100, "Anthony Scarpino" > > wrote: > > Hi, > > I need a quick review on a simple certpath config change. > > http://cr.openjdk.java.net/~ascarpino/8174849/webrev/ > > thanks > > Tony > From sean.mullan at oracle.com Tue Feb 14 15:55:41 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Feb 2017 10:55:41 -0500 Subject: RFR 8168410: Multiple JCK tests are failing due to SecurityException is not thrown. In-Reply-To: <9061d2cf-4f6a-13c8-99ee-db32443e4d81@oracle.com> References: <9061d2cf-4f6a-13c8-99ee-db32443e4d81@oracle.com> Message-ID: <06d7899c-23e7-d77f-be2f-dbc654514305@oracle.com> Hi Max, I agree this change is necessary so that we can resolve this tck-red issue before ZBB. However, since the TCK Policy provider implementation is not a "typical" implementation in the sense that it is denying permissions instead of granting permissions, I think we should continue to explore if there are any better options post-ZBB. A few minor comments: * ProtectionDomain.java Can you add more comments describing the purpose of the new property before lines 66 and 340? * CompatImpact.java Shouldn't you add 8168410 to the @bug line? --Sean On 2/13/17 9:53 PM, Weijun Wang wrote: > Please take a review at > > cr.openjdk.java.net/~weijun/8168410/webrev.00 > > JDK-8164705 introduced a compatibility layer to make sure that when > FilePermission on "/pwd/x" is granted you can still read "x". The > compatibility layer has 2 parts: > > 1. Inside our own default policy provider. > > 2. Inside ProtectionDomain. > > Multiple JCK tests fail because of #2. After some discussion, we decide > to only enable #2 when a new system property jdk.security.filePermCompat > is set. > > This means if user is using a customized policy implementation, the > compatibility layer will not work, and granting a FilePermission on "x" > will not allow the code reading "/pwd/x" when a security manager is on. > > Hopefully this is acceptable because: > > 1. A customized policy implementation is seldom used. > > 2. After JDK-8164705, we advise users to update their policy file so > that the FilePermission path matches how a file is actually accessed. So > if an application is reading "/pwd/x", the permission on "/pwd/x" > (instead if "x") should be granted. > > Thanks > Max > From jim.manico at owasp.org Tue Feb 14 21:50:32 2017 From: jim.manico at owasp.org (Jim Manico) Date: Tue, 14 Feb 2017 11:50:32 -1000 Subject: [RFR] 8174849: Change SHA1 certpath restrictions In-Reply-To: <79319f5c-530e-9c5a-4b57-0c6078372174@oracle.com> References: <6f051195-940f-76f9-8d07-e01eac355453@oracle.com> <2C80812C54F23E38.2395E5D5-861C-4C43-9873-884CE41BF6F1@mail.outlook.com> <79319f5c-530e-9c5a-4b57-0c6078372174@oracle.com> Message-ID: <3102a05e-51a6-c396-0c82-9893b34a85b3@owasp.org> The attacks against SHA-1 certificates are very real. SHA1 signatures are spoofable at a relatively low cost and that cost is only getting cheaper. Most other mature clients (browsers, etc) have an extremely aggressive rejection of SHA1 signatures. Why is Java9 rolling this back? What is breaking? Aloha, Jim Manico On 2/14/17 3:07 AM, Sean Mullan wrote: > On 2/14/17 2:33 AM, Bernd Eckenfels wrote: >> Hello, >> >> The bug does not explain why. I would understand to completely deny SHA1 >> (I.e. Unconditionally), but allowing it seems strange, especially >> without a justification. > > The initial disabling of SHA-1 certificates in JDK 9 is too broad and > affects all certificates. The compatibility risk at this time is too > high to make that change. We are working on an updated plan which will > focus initially on TLS Server certificates. More details will be > provided later. > > Thanks, > Sean > >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> >> >> >> >> On Mon, Feb 13, 2017 at 10:57 PM +0100, "Anthony Scarpino" >> > >> wrote: >> >> Hi, >> >> I need a quick review on a simple certpath config change. >> >> http://cr.openjdk.java.net/~ascarpino/8174849/webrev/ >> >> thanks >> >> Tony >> From weijun.wang at oracle.com Wed Feb 15 01:04:22 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Feb 2017 09:04:22 +0800 Subject: RFR 8168410: Multiple JCK tests are failing due to SecurityException is not thrown. In-Reply-To: <06d7899c-23e7-d77f-be2f-dbc654514305@oracle.com> References: <9061d2cf-4f6a-13c8-99ee-db32443e4d81@oracle.com> <06d7899c-23e7-d77f-be2f-dbc654514305@oracle.com> Message-ID: Webrev updated at http://cr.openjdk.java.net/~weijun/8168410/webrev.01/ Change since webrev.00: http://cr.openjdk.java.net/~weijun/8168410/webrev.01/interdiff.patch.html Thanks Max On 02/14/2017 11:55 PM, Sean Mullan wrote: > Hi Max, > > I agree this change is necessary so that we can resolve this tck-red > issue before ZBB. However, since the TCK Policy provider implementation > is not a "typical" implementation in the sense that it is denying > permissions instead of granting permissions, I think we should continue > to explore if there are any better options post-ZBB. > > A few minor comments: > > * ProtectionDomain.java > > Can you add more comments describing the purpose of the new property > before lines 66 and 340? > > * CompatImpact.java > > Shouldn't you add 8168410 to the @bug line? > > --Sean > > On 2/13/17 9:53 PM, Weijun Wang wrote: >> Please take a review at >> >> cr.openjdk.java.net/~weijun/8168410/webrev.00 >> >> JDK-8164705 introduced a compatibility layer to make sure that when >> FilePermission on "/pwd/x" is granted you can still read "x". The >> compatibility layer has 2 parts: >> >> 1. Inside our own default policy provider. >> >> 2. Inside ProtectionDomain. >> >> Multiple JCK tests fail because of #2. After some discussion, we decide >> to only enable #2 when a new system property jdk.security.filePermCompat >> is set. >> >> This means if user is using a customized policy implementation, the >> compatibility layer will not work, and granting a FilePermission on "x" >> will not allow the code reading "/pwd/x" when a security manager is on. >> >> Hopefully this is acceptable because: >> >> 1. A customized policy implementation is seldom used. >> >> 2. After JDK-8164705, we advise users to update their policy file so >> that the FilePermission path matches how a file is actually accessed. So >> if an application is reading "/pwd/x", the permission on "/pwd/x" >> (instead if "x") should be granted. >> >> Thanks >> Max >> From weijun.wang at oracle.com Wed Feb 15 01:16:47 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Feb 2017 09:16:47 +0800 Subject: RFR 8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms In-Reply-To: <32c222a8-18a1-14d6-7f32-13afd0aefae8@oracle.com> References: <46c26a65-7886-3a64-60f1-808ae07cd028@oracle.com> <32c222a8-18a1-14d6-7f32-13afd0aefae8@oracle.com> Message-ID: Ping again. Also, must we resolve this one before ZBB? --Max On 02/09/2017 10:26 AM, Weijun Wang wrote: > An update webrev is at > > http://cr.openjdk.java.net/~weijun/8171319/webrev.01/ > > The major change is that every risk warning has a owner now, i.e. > instead of just saying "MD5withRSA is weak", it prints out whose > algorithm is weak. For example: > > The generated CRL uses the MD5withRSA signature algorithm which is > considered a security risk. > > Please take a look at the output of the newly added regression test at > > http://cr.openjdk.java.net/~weijun/8171319/webrev.01/examples.txt > > Thanks > Max > > On 01/23/2017 06:02 PM, Weijun Wang wrote: >> Hi All >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8171319/webrev.00/ >> >> Warnings are printed to System.err when weak algorithms/keysizes are >> detected during the execution, this includes input, output, and any >> certs used. >> >> The detection applies to many keytool functions: >> >> - generation of certificate, certificate request, CRL >> - reading (printing, listing, exporting) of above >> - importing of certificate or certificates reply >> >> The behavior of most functions remains unchanged. The only exception is >> "keytool -importcert", where the user must reply to a prompt if weak >> algorithms/keysizes are detected, unless -noprompt is specified on the >> command line. >> >> Warnings are either printed at the end, or before a prompt. >> >> If there are multiple weak points, multiple warnings will be printed. >> >> The detection is based on the security property >> jdk.certpath.disabledAlgorithms. >> >> For example: >> >> $ keytool -genkeypair -alias a -dname CN=a -keyalg RSA -sigalg MD5withRSA >> >> Warning: >> The MD5withRSA signature algorithm is considered a security risk. >> >> $ keytool -keystore ks -storepass changeit -keypass changeit -list >> >> Keystore type: JKS >> Keystore provider: SUN >> >> Your keystore contains 3 entries >> >> b, Jan 23, 2017, PrivateKeyEntry, >> Certificate fingerprint (SHA-256): >> D8:46:B7:0B:8B:97:C2:DE:A2:17:62:01:27:82:2B:CE:B1:9B:12:0B:24:D5:47:BF:BD:54:EE:8A:71:29:2B:CE >> >> >> a, Jan 23, 2017, PrivateKeyEntry, >> Certificate fingerprint (SHA-256): >> 66:70:DF:11:14:A1:96:58:92:F5:6A:10:09:B1:2F:CC:1C:CC:2D:55:47:1D:EE:74:75:AA:26:63:E4:9D:EA:83 >> >> >> >> Warning: >> 's 512-bit RSA key is considered a security risk. >> 's MD5withRSA signature algorithm is considered a security risk. >> >> $ keytool -importcert -alias a -file b+a.certs >> >> Warning: >> Reply #2 of 2's 512-bit RSA key is considered a security risk. >> >> Install reply anyway? [no]:no >> Certificate reply was not installed in keystore >> >> Thanks >> Max From weijun.wang at oracle.com Wed Feb 15 08:35:52 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Feb 2017 16:35:52 +0800 Subject: RFR 8168410: Multiple JCK tests are failing due to SecurityException is not thrown. In-Reply-To: References: <9061d2cf-4f6a-13c8-99ee-db32443e4d81@oracle.com> <06d7899c-23e7-d77f-be2f-dbc654514305@oracle.com> Message-ID: I's also like to append the following paragraph to the current release note at https://bugs.openjdk.java.net/browse/JDK-8165836: Another new system property named jdk.security.filePermCompat, when set to "true", allows the compatibility layer above to work on third-party Policy implementations as well. The default value of this property is "false". Thanks Max On 02/15/2017 09:04 AM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8168410/webrev.01/ > > Change since webrev.00: > > http://cr.openjdk.java.net/~weijun/8168410/webrev.01/interdiff.patch.html > > Thanks > Max > > On 02/14/2017 11:55 PM, Sean Mullan wrote: >> Hi Max, >> >> I agree this change is necessary so that we can resolve this tck-red >> issue before ZBB. However, since the TCK Policy provider implementation >> is not a "typical" implementation in the sense that it is denying >> permissions instead of granting permissions, I think we should continue >> to explore if there are any better options post-ZBB. >> >> A few minor comments: >> >> * ProtectionDomain.java >> >> Can you add more comments describing the purpose of the new property >> before lines 66 and 340? >> >> * CompatImpact.java >> >> Shouldn't you add 8168410 to the @bug line? >> >> --Sean >> >> On 2/13/17 9:53 PM, Weijun Wang wrote: >>> Please take a review at >>> >>> cr.openjdk.java.net/~weijun/8168410/webrev.00 >>> >>> JDK-8164705 introduced a compatibility layer to make sure that when >>> FilePermission on "/pwd/x" is granted you can still read "x". The >>> compatibility layer has 2 parts: >>> >>> 1. Inside our own default policy provider. >>> >>> 2. Inside ProtectionDomain. >>> >>> Multiple JCK tests fail because of #2. After some discussion, we decide >>> to only enable #2 when a new system property jdk.security.filePermCompat >>> is set. >>> >>> This means if user is using a customized policy implementation, the >>> compatibility layer will not work, and granting a FilePermission on "x" >>> will not allow the code reading "/pwd/x" when a security manager is on. >>> >>> Hopefully this is acceptable because: >>> >>> 1. A customized policy implementation is seldom used. >>> >>> 2. After JDK-8164705, we advise users to update their policy file so >>> that the FilePermission path matches how a file is actually accessed. So >>> if an application is reading "/pwd/x", the permission on "/pwd/x" >>> (instead if "x") should be granted. >>> >>> Thanks >>> Max >>> From sean.mullan at oracle.com Wed Feb 15 12:18:12 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Feb 2017 07:18:12 -0500 Subject: RFR 8168410: Multiple JCK tests are failing due to SecurityException is not thrown. In-Reply-To: References: <9061d2cf-4f6a-13c8-99ee-db32443e4d81@oracle.com> <06d7899c-23e7-d77f-be2f-dbc654514305@oracle.com> Message-ID: <17fde31d-49d4-01cd-f213-9204901f89f9@oracle.com> Looks good. --Sean On 2/14/17 8:04 PM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8168410/webrev.01/ > > Change since webrev.00: > > http://cr.openjdk.java.net/~weijun/8168410/webrev.01/interdiff.patch.html > > Thanks > Max > > On 02/14/2017 11:55 PM, Sean Mullan wrote: >> Hi Max, >> >> I agree this change is necessary so that we can resolve this tck-red >> issue before ZBB. However, since the TCK Policy provider implementation >> is not a "typical" implementation in the sense that it is denying >> permissions instead of granting permissions, I think we should continue >> to explore if there are any better options post-ZBB. >> >> A few minor comments: >> >> * ProtectionDomain.java >> >> Can you add more comments describing the purpose of the new property >> before lines 66 and 340? >> >> * CompatImpact.java >> >> Shouldn't you add 8168410 to the @bug line? >> >> --Sean >> >> On 2/13/17 9:53 PM, Weijun Wang wrote: >>> Please take a review at >>> >>> cr.openjdk.java.net/~weijun/8168410/webrev.00 >>> >>> JDK-8164705 introduced a compatibility layer to make sure that when >>> FilePermission on "/pwd/x" is granted you can still read "x". The >>> compatibility layer has 2 parts: >>> >>> 1. Inside our own default policy provider. >>> >>> 2. Inside ProtectionDomain. >>> >>> Multiple JCK tests fail because of #2. After some discussion, we decide >>> to only enable #2 when a new system property jdk.security.filePermCompat >>> is set. >>> >>> This means if user is using a customized policy implementation, the >>> compatibility layer will not work, and granting a FilePermission on "x" >>> will not allow the code reading "/pwd/x" when a security manager is on. >>> >>> Hopefully this is acceptable because: >>> >>> 1. A customized policy implementation is seldom used. >>> >>> 2. After JDK-8164705, we advise users to update their policy file so >>> that the FilePermission path matches how a file is actually accessed. So >>> if an application is reading "/pwd/x", the permission on "/pwd/x" >>> (instead if "x") should be granted. >>> >>> Thanks >>> Max >>> From sean.mullan at oracle.com Wed Feb 15 12:30:38 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Feb 2017 07:30:38 -0500 Subject: RFR 8168410: Multiple JCK tests are failing due to SecurityException is not thrown. In-Reply-To: References: <9061d2cf-4f6a-13c8-99ee-db32443e4d81@oracle.com> <06d7899c-23e7-d77f-be2f-dbc654514305@oracle.com> Message-ID: <5e9cf8d5-3380-2955-1ee7-198560666ba6@oracle.com> On 2/15/17 3:35 AM, Weijun Wang wrote: > I's also like to append the following paragraph to the current release > note at https://bugs.openjdk.java.net/browse/JDK-8165836: > > Another new system property named jdk.security.filePermCompat, when > set to "true", allows the compatibility layer above to work on > third-party Policy implementations as well. The default value of this > property is "false". Looks fine. I suggest tweaking the wording a little: A system property named jdk.security.filePermCompat has also been introduced. When set to "true", the compatibility layer described above will also be supported for third-party Policy implementations. The default value of this property is "false". --Sean > > Thanks > Max > > > On 02/15/2017 09:04 AM, Weijun Wang wrote: >> Webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8168410/webrev.01/ >> >> Change since webrev.00: >> >> >> http://cr.openjdk.java.net/~weijun/8168410/webrev.01/interdiff.patch.html >> >> Thanks >> Max >> >> On 02/14/2017 11:55 PM, Sean Mullan wrote: >>> Hi Max, >>> >>> I agree this change is necessary so that we can resolve this tck-red >>> issue before ZBB. However, since the TCK Policy provider implementation >>> is not a "typical" implementation in the sense that it is denying >>> permissions instead of granting permissions, I think we should continue >>> to explore if there are any better options post-ZBB. >>> >>> A few minor comments: >>> >>> * ProtectionDomain.java >>> >>> Can you add more comments describing the purpose of the new property >>> before lines 66 and 340? >>> >>> * CompatImpact.java >>> >>> Shouldn't you add 8168410 to the @bug line? >>> >>> --Sean >>> >>> On 2/13/17 9:53 PM, Weijun Wang wrote: >>>> Please take a review at >>>> >>>> cr.openjdk.java.net/~weijun/8168410/webrev.00 >>>> >>>> JDK-8164705 introduced a compatibility layer to make sure that when >>>> FilePermission on "/pwd/x" is granted you can still read "x". The >>>> compatibility layer has 2 parts: >>>> >>>> 1. Inside our own default policy provider. >>>> >>>> 2. Inside ProtectionDomain. >>>> >>>> Multiple JCK tests fail because of #2. After some discussion, we decide >>>> to only enable #2 when a new system property >>>> jdk.security.filePermCompat >>>> is set. >>>> >>>> This means if user is using a customized policy implementation, the >>>> compatibility layer will not work, and granting a FilePermission on "x" >>>> will not allow the code reading "/pwd/x" when a security manager is on. >>>> >>>> Hopefully this is acceptable because: >>>> >>>> 1. A customized policy implementation is seldom used. >>>> >>>> 2. After JDK-8164705, we advise users to update their policy file so >>>> that the FilePermission path matches how a file is actually >>>> accessed. So >>>> if an application is reading "/pwd/x", the permission on "/pwd/x" >>>> (instead if "x") should be granted. >>>> >>>> Thanks >>>> Max >>>> From weijun.wang at oracle.com Wed Feb 15 13:44:23 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 15 Feb 2017 21:44:23 +0800 Subject: RFR 8168410: Multiple JCK tests are failing due to SecurityException is not thrown. In-Reply-To: <5e9cf8d5-3380-2955-1ee7-198560666ba6@oracle.com> References: <9061d2cf-4f6a-13c8-99ee-db32443e4d81@oracle.com> <06d7899c-23e7-d77f-be2f-dbc654514305@oracle.com> <5e9cf8d5-3380-2955-1ee7-198560666ba6@oracle.com> Message-ID: <7eff6a2d-3ff9-52ed-a7c2-99cc4afb823f@oracle.com> The last existing paragraph is already A system property named jdk.io.permissionsUseCanonicalPath has also been introduced. When it is set to "true", FilePermission will canonicalize its pathname as it did before JDK 9. The default value of this property is "false". and I'd like the first sentence to be a little different. --Max On 02/15/2017 08:30 PM, Sean Mullan wrote: > On 2/15/17 3:35 AM, Weijun Wang wrote: >> I's also like to append the following paragraph to the current release >> note at https://bugs.openjdk.java.net/browse/JDK-8165836: >> >> Another new system property named jdk.security.filePermCompat, when >> set to "true", allows the compatibility layer above to work on >> third-party Policy implementations as well. The default value of this >> property is "false". > > Looks fine. I suggest tweaking the wording a little: > > A system property named jdk.security.filePermCompat has also been > introduced. When set to "true", the compatibility layer described above > will also be supported for third-party Policy implementations. The > default value of this property is "false". > > --Sean > >> >> Thanks >> Max >> >> >> On 02/15/2017 09:04 AM, Weijun Wang wrote: >>> Webrev updated at >>> >>> http://cr.openjdk.java.net/~weijun/8168410/webrev.01/ >>> >>> Change since webrev.00: >>> >>> >>> http://cr.openjdk.java.net/~weijun/8168410/webrev.01/interdiff.patch.html >>> >>> >>> Thanks >>> Max >>> >>> On 02/14/2017 11:55 PM, Sean Mullan wrote: >>>> Hi Max, >>>> >>>> I agree this change is necessary so that we can resolve this tck-red >>>> issue before ZBB. However, since the TCK Policy provider implementation >>>> is not a "typical" implementation in the sense that it is denying >>>> permissions instead of granting permissions, I think we should continue >>>> to explore if there are any better options post-ZBB. >>>> >>>> A few minor comments: >>>> >>>> * ProtectionDomain.java >>>> >>>> Can you add more comments describing the purpose of the new property >>>> before lines 66 and 340? >>>> >>>> * CompatImpact.java >>>> >>>> Shouldn't you add 8168410 to the @bug line? >>>> >>>> --Sean >>>> >>>> On 2/13/17 9:53 PM, Weijun Wang wrote: >>>>> Please take a review at >>>>> >>>>> cr.openjdk.java.net/~weijun/8168410/webrev.00 >>>>> >>>>> JDK-8164705 introduced a compatibility layer to make sure that when >>>>> FilePermission on "/pwd/x" is granted you can still read "x". The >>>>> compatibility layer has 2 parts: >>>>> >>>>> 1. Inside our own default policy provider. >>>>> >>>>> 2. Inside ProtectionDomain. >>>>> >>>>> Multiple JCK tests fail because of #2. After some discussion, we >>>>> decide >>>>> to only enable #2 when a new system property >>>>> jdk.security.filePermCompat >>>>> is set. >>>>> >>>>> This means if user is using a customized policy implementation, the >>>>> compatibility layer will not work, and granting a FilePermission on >>>>> "x" >>>>> will not allow the code reading "/pwd/x" when a security manager is >>>>> on. >>>>> >>>>> Hopefully this is acceptable because: >>>>> >>>>> 1. A customized policy implementation is seldom used. >>>>> >>>>> 2. After JDK-8164705, we advise users to update their policy file so >>>>> that the FilePermission path matches how a file is actually >>>>> accessed. So >>>>> if an application is reading "/pwd/x", the permission on "/pwd/x" >>>>> (instead if "x") should be granted. >>>>> >>>>> Thanks >>>>> Max >>>>> From sean.coffey at oracle.com Wed Feb 15 15:04:08 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 15 Feb 2017 15:04:08 +0000 Subject: RFR 8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms In-Reply-To: References: <46c26a65-7886-3a64-60f1-808ae07cd028@oracle.com> <32c222a8-18a1-14d6-7f32-13afd0aefae8@oracle.com> Message-ID: <5ac4842f-a051-3280-8501-4b5f41a781c5@oracle.com> Hi Weijun, That's looks good to me and will be a big help for keytool usability. some thoughts : Main.java : in your printCRL method, would you consider editing the X509CRLImpl class to print with a customized string ? It'll make the code more resilient to future changes in this area i.e. something like this in X509CRLImpl : public String toString() { printCRL(null); } public String printCRL(String custom) { // transfer the toString() code to here // and allow for 'custom' string to be injected if non-null .. } in Main.java, I'd suggest an instanceof check for X509CRLImpl before calling printCRL(..). Could X509CRL.getSigAlgName() then be used for passing into the withWeak method call ? === Also in Main.java, maybe you could reduce printWeakWarningsWithoutNewLine and printWeakWarnings() to one method - e.g. printWeakWarnings(boolean newline) === Regards, Sean. On 15/02/17 01:16, Weijun Wang wrote: > Ping again. > > Also, must we resolve this one before ZBB? > > --Max > > On 02/09/2017 10:26 AM, Weijun Wang wrote: >> An update webrev is at >> >> http://cr.openjdk.java.net/~weijun/8171319/webrev.01/ >> >> The major change is that every risk warning has a owner now, i.e. >> instead of just saying "MD5withRSA is weak", it prints out whose >> algorithm is weak. For example: >> >> The generated CRL uses the MD5withRSA signature algorithm which is >> considered a security risk. >> >> Please take a look at the output of the newly added regression test at >> >> http://cr.openjdk.java.net/~weijun/8171319/webrev.01/examples.txt >> >> Thanks >> Max >> >> On 01/23/2017 06:02 PM, Weijun Wang wrote: >>> Hi All >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8171319/webrev.00/ >>> >>> Warnings are printed to System.err when weak algorithms/keysizes are >>> detected during the execution, this includes input, output, and any >>> certs used. >>> >>> The detection applies to many keytool functions: >>> >>> - generation of certificate, certificate request, CRL >>> - reading (printing, listing, exporting) of above >>> - importing of certificate or certificates reply >>> >>> The behavior of most functions remains unchanged. The only exception is >>> "keytool -importcert", where the user must reply to a prompt if weak >>> algorithms/keysizes are detected, unless -noprompt is specified on the >>> command line. >>> >>> Warnings are either printed at the end, or before a prompt. >>> >>> If there are multiple weak points, multiple warnings will be printed. >>> >>> The detection is based on the security property >>> jdk.certpath.disabledAlgorithms. >>> >>> For example: >>> >>> $ keytool -genkeypair -alias a -dname CN=a -keyalg RSA -sigalg >>> MD5withRSA >>> >>> Warning: >>> The MD5withRSA signature algorithm is considered a security risk. >>> >>> $ keytool -keystore ks -storepass changeit -keypass changeit -list >>> >>> Keystore type: JKS >>> Keystore provider: SUN >>> >>> Your keystore contains 3 entries >>> >>> b, Jan 23, 2017, PrivateKeyEntry, >>> Certificate fingerprint (SHA-256): >>> D8:46:B7:0B:8B:97:C2:DE:A2:17:62:01:27:82:2B:CE:B1:9B:12:0B:24:D5:47:BF:BD:54:EE:8A:71:29:2B:CE >>> >>> >>> >>> a, Jan 23, 2017, PrivateKeyEntry, >>> Certificate fingerprint (SHA-256): >>> 66:70:DF:11:14:A1:96:58:92:F5:6A:10:09:B1:2F:CC:1C:CC:2D:55:47:1D:EE:74:75:AA:26:63:E4:9D:EA:83 >>> >>> >>> >>> >>> Warning: >>> 's 512-bit RSA key is considered a security risk. >>> 's MD5withRSA signature algorithm is considered a security risk. >>> >>> $ keytool -importcert -alias a -file b+a.certs >>> >>> Warning: >>> Reply #2 of 2's 512-bit RSA key is considered a security risk. >>> >>> Install reply anyway? [no]:no >>> Certificate reply was not installed in keystore >>> >>> Thanks >>> Max From weijun.wang at oracle.com Thu Feb 16 08:50:22 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 16 Feb 2017 16:50:22 +0800 Subject: RFR 8168410: Multiple JCK tests are failing due to SecurityException is not thrown. In-Reply-To: <06d7899c-23e7-d77f-be2f-dbc654514305@oracle.com> References: <9061d2cf-4f6a-13c8-99ee-db32443e4d81@oracle.com> <06d7899c-23e7-d77f-be2f-dbc654514305@oracle.com> Message-ID: <4ded4df0-712a-4e4d-17f4-42bc4502f61a@oracle.com> On 02/14/2017 11:55 PM, Sean Mullan wrote: > Hi Max, > > I agree this change is necessary so that we can resolve this tck-red > issue before ZBB. However, since the TCK Policy provider implementation > is not a "typical" implementation in the sense that it is denying > permissions instead of granting permissions, I think we should continue > to explore if there are any better options post-ZBB. Some JAXP tests fail [1] after this code change, and I believe the case there -- permission on ${user.dir}/- granted, access base name without directory -- is the most popular one we want to support. But I cannot think of any solution that could make the TCK tests pass. --Max [1] https://bugs.openjdk.java.net/browse/JDK-8175043 From claes.redestad at oracle.com Thu Feb 16 16:24:27 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 16 Feb 2017 17:24:27 +0100 Subject: RFR: 8175079: Lazy initialization of ImageReader breaks rmid Message-ID: Hi, please review this simple backout of a startup optimization that has proven to destabilize things like rmid. Patch inline.. Bug: https://bugs.openjdk.java.net/browse/JDK-8175079 diff -r 87f2a6fb4b9a src/java.base/share/classes/java/lang/System.java --- a/src/java.base/share/classes/java/lang/System.java Wed Feb 15 15:57:18 2017 +0100 +++ b/src/java.base/share/classes/java/lang/System.java Thu Feb 16 17:18:49 2017 +0100 @@ -1945,9 +1945,6 @@ // set security manager String cn = System.getProperty("java.security.manager"); if (cn != null) { - // ensure image reader for java.base is initialized before security manager - Object.class.getResource("module-info.class"); - if (cn.isEmpty() || "default".equals(cn)) { System.setSecurityManager(new SecurityManager()); } else { diff -r 87f2a6fb4b9a src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java --- a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java Wed Feb 15 15:57:18 2017 +0100 +++ b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java Thu Feb 16 17:18:49 2017 +0100 @@ -115,12 +115,7 @@ long t0 = System.nanoTime(); // system modules (may be patched) - ModuleFinder systemModules; - if (SystemModules.MODULE_NAMES.length > 0) { - systemModules = SystemModuleFinder.getInstance(); - } else { - systemModules = ModuleFinder.ofSystem(); - } + ModuleFinder systemModules = ModuleFinder.ofSystem(); PerfCounters.systemModulesTime.addElapsedTimeFrom(t0); An alternative patch is to move the force initialization of the image reader from initPhase3 to SecurityManager, which ensures it's initialized before a security manager is installed. This preserves the startup optimization in case a SM is not installed: diff -r 87f2a6fb4b9a src/java.base/share/classes/java/lang/SecurityManager.java --- a/src/java.base/share/classes/java/lang/SecurityManager.java Wed Feb 15 15:57:18 2017 +0100 +++ b/src/java.base/share/classes/java/lang/SecurityManager.java Thu Feb 16 17:23:57 2017 +0100 @@ -233,6 +233,11 @@ public class SecurityManager { + static { + // ensure image reader for java.base is initialized before security + // manager is installed + Object.class.getResource("module-info.class"); + } /** * This field is true if there is a security check in * progress; false otherwise. Thanks! /Claes From Alan.Bateman at oracle.com Thu Feb 16 16:27:00 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Feb 2017 16:27:00 +0000 Subject: RFR: 8175079: Lazy initialization of ImageReader breaks rmid In-Reply-To: References: Message-ID: <0e5e4613-add1-8df9-3ea9-45a2a0907921@oracle.com> I think go with the first for now. -Alan On 16/02/2017 16:24, Claes Redestad wrote: > Hi, > > please review this simple backout of a startup optimization that has > proven to destabilize things like rmid. Patch inline.. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8175079 > > diff -r 87f2a6fb4b9a src/java.base/share/classes/java/lang/System.java > --- a/src/java.base/share/classes/java/lang/System.java Wed Feb 15 > 15:57:18 2017 +0100 > +++ b/src/java.base/share/classes/java/lang/System.java Thu Feb 16 > 17:18:49 2017 +0100 > @@ -1945,9 +1945,6 @@ > // set security manager > String cn = System.getProperty("java.security.manager"); > if (cn != null) { > - // ensure image reader for java.base is initialized > before security manager > - Object.class.getResource("module-info.class"); > - > if (cn.isEmpty() || "default".equals(cn)) { > System.setSecurityManager(new SecurityManager()); > } else { > diff -r 87f2a6fb4b9a > src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java > --- > a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java > Wed Feb 15 15:57:18 2017 +0100 > +++ > b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java > Thu Feb 16 17:18:49 2017 +0100 > @@ -115,12 +115,7 @@ > long t0 = System.nanoTime(); > > // system modules (may be patched) > - ModuleFinder systemModules; > - if (SystemModules.MODULE_NAMES.length > 0) { > - systemModules = SystemModuleFinder.getInstance(); > - } else { > - systemModules = ModuleFinder.ofSystem(); > - } > + ModuleFinder systemModules = ModuleFinder.ofSystem(); > > PerfCounters.systemModulesTime.addElapsedTimeFrom(t0); > > > An alternative patch is to move the force initialization of the image > reader from initPhase3 to SecurityManager, > which ensures it's initialized before a security manager is installed. > This preserves the startup optimization in > case a SM is not installed: > > diff -r 87f2a6fb4b9a > src/java.base/share/classes/java/lang/SecurityManager.java > --- a/src/java.base/share/classes/java/lang/SecurityManager.java Wed > Feb 15 15:57:18 2017 +0100 > +++ b/src/java.base/share/classes/java/lang/SecurityManager.java Thu > Feb 16 17:23:57 2017 +0100 > @@ -233,6 +233,11 @@ > public > class SecurityManager { > > + static { > + // ensure image reader for java.base is initialized before > security > + // manager is installed > + Object.class.getResource("module-info.class"); > + } > /** > * This field is true if there is a security check in > * progress; false otherwise. > > > Thanks! > > /Claes From claes.redestad at oracle.com Thu Feb 16 16:30:14 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 16 Feb 2017 17:30:14 +0100 Subject: RFR: 8175079: Lazy initialization of ImageReader breaks rmid In-Reply-To: <0e5e4613-add1-8df9-3ea9-45a2a0907921@oracle.com> References: <0e5e4613-add1-8df9-3ea9-45a2a0907921@oracle.com> Message-ID: Done! On 02/16/2017 05:27 PM, Alan Bateman wrote: > I think go with the first for now. > > -Alan > > > On 16/02/2017 16:24, Claes Redestad wrote: > >> Hi, >> >> please review this simple backout of a startup optimization that has >> proven to destabilize things like rmid. Patch inline.. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8175079 >> >> diff -r 87f2a6fb4b9a src/java.base/share/classes/java/lang/System.java >> --- a/src/java.base/share/classes/java/lang/System.java Wed Feb 15 >> 15:57:18 2017 +0100 >> +++ b/src/java.base/share/classes/java/lang/System.java Thu Feb 16 >> 17:18:49 2017 +0100 >> @@ -1945,9 +1945,6 @@ >> // set security manager >> String cn = System.getProperty("java.security.manager"); >> if (cn != null) { >> - // ensure image reader for java.base is initialized >> before security manager >> - Object.class.getResource("module-info.class"); >> - >> if (cn.isEmpty() || "default".equals(cn)) { >> System.setSecurityManager(new SecurityManager()); >> } else { >> diff -r 87f2a6fb4b9a >> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java >> --- >> a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java >> Wed Feb 15 15:57:18 2017 +0100 >> +++ >> b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java >> Thu Feb 16 17:18:49 2017 +0100 >> @@ -115,12 +115,7 @@ >> long t0 = System.nanoTime(); >> >> // system modules (may be patched) >> - ModuleFinder systemModules; >> - if (SystemModules.MODULE_NAMES.length > 0) { >> - systemModules = SystemModuleFinder.getInstance(); >> - } else { >> - systemModules = ModuleFinder.ofSystem(); >> - } >> + ModuleFinder systemModules = ModuleFinder.ofSystem(); >> >> PerfCounters.systemModulesTime.addElapsedTimeFrom(t0); >> >> >> An alternative patch is to move the force initialization of the image >> reader from initPhase3 to SecurityManager, >> which ensures it's initialized before a security manager is >> installed. This preserves the startup optimization in >> case a SM is not installed: >> >> diff -r 87f2a6fb4b9a >> src/java.base/share/classes/java/lang/SecurityManager.java >> --- a/src/java.base/share/classes/java/lang/SecurityManager.java Wed >> Feb 15 15:57:18 2017 +0100 >> +++ b/src/java.base/share/classes/java/lang/SecurityManager.java Thu >> Feb 16 17:23:57 2017 +0100 >> @@ -233,6 +233,11 @@ >> public >> class SecurityManager { >> >> + static { >> + // ensure image reader for java.base is initialized before >> security >> + // manager is installed >> + Object.class.getResource("module-info.class"); >> + } >> /** >> * This field is true if there is a security check in >> * progress; false otherwise. >> >> >> Thanks! >> >> /Claes > From weijun.wang at oracle.com Fri Feb 17 01:16:29 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 Feb 2017 09:16:29 +0800 Subject: RFR 8175120: Remove old tests on kdc timeout policy Message-ID: <560eebef-2b64-39a5-3791-46957bc7ee41@oracle.com> The new kdc timeout policy test KdcPolicy.java [1] has been running for some time and it's both faster and more reliable. I request removing the old ones: files: - test/sun/security/krb5/auto/BadKdc.java - test/sun/security/krb5/auto/BadKdc1.java - test/sun/security/krb5/auto/BadKdc2.java - test/sun/security/krb5/auto/BadKdc3.java - test/sun/security/krb5/auto/BadKdc4.java - test/sun/security/krb5/auto/CommMatcher.java - test/sun/security/krb5/auto/MaxRetries.java - test/sun/security/krb5/auto/TcpTimeout.java - test/sun/security/krb5/auto/UdpTcp.java Thanks Max [1] http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014700.html From valerie.peng at oracle.com Fri Feb 17 01:26:34 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 16 Feb 2017 17:26:34 -0800 Subject: RFR 8006259: Test example vectors from NIST SP 800-38A In-Reply-To: <4ae41476-b0a7-629a-5527-5897db412372@oracle.com> References: <4ae41476-b0a7-629a-5527-5897db412372@oracle.com> Message-ID: Changes look fine. Just a nit on code conventions, we normally use the style below: try { ... } catch (..) { ... } Can you update the test source to follow the same style? Thanks, Valerie On 2/7/2017 11:50 AM, Adam Petcher wrote: > This change adds a test which executes example vectors from NIST SP > 800-38A to check AES in various modes of operation. The test pulls in > all of the providers and runs the appropriate vectors for all > supported modes of operation on each provider. It passes on all > platforms on JPRT, and I confirmed that it exercises OracleUcrypto and > SunPKCS11 on Solaris. The CFB1 mode is included even though no > provider seems to support it at this time. > > http://cr.openjdk.java.net/~apetcher/8006259/webrev.00/ > From Xuelei.Fan at Oracle.Com Fri Feb 17 01:59:31 2017 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Thu, 16 Feb 2017 17:59:31 -0800 Subject: RFR 8175120: Remove old tests on kdc timeout policy In-Reply-To: <560eebef-2b64-39a5-3791-46957bc7ee41@oracle.com> References: <560eebef-2b64-39a5-3791-46957bc7ee41@oracle.com> Message-ID: <3826C30D-5803-4249-85FA-3229547ABFED@Oracle.Com> OK. Xuelei > On Feb 16, 2017, at 5:16 PM, Weijun Wang wrote: > > The new kdc timeout policy test KdcPolicy.java [1] has been running for some time and it's both faster and more reliable. I request removing the old ones: > > files: > - test/sun/security/krb5/auto/BadKdc.java > - test/sun/security/krb5/auto/BadKdc1.java > - test/sun/security/krb5/auto/BadKdc2.java > - test/sun/security/krb5/auto/BadKdc3.java > - test/sun/security/krb5/auto/BadKdc4.java > - test/sun/security/krb5/auto/CommMatcher.java > - test/sun/security/krb5/auto/MaxRetries.java > - test/sun/security/krb5/auto/TcpTimeout.java > - test/sun/security/krb5/auto/UdpTcp.java > > Thanks > Max > > [1] http://mail.openjdk.java.net/pipermail/security-dev/2016-August/014700.html From weijun.wang at oracle.com Fri Feb 17 02:35:17 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 Feb 2017 10:35:17 +0800 Subject: RFR 8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms In-Reply-To: <5ac4842f-a051-3280-8501-4b5f41a781c5@oracle.com> References: <46c26a65-7886-3a64-60f1-808ae07cd028@oracle.com> <32c222a8-18a1-14d6-7f32-13afd0aefae8@oracle.com> <5ac4842f-a051-3280-8501-4b5f41a781c5@oracle.com> Message-ID: On 02/15/2017 11:04 PM, Se?n Coffey wrote: > Hi Weijun, > > That's looks good to me and will be a big help for keytool usability. > > some thoughts : > > Main.java : in your printCRL method, would you consider editing the > X509CRLImpl class to print with a customized string ? It'll make the > code more resilient to future changes in this area > > i.e. something like this in X509CRLImpl : > > public String toString() { printCRL(null); } > public String printCRL(String custom) { > // transfer the toString() code to here > // and allow for 'custom' string to be injected if non-null > .. > } > > in Main.java, I'd suggest an instanceof check for X509CRLImpl before > calling printCRL(..). Could X509CRL.getSigAlgName() then be used for > passing into the withWeak method call ? I can probably pass DISABLED_CHECK into this new printCRL() method. Will try. > > === > > Also in Main.java, maybe you could reduce > printWeakWarningsWithoutNewLine and printWeakWarnings() to one method - > e.g. printWeakWarnings(boolean newline) Good idea. Thanks Max From sean.mullan at oracle.com Fri Feb 17 15:57:33 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Feb 2017 10:57:33 -0500 Subject: [JDK-8146293] - Proposal to fix RSASSA-PSS AlgorithmChecker constraints for TLS 1.2 In-Reply-To: References: Message-ID: Hi Chris, Comments inline ... On 2/10/17 4:41 PM, Christopher Fox wrote: > We have been looking into supporting RSASSA-PSS signature algorithms > within the chain of an end-entity certificate used for TLS 1.2. The EE > certificate itself is not signed with RSASSA-PSS. > > As mentioned in JDK-8146293 > , we run into the > exception: java.security.cert.CertificateException: Certificates does > not conform to algorithm constraints > > Upon closer inspection we believe there are 2 workarounds for this issue: > > 1) > Update sun.security.provider.certpath.AlgorithmChecker#check(java.security.cert.Certificate, > java.util.Collection) to call getSigAlgName from the > provided certificate (var1), instead of the > converted sun.security.x509.X509CertImpl (var3). > > Looking at the code in question: > > public void check(Certificate var1, Collection var2) throws CertPathValidatorException { > if(var1 instanceof X509Certificate && this.constraints != null) { > X509CertImpl var3 = null; > > try { > var3 = X509CertImpl.toImpl((X509Certificate)var1); > } catch (CertificateException var15) { > throw new CertPathValidatorException(var15); > } > > PublicKey var4 = var3.getPublicKey(); > String var5 = var3.getSigAlgName(); > AlgorithmId var6 = null; > > try { > var6 = (AlgorithmId)var3.get("x509.algorithm"); > } catch (CertificateException var14) { > throw new CertPathValidatorException(var14); > } > > AlgorithmParameters var7 = var6.getParameters(); > if(!this.constraints.permits(SIGNATURE_PRIMITIVE_SET, var5, var7)) { > throw new CertPathValidatorException("Algorithm constraints check failed: " + var5, (Throwable)null, (CertPath)null, -1, BasicReason.ALGORITHM_CONSTRAINED); > } else { > .... > > The problem is that the sun.security.x509.X509CertImpl cannot > convert the RSASSA-PSS algorithm OID to its friendly name when > var3.getSigAlgName() is called: > > NOTE: In this case var1 is a instance > of org.bouncycastle.jce.provider.X509CertificateObject > > In our tests, making this change results in a successful TLS > connection without further changes: > > - Stringvar5 = var3.getSigAlgName(); > + Stringvar5 = ((X509Certificate)var1).getSigAlgName(); We have just fixed this in JDK 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da > 2) Update sun.security.x509.AlgorithmId to properly map the RSASSA-PSS > algorithm OID to its friendly name. We have not experimented with this > option, but believe it would have the same outcome, but with more code > to change. I think that's a more involved changes that will be addressed by JDK-8146293. Thanks, Sean From adam.petcher at oracle.com Fri Feb 17 16:18:07 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 17 Feb 2017 11:18:07 -0500 Subject: RFR 8006259: Test example vectors from NIST SP 800-38A In-Reply-To: References: <4ae41476-b0a7-629a-5527-5897db412372@oracle.com> Message-ID: Fixed. Here is the new webrev: http://cr.openjdk.java.net/~apetcher/8006259/webrev.01/ On 2/16/2017 8:26 PM, Valerie Peng wrote: > > Changes look fine. > Just a nit on code conventions, we normally use the style below: > try { > ... > } catch (..) { > ... > } > > Can you update the test source to follow the same style? > Thanks, > Valerie > > On 2/7/2017 11:50 AM, Adam Petcher wrote: >> This change adds a test which executes example vectors from NIST SP >> 800-38A to check AES in various modes of operation. The test pulls in >> all of the providers and runs the appropriate vectors for all >> supported modes of operation on each provider. It passes on all >> platforms on JPRT, and I confirmed that it exercises OracleUcrypto >> and SunPKCS11 on Solaris. The CFB1 mode is included even though no >> provider seems to support it at this time. >> >> http://cr.openjdk.java.net/~apetcher/8006259/webrev.00/ >> > From cfox at mobileiron.com Fri Feb 17 16:21:49 2017 From: cfox at mobileiron.com (Christopher Fox) Date: Fri, 17 Feb 2017 16:21:49 +0000 Subject: [JDK-8146293] - Proposal to fix RSASSA-PSS AlgorithmChecker constraints for TLS 1.2 In-Reply-To: References: , Message-ID: Hello Sean, That's great news that the change is in JDK9. Will the change be back-ported to a JDK8 update as well? Our product is currently on JDK8. Thanks, Chris Fox ________________________________ From: Sean Mullan Sent: Friday, February 17, 2017 10:57:33 AM To: Christopher Fox; security-dev at openjdk.java.net Cc: Glen Beasley; Timothy Jackson Subject: Re: [JDK-8146293] - Proposal to fix RSASSA-PSS AlgorithmChecker constraints for TLS 1.2 Hi Chris, Comments inline ... On 2/10/17 4:41 PM, Christopher Fox wrote: > We have been looking into supporting RSASSA-PSS signature algorithms > within the chain of an end-entity certificate used for TLS 1.2. The EE > certificate itself is not signed with RSASSA-PSS. > > As mentioned in JDK-8146293 > , we run into the > exception: java.security.cert.CertificateException: Certificates does > not conform to algorithm constraints > > Upon closer inspection we believe there are 2 workarounds for this issue: > > 1) > Update sun.security.provider.certpath.AlgorithmChecker#check(java.security.cert.Certificate, > java.util.Collection) to call getSigAlgName from the > provided certificate (var1), instead of the > converted sun.security.x509.X509CertImpl (var3). > > Looking at the code in question: > > public void check(Certificate var1, Collection var2) throws CertPathValidatorException { > if(var1 instanceof X509Certificate && this.constraints != null) { > X509CertImpl var3 = null; > > try { > var3 = X509CertImpl.toImpl((X509Certificate)var1); > } catch (CertificateException var15) { > throw new CertPathValidatorException(var15); > } > > PublicKey var4 = var3.getPublicKey(); > String var5 = var3.getSigAlgName(); > AlgorithmId var6 = null; > > try { > var6 = (AlgorithmId)var3.get("x509.algorithm"); > } catch (CertificateException var14) { > throw new CertPathValidatorException(var14); > } > > AlgorithmParameters var7 = var6.getParameters(); > if(!this.constraints.permits(SIGNATURE_PRIMITIVE_SET, var5, var7)) { > throw new CertPathValidatorException("Algorithm constraints check failed: " + var5, (Throwable)null, (CertPath)null, -1, BasicReason.ALGORITHM_CONSTRAINED); > } else { > .... > > The problem is that the sun.security.x509.X509CertImpl cannot > convert the RSASSA-PSS algorithm OID to its friendly name when > var3.getSigAlgName() is called: > > NOTE: In this case var1 is a instance > of org.bouncycastle.jce.provider.X509CertificateObject > > In our tests, making this change results in a successful TLS > connection without further changes: > > - Stringvar5 = var3.getSigAlgName(); > + Stringvar5 = ((X509Certificate)var1).getSigAlgName(); We have just fixed this in JDK 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da > 2) Update sun.security.x509.AlgorithmId to properly map the RSASSA-PSS > algorithm OID to its friendly name. We have not experimented with this > option, but believe it would have the same outcome, but with more code > to change. I think that's a more involved changes that will be addressed by JDK-8146293. Thanks, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Feb 17 16:26:11 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Feb 2017 11:26:11 -0500 Subject: [JDK-8146293] - Proposal to fix RSASSA-PSS AlgorithmChecker constraints for TLS 1.2 In-Reply-To: References: Message-ID: On 2/17/17 11:21 AM, Christopher Fox wrote: > Hello Sean, > > > That's great news that the change is in JDK9. Will the change be > back-ported to a JDK8 update as well? Yes, but exactly which update is still TBD. --Sean > > > Our product is currently on JDK8. > > > Thanks, > > Chris Fox > > ------------------------------------------------------------------------ > *From:* Sean Mullan > *Sent:* Friday, February 17, 2017 10:57:33 AM > *To:* Christopher Fox; security-dev at openjdk.java.net > *Cc:* Glen Beasley; Timothy Jackson > *Subject:* Re: [JDK-8146293] - Proposal to fix RSASSA-PSS > AlgorithmChecker constraints for TLS 1.2 > > Hi Chris, > > Comments inline ... > > On 2/10/17 4:41 PM, Christopher Fox wrote: >> We have been looking into supporting RSASSA-PSS signature algorithms >> within the chain of an end-entity certificate used for TLS 1.2. The EE >> certificate itself is not signed with RSASSA-PSS. >> >> As mentioned in JDK-8146293 >> , we run into the >> exception: java.security.cert.CertificateException: Certificates does >> not conform to algorithm constraints >> >> Upon closer inspection we believe there are 2 workarounds for this issue: >> >> 1) >> Update sun.security.provider.certpath.AlgorithmChecker#check(java.security.cert.Certificate, >> java.util.Collection) to call getSigAlgName from the >> provided certificate (var1), instead of the >> converted sun.security.x509.X509CertImpl (var3). >> >> Looking at the code in question: >> >> public void check(Certificate var1, Collection var2) throws CertPathValidatorException { >> if(var1 instanceof X509Certificate && this.constraints != null) { >> X509CertImpl var3 = null; >> >> try { >> var3 = X509CertImpl.toImpl((X509Certificate)var1); >> } catch (CertificateException var15) { >> throw new CertPathValidatorException(var15); >> } >> >> PublicKey var4 = var3.getPublicKey(); >> String var5 = var3.getSigAlgName(); >> AlgorithmId var6 = null; >> >> try { >> var6 = (AlgorithmId)var3.get("x509.algorithm"); >> } catch (CertificateException var14) { >> throw new CertPathValidatorException(var14); >> } >> >> AlgorithmParameters var7 = var6.getParameters(); >> if(!this.constraints.permits(SIGNATURE_PRIMITIVE_SET, var5, var7)) { >> throw new CertPathValidatorException("Algorithm constraints check failed: " + var5, (Throwable)null, (CertPath)null, -1, BasicReason.ALGORITHM_CONSTRAINED); >> } else { >> .... >> >> The problem is that the sun.security.x509.X509CertImpl cannot >> convert the RSASSA-PSS algorithm OID to its friendly name when >> var3.getSigAlgName() is called: >> >> NOTE: In this case var1 is a instance >> of org.bouncycastle.jce.provider.X509CertificateObject >> >> In our tests, making this change results in a successful TLS >> connection without further changes: >> >> - Stringvar5 = var3.getSigAlgName(); >> + Stringvar5 = ((X509Certificate)var1).getSigAlgName(); > > We have just fixed this in JDK 9: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da > >> 2) Update sun.security.x509.AlgorithmId to properly map the RSASSA-PSS >> algorithm OID to its friendly name. We have not experimented with this >> option, but believe it would have the same outcome, but with more code >> to change. > > I think that's a more involved changes that will be addressed by > JDK-8146293. > > Thanks, > Sean From valerie.peng at oracle.com Fri Feb 17 21:20:44 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 17 Feb 2017 13:20:44 -0800 Subject: RFR 8006259: Test example vectors from NIST SP 800-38A In-Reply-To: References: <4ae41476-b0a7-629a-5527-5897db412372@oracle.com> Message-ID: Update looks good. Thanks, Valerie On 2/17/2017 8:18 AM, Adam Petcher wrote: > Fixed. Here is the new webrev: > http://cr.openjdk.java.net/~apetcher/8006259/webrev.01/ > > > On 2/16/2017 8:26 PM, Valerie Peng wrote: >> >> Changes look fine. >> Just a nit on code conventions, we normally use the style below: >> try { >> ... >> } catch (..) { >> ... >> } >> >> Can you update the test source to follow the same style? >> Thanks, >> Valerie >> >> On 2/7/2017 11:50 AM, Adam Petcher wrote: >>> This change adds a test which executes example vectors from NIST SP >>> 800-38A to check AES in various modes of operation. The test pulls >>> in all of the providers and runs the appropriate vectors for all >>> supported modes of operation on each provider. It passes on all >>> platforms on JPRT, and I confirmed that it exercises OracleUcrypto >>> and SunPKCS11 on Solaris. The CFB1 mode is included even though no >>> provider seems to support it at this time. >>> >>> http://cr.openjdk.java.net/~apetcher/8006259/webrev.00/ >>> >> > From reto.merz at abacus.ch Tue Feb 21 11:07:18 2017 From: reto.merz at abacus.ch (Reto Merz) Date: Tue, 21 Feb 2017 12:07:18 +0100 Subject: [jdk9] Webstart app is logging a SecurityException Message-ID: <2c444cbe-e758-4722-935a-daf9316c907c@abacus.ch> Hi, While we test our WebStart app with Java 9 we noticed that a SecurityException is silently logged to the Java Webstart Console: Exception in thread "Thread-13" java.lang.SecurityException: Sicherheitspaket-JAR-Datei kann nicht gepr?ft werden at jdk.deploy at 9-ea/com.sun.deploy.util.SecurityBaseline.verifyJar(Unknown Source) at jdk.deploy at 9-ea/com.sun.deploy.util.SecurityBaseline.access$200(Unknown Source) at jdk.deploy at 9-ea/com.sun.deploy.util.SecurityBaseline$1.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source) The app continues to work, we have not found any side effects yet. One conspicuous thing is that this is just logged after we call: java.util.logging.LogManager.getLogManager().readConfiguration(); I have not found any related open issue on https://bugs.openjdk.java.net All our JARs are signed and JNLP also request all-permissions. Tested with Java 9 b157 and Windows 7. The exception is not logged with Java 8 u121. Should we fill a report on bugreport.java.com for this ? Btw SecurityBaseline starts multiple threads, it would be great to give this threads a descriptive name. Thanks Reto From anthony.scarpino at oracle.com Wed Feb 22 19:29:48 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 22 Feb 2017 11:29:48 -0800 Subject: RFR 8175250: Manifest checking throws exception with no entry Message-ID: <34936ea8-cca1-78f8-4ce5-2377e78a9f40@oracle.com> Hi, I need a review of this small change that wasn't caught in normal testing of manifest entries. http://cr.openjdk.java.net/~ascarpino/8175250/webrev/ thanks Tony From sean.mullan at oracle.com Wed Feb 22 20:21:34 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 Feb 2017 15:21:34 -0500 Subject: RFR 8175250: Manifest checking throws exception with no entry In-Reply-To: <34936ea8-cca1-78f8-4ce5-2377e78a9f40@oracle.com> References: <34936ea8-cca1-78f8-4ce5-2377e78a9f40@oracle.com> Message-ID: Looks ok. I think another way to fix this is to set weakAlgs to false initially, and then only set it to true if permittedCheck returns false. You need a reason for the noreg label (i.e. noreg-{something}). --Sean On 2/22/17 2:29 PM, Anthony Scarpino wrote: > Hi, > > I need a review of this small change that wasn't caught in normal > testing of manifest entries. > > http://cr.openjdk.java.net/~ascarpino/8175250/webrev/ > > thanks > > Tony From sean.mullan at oracle.com Wed Feb 22 21:05:13 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 Feb 2017 16:05:13 -0500 Subject: RFR 8175250: Manifest checking throws exception with no entry In-Reply-To: References: <34936ea8-cca1-78f8-4ce5-2377e78a9f40@oracle.com> Message-ID: On 2/22/17 3:21 PM, Sean Mullan wrote: > Looks ok. I think another way to fix this is to set weakAlgs to false > initially, and then only set it to true if permittedCheck returns false. Never mind the comment above, this would not work because as long as you have one strong alg, it is ok. --Sean > > You need a reason for the noreg label (i.e. noreg-{something}). > > --Sean > > On 2/22/17 2:29 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this small change that wasn't caught in normal >> testing of manifest entries. >> >> http://cr.openjdk.java.net/~ascarpino/8175250/webrev/ >> >> thanks >> >> Tony From weijun.wang at oracle.com Thu Feb 23 03:42:28 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 23 Feb 2017 11:42:28 +0800 Subject: RFR 8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms In-Reply-To: <5ac4842f-a051-3280-8501-4b5f41a781c5@oracle.com> References: <46c26a65-7886-3a64-60f1-808ae07cd028@oracle.com> <32c222a8-18a1-14d6-7f32-13afd0aefae8@oracle.com> <5ac4842f-a051-3280-8501-4b5f41a781c5@oracle.com> Message-ID: <1665c445-931b-5f91-a8d6-c3c2202ed185@oracle.com> Updated again at http://cr.openjdk.java.net/~weijun/8171319/webrev.02/ Changes: 1. Combined printWeakWarningsWithoutNewLine() and printWeakWarnings() to one method. 2. New X509CRLImpl.toStringWithAlgName(String name). Nothing more. Thanks Max On 02/15/2017 11:04 PM, Se?n Coffey wrote: > Hi Weijun, > > That's looks good to me and will be a big help for keytool usability. > > some thoughts : > > Main.java : in your printCRL method, would you consider editing the > X509CRLImpl class to print with a customized string ? It'll make the > code more resilient to future changes in this area > > i.e. something like this in X509CRLImpl : > > public String toString() { printCRL(null); } > public String printCRL(String custom) { > // transfer the toString() code to here > // and allow for 'custom' string to be injected if non-null > .. > } > > in Main.java, I'd suggest an instanceof check for X509CRLImpl before > calling printCRL(..). Could X509CRL.getSigAlgName() then be used for > passing into the withWeak method call ? > > === > > Also in Main.java, maybe you could reduce > printWeakWarningsWithoutNewLine and printWeakWarnings() to one method - > e.g. printWeakWarnings(boolean newline) > > === > > Regards, > Sean. > > On 15/02/17 01:16, Weijun Wang wrote: >> Ping again. >> >> Also, must we resolve this one before ZBB? >> >> --Max >> >> On 02/09/2017 10:26 AM, Weijun Wang wrote: >>> An update webrev is at >>> >>> http://cr.openjdk.java.net/~weijun/8171319/webrev.01/ >>> >>> The major change is that every risk warning has a owner now, i.e. >>> instead of just saying "MD5withRSA is weak", it prints out whose >>> algorithm is weak. For example: >>> >>> The generated CRL uses the MD5withRSA signature algorithm which is >>> considered a security risk. >>> >>> Please take a look at the output of the newly added regression test at >>> >>> http://cr.openjdk.java.net/~weijun/8171319/webrev.01/examples.txt >>> >>> Thanks >>> Max >>> >>> On 01/23/2017 06:02 PM, Weijun Wang wrote: >>>> Hi All >>>> >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8171319/webrev.00/ >>>> >>>> Warnings are printed to System.err when weak algorithms/keysizes are >>>> detected during the execution, this includes input, output, and any >>>> certs used. >>>> >>>> The detection applies to many keytool functions: >>>> >>>> - generation of certificate, certificate request, CRL >>>> - reading (printing, listing, exporting) of above >>>> - importing of certificate or certificates reply >>>> >>>> The behavior of most functions remains unchanged. The only exception is >>>> "keytool -importcert", where the user must reply to a prompt if weak >>>> algorithms/keysizes are detected, unless -noprompt is specified on the >>>> command line. >>>> >>>> Warnings are either printed at the end, or before a prompt. >>>> >>>> If there are multiple weak points, multiple warnings will be printed. >>>> >>>> The detection is based on the security property >>>> jdk.certpath.disabledAlgorithms. >>>> >>>> For example: >>>> >>>> $ keytool -genkeypair -alias a -dname CN=a -keyalg RSA -sigalg >>>> MD5withRSA >>>> >>>> Warning: >>>> The MD5withRSA signature algorithm is considered a security risk. >>>> >>>> $ keytool -keystore ks -storepass changeit -keypass changeit -list >>>> >>>> Keystore type: JKS >>>> Keystore provider: SUN >>>> >>>> Your keystore contains 3 entries >>>> >>>> b, Jan 23, 2017, PrivateKeyEntry, >>>> Certificate fingerprint (SHA-256): >>>> D8:46:B7:0B:8B:97:C2:DE:A2:17:62:01:27:82:2B:CE:B1:9B:12:0B:24:D5:47:BF:BD:54:EE:8A:71:29:2B:CE >>>> >>>> >>>> >>>> a, Jan 23, 2017, PrivateKeyEntry, >>>> Certificate fingerprint (SHA-256): >>>> 66:70:DF:11:14:A1:96:58:92:F5:6A:10:09:B1:2F:CC:1C:CC:2D:55:47:1D:EE:74:75:AA:26:63:E4:9D:EA:83 >>>> >>>> >>>> >>>> >>>> Warning: >>>> 's 512-bit RSA key is considered a security risk. >>>> 's MD5withRSA signature algorithm is considered a security risk. >>>> >>>> $ keytool -importcert -alias a -file b+a.certs >>>> >>>> Warning: >>>> Reply #2 of 2's 512-bit RSA key is considered a security risk. >>>> >>>> Install reply anyway? [no]:no >>>> Certificate reply was not installed in keystore >>>> >>>> Thanks >>>> Max > From sean.coffey at oracle.com Thu Feb 23 13:55:54 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 23 Feb 2017 13:55:54 +0000 Subject: RFR 8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms In-Reply-To: <1665c445-931b-5f91-a8d6-c3c2202ed185@oracle.com> References: <46c26a65-7886-3a64-60f1-808ae07cd028@oracle.com> <32c222a8-18a1-14d6-7f32-13afd0aefae8@oracle.com> <5ac4842f-a051-3280-8501-4b5f41a781c5@oracle.com> <1665c445-931b-5f91-a8d6-c3c2202ed185@oracle.com> Message-ID: Looks fine to me Max. regards, Sean. On 23/02/2017 03:42, Weijun Wang wrote: > Updated again at > > http://cr.openjdk.java.net/~weijun/8171319/webrev.02/ > > Changes: > > 1. Combined printWeakWarningsWithoutNewLine() and printWeakWarnings() > to one method. > > 2. New X509CRLImpl.toStringWithAlgName(String name). > > Nothing more. > > Thanks > Max > > On 02/15/2017 11:04 PM, Se?n Coffey wrote: >> Hi Weijun, >> >> That's looks good to me and will be a big help for keytool usability. >> >> some thoughts : >> >> Main.java : in your printCRL method, would you consider editing the >> X509CRLImpl class to print with a customized string ? It'll make the >> code more resilient to future changes in this area >> >> i.e. something like this in X509CRLImpl : >> >> public String toString() { printCRL(null); } >> public String printCRL(String custom) { >> // transfer the toString() code to here >> // and allow for 'custom' string to be injected if non-null >> .. >> } >> >> in Main.java, I'd suggest an instanceof check for X509CRLImpl before >> calling printCRL(..). Could X509CRL.getSigAlgName() then be used for >> passing into the withWeak method call ? >> >> === >> >> Also in Main.java, maybe you could reduce >> printWeakWarningsWithoutNewLine and printWeakWarnings() to one method - >> e.g. printWeakWarnings(boolean newline) >> >> === >> >> Regards, >> Sean. >> >> On 15/02/17 01:16, Weijun Wang wrote: >>> Ping again. >>> >>> Also, must we resolve this one before ZBB? >>> >>> --Max >>> >>> On 02/09/2017 10:26 AM, Weijun Wang wrote: >>>> An update webrev is at >>>> >>>> http://cr.openjdk.java.net/~weijun/8171319/webrev.01/ >>>> >>>> The major change is that every risk warning has a owner now, i.e. >>>> instead of just saying "MD5withRSA is weak", it prints out whose >>>> algorithm is weak. For example: >>>> >>>> The generated CRL uses the MD5withRSA signature algorithm which is >>>> considered a security risk. >>>> >>>> Please take a look at the output of the newly added regression test at >>>> >>>> http://cr.openjdk.java.net/~weijun/8171319/webrev.01/examples.txt >>>> >>>> Thanks >>>> Max >>>> >>>> On 01/23/2017 06:02 PM, Weijun Wang wrote: >>>>> Hi All >>>>> >>>>> Please take a review at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8171319/webrev.00/ >>>>> >>>>> Warnings are printed to System.err when weak algorithms/keysizes are >>>>> detected during the execution, this includes input, output, and any >>>>> certs used. >>>>> >>>>> The detection applies to many keytool functions: >>>>> >>>>> - generation of certificate, certificate request, CRL >>>>> - reading (printing, listing, exporting) of above >>>>> - importing of certificate or certificates reply >>>>> >>>>> The behavior of most functions remains unchanged. The only >>>>> exception is >>>>> "keytool -importcert", where the user must reply to a prompt if weak >>>>> algorithms/keysizes are detected, unless -noprompt is specified on >>>>> the >>>>> command line. >>>>> >>>>> Warnings are either printed at the end, or before a prompt. >>>>> >>>>> If there are multiple weak points, multiple warnings will be printed. >>>>> >>>>> The detection is based on the security property >>>>> jdk.certpath.disabledAlgorithms. >>>>> >>>>> For example: >>>>> >>>>> $ keytool -genkeypair -alias a -dname CN=a -keyalg RSA -sigalg >>>>> MD5withRSA >>>>> >>>>> Warning: >>>>> The MD5withRSA signature algorithm is considered a security risk. >>>>> >>>>> $ keytool -keystore ks -storepass changeit -keypass changeit -list >>>>> >>>>> Keystore type: JKS >>>>> Keystore provider: SUN >>>>> >>>>> Your keystore contains 3 entries >>>>> >>>>> b, Jan 23, 2017, PrivateKeyEntry, >>>>> Certificate fingerprint (SHA-256): >>>>> D8:46:B7:0B:8B:97:C2:DE:A2:17:62:01:27:82:2B:CE:B1:9B:12:0B:24:D5:47:BF:BD:54:EE:8A:71:29:2B:CE >>>>> >>>>> >>>>> >>>>> >>>>> a, Jan 23, 2017, PrivateKeyEntry, >>>>> Certificate fingerprint (SHA-256): >>>>> 66:70:DF:11:14:A1:96:58:92:F5:6A:10:09:B1:2F:CC:1C:CC:2D:55:47:1D:EE:74:75:AA:26:63:E4:9D:EA:83 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Warning: >>>>> 's 512-bit RSA key is considered a security risk. >>>>> 's MD5withRSA signature algorithm is considered a security risk. >>>>> >>>>> $ keytool -importcert -alias a -file b+a.certs >>>>> >>>>> Warning: >>>>> Reply #2 of 2's 512-bit RSA key is considered a security risk. >>>>> >>>>> Install reply anyway? [no]:no >>>>> Certificate reply was not installed in keystore >>>>> >>>>> Thanks >>>>> Max >>