-
Bug
-
Resolution: Fixed
-
P3
-
8u161
-
b01
-
x86
-
other
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8212346 | 8u202 | Andy Herrick | P3 | Resolved | Fixed | b01 |
JDK-8207649 | 8u192 | Andy Herrick | P3 | Resolved | Fixed | b02 |
JDK-8202211 | 8u181 | Andy Herrick | P3 | Resolved | Fixed | b04 |
JDK-8211573 | emb-8u191 | Andy Herrick | P3 | Resolved | Fixed | master |
JDK-8203073 | emb-8u181 | Andy Herrick | P3 | Resolved | Fixed | b04 |
build 1.8.0_161
ADDITIONAL OS VERSION INFORMATION :
Windows 10
A DESCRIPTION OF THE PROBLEM :
When using the <property name="jnlp.versionEnabled" value="true"/> in a JNLP file with the following naming convention <JAR file name>__V<version number>.jar for binaries, application fails to launch for security reason if JAR files are autosigned.
@see https://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/avoidingUnnecessaryUpdateChecks.html
This is always true unless using a specific deployment rule. Indeed, a way for enterprises to continue using JavaWebStart legacy business applications in their environment is to use the Deployment Rule Set feature.
@see https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/deployment_rules.html
Unfortunately the version-based download protocol passes through the security check implemented with this Deployment Rule Set feature.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
A formal DeploymentRuleSet.jar file must be set and properly signed with a valid certificate from a trusted authority
JAR files referenced in the JNLP sample must be signed with a non valid certificate but defined in the ruleSet.xml
Disable temporary files in general JAVA settings
The JAR files repository must not support the classical version-based download protocol like when using a JnlpDownloadServlet
@see https://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/downloadservletguide.html
Instead add <property name="jnlp.versionEnabled" value="true"/> in JNLP file and use the following naming convention <JAR file name>__V<version number>.jar with files in the repository
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Application should launch normally
ACTUAL -
Application is bloqued by a java security dialog
Note :
When sniffing TCP request one can see a 6 times try request with URL http://<site>/<main_jar_href>.jar&version-id=<version_value> for the main jar download
following by http://<site>/<main_jar_href>__V<version_value>.jar
The first 6 times failure looks normal when download protocol with query parameter &version-id is not handled by the repository server (tomcat jetty etc...)
But the last request with version naming convention in the URL should have been called instead when using <property name="jnlp.versionEnabled" value="true"/>
Strangely, this is what happened for all other JAR download request but the main one. It starts trying download with URL like <JAR file name>__V<version number>.jar, then try with the casual &version-id query parameter one.
Unfortunately it passes through the security check implemented with this Deployment Rule Set feature.
It behaves normally when a valid certificate is used because a specific RuleSet is not required.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
If temporary file is enable in JAVA settings the failure occurs only once, then application can be launched normally. It sounds logical since there is no need to perform update check with up-to-date files stored in cache.
Another workaround is to use a JnlpDownloadServlet like to deal with the classical version-based dowload protocol.
- backported by
-
JDK-8202211 Security check failure for main jar downlaod with jnlp.versionEnabled and Deployment Rule Set feature
- Resolved
-
JDK-8203073 Security check failure for main jar downlaod with jnlp.versionEnabled and Deployment Rule Set feature
- Resolved
-
JDK-8207649 Security check failure for main jar downlaod with jnlp.versionEnabled and Deployment Rule Set feature
- Resolved
-
JDK-8211573 Security check failure for main jar downlaod with jnlp.versionEnabled and Deployment Rule Set feature
- Resolved
-
JDK-8212346 Security check failure for main jar downlaod with jnlp.versionEnabled and Deployment Rule Set feature
- Resolved