[
https://issues.apache.org/jira/browse/FELIX-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019672#comment-14019672
]
Rob Walker commented on FELIX-4281:
-----------------------------------
Patch does work Karl, thanks. There are some adaptations needed (noted below)
... guess it goes to prove that I don't understand how the ExtensionManager
code works or rather what it clashes with in a JNLP!
If we assume people will only ever use Felix embedded, the mod will work
provided they use setProperty to force this property set before launching
Felix. But if we want to allow that new property in a JNLP file, we also need
to support the required syntax which is that properties in there must be
prefixed "jnlp." to be accessible as System properties e.g.
{noformat}
<resources>
...
<property name="jnlp.felix.extensions.disable" value="true"/>
</resources>
{noformat}
I've attached a patch with one implementation approach for this - a mod to
SecureAction to check for a "jnlp," version of a property before falling back
to System properties or the supplied default.
An alternative would be additional init code in Felix or FelixConstants to test
each property that we wish to expose to JNLP files and push any non-null value
into System properties. This would be more transparent, but also more
maintenance whenever new FelixConstants are added.
An observations I found along the way was that you can launch javaws from the
command line with a -silent option. This bypasses the dialog box much like
-verbose / -noWebJava but without any other prompting. I don't think this helps
much at this stage, but it definitely shows there is some inner switch that the
lower code is testing before putting up the dialog.
I'm still troubled that I don't understand exactly what happens lower down in
the JNLP classes/classloaders to cause it to decide to put up a blocking dialog
rather than just throwing a CNFE. So I may carry on digging to see if I can
figure it out for myself. I'd like to believe there may be some other more
seamless solution in terms of combinations of attributes, signing and/or built
in code checks. We could definitely detect the presence of a JNLP class loader
- trouble there is that it's a com.sun class, and hence implementation
dependent. It could differ in other Java implementations I guess.
> Security Warning: Felix with Java Web Start
> -------------------------------------------
>
> Key: FELIX-4281
> URL: https://issues.apache.org/jira/browse/FELIX-4281
> Project: Felix
> Issue Type: Bug
> Environment: Windows 7 with Java 7 update 40, 64 bits
> Reporter: Cesar Souza
> Assignee: Karl Pauls
> Priority: Minor
> Attachments: message.zip, sec_action.patch, viewer.jnlp,
> webstart.patch
>
>
> Since the release of Java 7 update 40 the following warning occurs when you
> try to execute a signed (with valid certificate) Java Web Start application:
> -----------------------------
> Security Warning
> Do you want to run this application?
> An unsigned application from the location below is requesting permission to
> run.
> http://......
> Running unsigned applications like this will be blocked in a future
> release because it is potentially unsafe and a security risk
> -----------------------------
> Although the Java recognizes the certificate in the first dialog, it shows
> the warning message when the Felix's init method is invoked.
> I have tested a same application over Java 7 update 21 and everything is ok.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
