JDK-8060719 : TrustDecider.checkMainJarManifest will fail for fx app with embedded certificate.
- Type: Bug
- Component: deploy
- Sub-Component: javafx
- Affected Version: 8u20,9
- Priority: P2
- Status: Closed
- Resolution: Fixed
- Submitted: 2014-10-15
- Updated: 2015-06-03
- Resolved: 2014-10-21
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.
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 |
|---|---|
8u40 b12Fixed  |
9Fixed |
Description
The packager generates a jnlp file with:
<jfx:details>
<jfx:certificate-path> ...
</jfx:certificate-path>
</jfx:details>
in this case, the certificate is pre-verified (while the jars are downloaded) using a CodeSource that has this certificate but a location based on the jnlp file.
The code in TrustDecider.checkMainJarManifest() assumes the CodeSource refers to a jar, and tries to open that jar to see if it has the main class, and if so if it has a permission manifest attribute.
When the exception is caught from :
new JarFile(ResourceProvider.get().getCachedResourceFilePath(cs.getLocation(), ver), false);
a SecurityException is thrown, and the app is blocked for not having a permissions attribute.
We need to recognize this situation and not block
Comments
|