JDK-8187993 : [CPU17_04] Need to update securitypack.jar with baseline.versions file having jdk9 entry
  • Type: Bug
  • Component: infrastructure
  • Affected Version: 9.0.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-09-27
  • Updated: 2018-02-07
  • Resolved: 2017-09-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u161Fixed 9.0.1Fixed
Description
Need to update securitypack.jar with baseline.versions file having jdk9(9.0.1) entry

Currently staged securitypack doesn't have baseline.versions file with jdk9 entry
https://java.se.oracle.com/artifactory/re-virtual/jdk/8u151/b12/bundles/windows-i586/securitypack.jar
https://javadl-esd-secure.oracle.com/update/security/securitypack.jar
Comments
Verified.
06-10-2017

For documentation purposes, updated file staged here: https://javadl-esd-secure.oracle.com/update/security/securitypack.jar
02-10-2017

Sorry about that. Attaching a signed version to this bug.
02-10-2017

The staged file is still unsigned: ---------- trace output after setting property: deployment.baseline.url=https\://javadl-esd-secure.oracle.com/update/security/securitypack.jar -------------------------: network: Connecting https://javadl-esd-secure.oracle.com/update/security/securitypack.jar with cookie "ORASSO_AUTH_HINT=v1.0~20170614022930" network: Updating file at: C:\Users\aherrick.ORADEV\AppData\LocalLow\Sun\Java\Deployment\security\securitypack.jar from url: https://javadl-esd-secure.oracle.com/update/security/securitypack.jar security: Canot validate certificate - unsigned security: Verification failed for signed security pack file C:\Users\aherrick.ORADEV\AppData\LocalLow\Sun\Java\Deployment\security\securitypack.jar Exception in thread "Thread-7" java.lang.SecurityException: Can not verify security pack jar at jdk.deploy@10-internal/com.sun.deploy.util.SecurityBaseline.verifyJar(SecurityBaseline.java:430) at jdk.deploy@10-internal/com.sun.deploy.util.SecurityBaseline.access$200(SecurityBaseline.java:44) at jdk.deploy@10-internal/com.sun.deploy.util.SecurityBaseline$1.run(SecurityBaseline.java:302) at java.base/java.lang.Thread.run(Thread.java:844) ------------------------------------------------------
29-09-2017

Thank you Erik! securitypack.jar is now updated and re-staged: https://javadl-esd-secure.oracle.com/update/security/securitypack.jar
29-09-2017

The jar attached to JDK-8188049 and the one copied to https://java.se.oracle.com/artifactory/re-release-local/jdk/9.0.1/11/bundles/windows-x86/securitypack.jar are unsigned.
29-09-2017

A valid securitypack.jar for 9.0.1 has been delivered. A way of producing it for future CPUs has been implemented.
29-09-2017

Sounds reasonable. The securitypack.jar was attached to JDK-8188049, sorry for the confusion.
29-09-2017

crucible review: https://java.se.oracle.com/code/cru/CR-JDK8UCPU-487
28-09-2017

When 9 is EOL'd, it's security baseline should be set to something later than the last release, so no version will be secure. Since that will happen before JDK8 is EOL'd I have proposed we fix this in 8u, and later take these files from 8u (since there will be no 9 in CPU_18_02 to take it from).
28-09-2017

What happens when JDK 9 is EOL. Should the securitypack.jar still list the last version of 9 indefinitely even if it is no longer secure? Note that I have a fixed JDK-8188049 in 9/cpu so at least next CPU will get a securitypack.jar published from the promotion builds of 9.0.x. I have also attached a securitypack.jar built from latest 9.0.1 that should serve fine for the 9.0.1 release, unless a new build is requested, in which case the fix for JDK-8188049 could be pulled into 9.0.1 which would make the new build publish securitypack.jar. Also note that in 9 updates, we do indeed specify the baselines in the deploy makefiles rather than rely on RE specifying them in the re3 src repository, so each CPU will need to update those.
28-09-2017

OK - I can confirm that making this change will cause baseline.versions to be generated with a value for 9. however, by default, the values are: 1.4.2_99 1.5.0_99 1.6.0_99 1.7.0_99 1.8.0_99 1.9.0 which of course is all wrong, so it depends on the variables passed in by the RE script that generates the build. these values are in deploy/make/common/Defs-BaselineVersions.gmk The script used in https://java.se.oracle.com/artifactory/re-release-local/jdk/8u151/b12/config/build-scripts.zip shows that the following was used: SECURITY_BASELINE_180=1.8.0_151 SECURITY_BASELINE_170=1.7.0_161 SECURITY_BASELINE_160=1.6.0_171 SECURITY_BASELINE_150=1.5.0_99 SECURITY_BASELINE_142=1.4.2_43 export SECURITY_BASELINE_180 SECURITY_BASELINE_170 SECURITY_BASELINE_160 SECURITY_BASELINE_150 SECURITY_BASELINE_142 so we would also need that script changes to say: SECURITY_BASELINE_190=9.0.1 SECURITY_BASELINE_180=1.8.0_151 SECURITY_BASELINE_170=1.7.0_161 SECURITY_BASELINE_160=1.6.0_171 SECURITY_BASELINE_150=1.5.0_99 SECURITY_BASELINE_142=1.4.2_43 export SECURITY_BASELINE_190 SECURITY_BASELINE_180 SECURITY_BASELINE_170 SECURITY_BASELINE_160 SECURITY_BASELINE_150 SECURITY_BASELINE_142 (alternatively, we could change the default in deploy/make/common/Defs-BaselineVersions.gmk from ifndef SECURITY_BASELINE_190 SECURITY_BASELINE_190=1.9.0 endif #SECURITY_BASELINE_190 to: ifndef SECURITY_BASELINE_190 SECURITY_BASELINE_190=9.0.1 endif #SECURITY_BASELINE_190 but that would only help this release, and we would then have the same problem [need to change script] in 9.0.4)
28-09-2017

normally - securitypack.jar and baseline.versions would be staged from the latest major release in the CPU. now that would mean JDK9 (9.0.1) but: 1.) there is no securitypack.jar present from the latest 9.0.1 promotion (https://java.se.oracle.com/artifactory/re-release-local/jdk/9.0.1/9/) 2.) moving forward, JDK9 will not be the longest running version, and JDK10 (18.3) will not have deploy in it, so it may make more sense to continue staging these files from the JDK8 update in the CPU. 3.) currently, JDK8-CPU build for CPU17_04 (8u151) contains no baseline information for JDK9, it just has: 1.4.2_43 1.5.0_99 1.6.0_171 1.7.0_161 1.8.0_151 This is because the file deploy/make/ant/Release.build.xml in jdk8u-cpu has: -------------------------------------------------------------------------------- <!-- Prepare securitypack.jar --> <target name="prepare-securitypack"> <delete dir="${dir.securitypack.tmp}" /> <!-- Copy blacklist for jars from JDK repository --> <copy file="${basedir}/../jdk/src/closed/share/lib/security/blacklist" tofile="${dir.securitypack.tmp}/blacklist.dynamic"/> <!-- Copy blacklist for certificates from JDK repository --> <copy file="${basedir}/../jdk/src/share/lib/security/blacklisted.certs" tofile="${dir.securitypack.tmp}/blacklisted.certs"/> <!-- Create baseline.versions --> <echo message="${ws.security.baseline.142}${line.separator}" file="${dir.securitypack.tmp}/baseline.versions" append="true"/> <echo message="${ws.security.baseline.150}${line.separator}" file="${dir.securitypack.tmp}/baseline.versions" append="true"/> <echo message="${ws.security.baseline.160}${line.separator}" file="${dir.securitypack.tmp}/baseline.versions" append="true"/> <echo message="${ws.security.baseline.170}${line.separator}" file="${dir.securitypack.tmp}/baseline.versions" append="true"/> <echo message="${ws.security.baseline.180}${line.separator}" file="${dir.securitypack.tmp}/baseline.versions" append="true"/> <jar basedir="${dir.securitypack.tmp}" destfile="${dir.securitypack.tmp}/securitypack.jar"/> </target> ---------------------------------------------------------------------------------------- notice it is missing: <echo message="${ws.security.baseline.190}${line.separator}" file="${dir.securitypack.tmp}/baseline.versions" append="true"/>
28-09-2017

Please investigate from Install perspective..
27-09-2017

JDK-8188049 has been logged to report issues of securitypack.jar not available in 9.0.1 build.
27-09-2017

[~svijayasekar]] Yes we need to add an entry for jdk9 and it should be 9.0.1 as the same version is getting released with Oct 17 CPU.
27-09-2017

There had been no entries for 9 in the baseline.versions file packaged inside the JDK8uX securitypack.jar files even in the past. Why are we looking for the entry for 9 now inside the 8uX securitypack.jar ? Is this a new requirement? Please clarify. 8u144-b01: ======== [java_re@sca00cmg JDK-8187993]$ cd 8u144-b01/ [java_re@sca00cmg 8u144-b01]$ wget http://java.se.oracle.com/artifactory/re-virtual/jdk/8u144/b01/bundles/windows-i586/securitypack.jar --2017-09-27 02:43:16-- http://java.se.oracle.com/artifactory/re-virtual/jdk/8u144/b01/bundles/windows-i586/securitypack.jar Resolving java.se.oracle.com... 10.133.184.74 Connecting to java.se.oracle.com|10.133.184.74|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 9115 (8.9K) [application/java-archive] Saving to: `securitypack.jar' 100%[==================================================================================================================================>] 9,115 --.-K/s in 0s 2017-09-27 02:43:16 (200 MB/s) - `securitypack.jar' saved [9115/9115] [java_re@sca00cmg 8u144-b01]$ ls securitypack.jar [java_re@sca00cmg 8u144-b01]$ jar xvf securitypack.jar inflated: META-INF/MANIFEST.MF inflated: META-INF/ORACLE_C.SF inflated: META-INF/ORACLE_C.RSA created: META-INF/ inflated: baseline.versions inflated: blacklist.dynamic inflated: blacklisted.certs [java_re@sca00cmg 8u144-b01]$ cat baseline.versions 1.4.2_43 1.5.0_99 1.6.0_161 1.7.0_151 1.8.0_141 [java_re@sca00cmg 8u144-b01]$ 8u131-b11: ======== [java_re@sca00cmg 8u144-b01]$ cd ../8u131-b11/ [java_re@sca00cmg 8u131-b11]$ wget http://java.se.oracle.com/artifactory/re-virtual/jdk/8u131/b11/bundles/windows-i586/securitypack.jar --2017-09-27 02:43:43-- http://java.se.oracle.com/artifactory/re-virtual/jdk/8u131/b11/bundles/windows-i586/securitypack.jar Resolving java.se.oracle.com... 10.133.184.74 Connecting to java.se.oracle.com|10.133.184.74|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 9107 (8.9K) [application/java-archive] Saving to: `securitypack.jar' 100%[==================================================================================================================================>] 9,107 --.-K/s in 0s 2017-09-27 02:43:43 (174 MB/s) - `securitypack.jar' saved [9107/9107] [java_re@sca00cmg 8u131-b11]$ ls securitypack.jar [java_re@sca00cmg 8u131-b11]$ jar xvf securitypack.jar inflated: META-INF/MANIFEST.MF inflated: META-INF/ORACLE_C.SF inflated: META-INF/ORACLE_C.RSA created: META-INF/ inflated: baseline.versions inflated: blacklist.dynamic inflated: blacklisted.certs [java_re@sca00cmg 8u131-b11]$ cat baseline.versions 1.4.2_43 1.5.0_99 1.6.0_151 1.7.0_141 1.8.0_131 [java_re@sca00cmg 8u131-b11]$
27-09-2017

[~ddamodaran] I could see the entry for 9 present in the baseline.versions file placed inside the http://java.se.oracle.com/artifactory/re-virtual/jdk/9/181/bundles/windows-x86/securitypack.jar file: [java_re@sca00cmg 9-181]$ wget http://java.se.oracle.com/artifactory/re-virtual/jdk/9/181/bundles/windows-x86/securitypack.jar --2017-09-27 02:37:11-- http://java.se.oracle.com/artifactory/re-virtual/jdk/9/181/bundles/windows-x86/securitypack.jar Resolving java.se.oracle.com... 10.133.184.74 Connecting to java.se.oracle.com|10.133.184.74|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 9109 (8.9K) [application/java-archive] Saving to: `securitypack.jar' 100%[==================================================================================================================================>] 9,109 --.-K/s in 0s 2017-09-27 02:37:11 (183 MB/s) - `securitypack.jar' saved [9109/9109] [java_re@sca00cmg 9-181]$ ls securitypack.jar [java_re@sca00cmg 9-181]$ jar xvf securitypack.jar inflated: META-INF/MANIFEST.MF inflated: META-INF/ORACLE_C.SF inflated: META-INF/ORACLE_C.RSA created: META-INF/ inflated: baseline.versions inflated: blacklist.dynamic inflated: blacklisted.certs [java_re@sca00cmg 9-181]$ cat baseline.versions 1.4.2_43 1.5.0_99 1.6.0_161 1.7.0_151 1.8.0_141 9 [java_re@sca00cmg 9-181]$ I think we are good there.
27-09-2017