[
https://issues.apache.org/jira/browse/PIVOT-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634631#comment-14634631
]
Karel Hübl commented on PIVOT-965:
----------------------------------
Hi Roger,
I experimented with Trusted-only and Trusted-library but also with no suceess.
I also tested with Application-Library-Allowable-Codebase and
Caller-Allowable-Codebase, but it had no effect. I think this attributes should
affect interaction between javascript code in HTML page and RIA.
What I am experiencing looks like this (from
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#caller_allowable):
If the Caller-Allowable-Codebase attribute is not present, calls from
JavaScript code to your RIA show a security warning, and users have the choice
to allow the call or block the call. For unsigned RIAs, JavaScript code that
requires access to the RIA must be in the same location as the main JAR file
for your RIA, otherwise, the user is prompted to allow access. Security prompts
are shown for each Applet classLoader instance.
But even when I used Caller-Allowable-Codebase: * and
Application-Library-Allowable-Codebase: * the behaviour was the same. And for
me, it does not explain, why when I ship rhino libraries signed with the same
certificate as application it works without security warnings. My only
explanation is, that java considers all calls initiated from Nashorn script
engine shipped with JRE as untrusted. However I am not sure about this and I
have no idea how to deal with this issue if it is true...
I believe, maximum what can I do in manifest is this (which is still not
sufficient):
Manifest-Version: 1.0
Application-Name: jnlpScripting
Permissions: all-permissions
Codebase: *
Caller-Allowable-Codebase: *
Application-Library-Allowable-Codebase: *
Trusted-Library: true
Main-Class: org.kh.jnlpScripting.Main
> Java 8 BXML scripting security issues in Apache Pivot RIAs
> ----------------------------------------------------------
>
> Key: PIVOT-965
> URL: https://issues.apache.org/jira/browse/PIVOT-965
> Project: Pivot
> Issue Type: Bug
> Components: core-serialization
> Affects Versions: 2.0.4
> Environment: Windows, Sun JRE 64-bit 1.8.0_31b13
> Reporter: Karel Hübl
> Assignee: Sandro Martini
> Labels: java8, jdk8
> Fix For: 2.1, 2.0.5
>
>
> We encounter security issues in our pivot application after upgrading to JRE
> 1.8. The application is deployed as RIA using Java Web Start.
> I found out, that the problem is connected with nashorn script engine which
> replaced rhino script engine from previous java version. BXMLSerializer is
> using ScriptEngine to evaluate scripts in BXML files. It seems, that all
> calls initiated from BXML scripts, are considered untrusted in JRE 1.8 RIA
> Environment - this means security dialogs and exceptions are thrown, when
> trying execute privileged actions (network communication, reflection ...).
> Currently, I am not sure, if this is Pivot or Nashorn bug, but it is problem
> for current Apache Pivot RIAs. To investigate the srcipting behaviour in
> RIAs, I created testing non Pivot project
> https://github.com/kaja78/jnlpScripting The project contains testing
> application, which is deployed as JWS. When you execute the java web start
> app in JRE 1.8, the security dialog is displayed when testing method is
> executed from nashorn script engine (if you press cancel button on security
> dialog, you get SecurityException). When you uncomment 2 lines in
> Webcontent/jnlpScripting.jnlp file, rhino script engine is used instead of
> nashorn and no security dialog is displayed. This fix works also for our
> Pivot RIAs.
> I believe, Pivot should work in JRE 1.8 RIA Environment without security
> issues by default, so it should be fixed somehow in Pivot - may be, by
> correct ScriptEngine configuration in BXMLSerializer or by including Rhino
> libraries in Pivot distribution. Any idea how to "correctly" fix this issue?
> Btw.: I found this bug: http://bugs.java.com/view_bug.do?bug_id=8045075 I am
> not sure, if it is the same problem. But anyway, it should be fixed in
> 1.8.25.b01 and we are encountering above issues in latest 1.8.0.31.b13.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
