Details
-
Enhancement
-
Resolution: Fixed
-
P4
-
8u40
Description
I bumped the case of an FX WebStart app failing at start with a security dialog saying "missing Permissions attribute in JAR manifest" and once you hit OK button it exits; but if you start it a second time then it starts up fine.
My app is asking for all-permissions and I was using cachecertificates="false" in fx:permissions.
I discussed this with Andy Herrick and below is his answer:
"The feature of putting the certificate into the jnlp file as a hint was an optimization devised by Igor and Thomas so the warmup validator could show the certificate dialog before even the first jar was downloaded. It does get you to the TrustDeciderDialog quicker, helping perceived performance, but the cost in secondary launch performance, complexity, and opportunity for security vulnerabilities is greater than its benefits (IMHO)
I would suggest we remove generating it from the packager, and even remove processing it from our code.
The reason it is causing this bug, which will not be limited to drs tool, is the changes I made in TrustDecider to check if the jar being verified is the main jar (contains the main jar) assume a jar is veing verified. In the case of WarmupValidator checking the permissions for the certificate base64 encoded into the jnlp file, it is not a jar at all, but the jnlp file, so looking at it as a jar creates the zip exception which in turns causes the "no main jar permissions attribute exception"
This is just another case of "too many ways to do the same thing" causing us to not test every case when making a change.
we could leave this functionality in place, and it will not be difficult to fix the trust decider to take this into account, but as I said, I never liked this feature and think we may want to remove it entirely."
My app is asking for all-permissions and I was using cachecertificates="false" in fx:permissions.
I discussed this with Andy Herrick and below is his answer:
"The feature of putting the certificate into the jnlp file as a hint was an optimization devised by Igor and Thomas so the warmup validator could show the certificate dialog before even the first jar was downloaded. It does get you to the TrustDeciderDialog quicker, helping perceived performance, but the cost in secondary launch performance, complexity, and opportunity for security vulnerabilities is greater than its benefits (IMHO)
I would suggest we remove generating it from the packager, and even remove processing it from our code.
The reason it is causing this bug, which will not be limited to drs tool, is the changes I made in TrustDecider to check if the jar being verified is the main jar (contains the main jar) assume a jar is veing verified. In the case of WarmupValidator checking the permissions for the certificate base64 encoded into the jnlp file, it is not a jar at all, but the jnlp file, so looking at it as a jar creates the zip exception which in turns causes the "no main jar permissions attribute exception"
This is just another case of "too many ways to do the same thing" causing us to not test every case when making a change.
we could leave this functionality in place, and it will not be difficult to fix the trust decider to take this into account, but as I said, I never liked this feature and think we may want to remove it entirely."
Attachments
Issue Links
- relates to
-
JDK-8095978 javafxpackager deploy task: -embedCertificates option is not working
-
- Resolved
-