JNLP aggregation leads to a missing attribute permission warning

mazze5 commented 4 years ago

OS: Windows10 OpenWebstart: 1.0.0

Using JNLP aggregation leads to a warning dialog "... missing attribute 'permission'...".

The main JNLP looks like this:

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="http://my-codebase/">
  <information>
    <title>OpenWebstart-Test</title>
    <vendor>Me</vendor>
    <homepage href="index.html"/>
  </information>
  <update check="always"/>
  <resources>
    <java version="1.8" java-vm-args="-Xms512m -Xmx1024m"/>
    <extension name="Components" href="my-components.jnlp"/>
  </resources>
  <security><all-permissions/></security>
  <application-desc main-class="me.MainClass">
  </application-desc>
</jnlp>

And the my-components.jnlp looks like this:

<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="">
    <information>
        <title>Components</title>
        <vendor>Me</vendor>
    </information>
    <update check="always"/>
    <resources>
        <jar href="lib/my-app.jar" main="true"/>
    </resources>
    <security>
        <all-permissions/>
    </security>
    <component-desc/>
</jnlp>

Is this issue known? With Webstart from Oracle this works for me like expected, without a warning.

The resource "my-app.jar" has the right MANIFEST.MF included with permissions and codebase attributes. It works fine without a warning dialog if I use the jar element in the main JNLP instead of the extension element with the components JNLP.

sclassen commented 4 years ago

Could you provide the application for us to reproduce the error?

mazze5 commented 4 years ago

Since OpenWebstart 1.1.0 the behaviour has changed. Now I get an the following initialization Error:

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
    at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:593)
    at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:370)
    at net.sourceforge.jnlp.Launcher.access$200(Launcher.java:69)
    at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:661)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: The JNLP application is not fully signed by a single cert. The JNLP application has its components individually signed, however there must be a common signer to all entries.
    at net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.getClassLoaderSecurity(JNLPClassLoader.java:2218)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:385)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:674)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:348)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:421)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:493)
    at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:466)
    at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:585)
    ... 3 more

I have created a small test in the following zip, so that you can reproduce.

Some notes to the test application: I use the DynamicTreeDemo from Oracle: https://docs.oracle.com/javase/tutorial/deployment/webstart/examplesIndex.html

In the zip you find two JNLPs to start the application and you have to change the codebase in this JNLPs to test it:

start.jnlp: This version works, the application starts. But there is no aggregation in the jnlp
start-aggregate.jnlp: This verions fails. In the JNLP is the aggregation included.

openwebstart-component-test.zip

sclassen commented 4 years ago

Thank you, we will have a look at this

AndreasEhret commented 4 years ago

please test with 3.0.0-alpha1

mazze5 commented 4 years ago

sorry for the late response. now i have tested it.

it works. but i had to make some changes in the jnlp file to get it working.

the following changes are needed:

i had to change jvm definition to concret version 1.8.0_242 (in OWS 1.x its working with 1.8 <java version="1.8.0_242" java-vm-args="-Xms512m -Xmx1024m"/>
i had to put the main-jar into the main jnlp file. if the main jar is in the extension-jnlp the main-class was not found <jar href="lib/my-main-jar__V1.0.2.jar" main="true"/>
in extension-jnlp i used the version attribute, but that doesn't work. OWS crash. i had to change the entries from <jar href="lib/my.jar" version="1.0.0"/> to <jar href="lib/my__V1.0.0.jar"/>

After these changes the applications starts without the described error "The JNLP application is not fully signed by a single cert"

AndreasEhret commented 4 years ago

Could you give us more details on bullet point three above where OWS crashed (logs, jnlp file, stacktrace)?

mazze5 commented 4 years ago

Here are more informations on bullet point three where OWS crashed.

The crash is the result of a ClassNotFoundException, because the jar files are not downloaded

Could not launch application instance
java.util.concurrent.CompletionException: java.lang.RuntimeException: Error while starting application
    at java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
    at java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
    at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1606)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: Error while starting application
    at net.sourceforge.jnlp.Launcher.launchApplicationInstance(Launcher.java:186)
    at net.sourceforge.jnlp.Launcher.lambda$launch$0(Launcher.java:147)
    at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1604)
    ... 3 more
Caused by: java.lang.NoClassDefFoundError: tup/jrw/core/client/commons/data/DataListener

The jnlp entry looks like this: <jar href="lib/commons-io.jar" version="2.5-tupkey-sectigo-2019"/>

And on the filesystem the jar name is: lib/commons-io__V2.5-tupkey-sectigo-2019.jar

The working request from JavaWebstart: "HEAD /tupng2.0-dev/dialog/lib/commons-io__V2.5-tupkey-sectigo-2019.jar HTTP/1.1" 200

But the OWS request looks like this: "HEAD /tupng2.0-dev/dialog/lib/commons-io.jar?version-id=2.5-tupkey-sectigo-2019 HTTP/1.1" 404

And the OWS stacktrace:

[MESSAGE_ALL][Mon May 11 13:07:50 CEST 2020] Mon May 11 13:07:50 CEST 2020 [DEBUG  ] net.adoptopenjdk.icedteaweb.resources.initializer.ExactVersionedResourceInitializer: Candidate URLs for location=http://tupspa.ka.tup.com:8080/tupng2.0-dev/dialog/lib/commons-io.jar version=2.5-tupkey-sectigo-2019 state=INCOMPLETE: [http://tupspa.ka.tup.com:8080/tupng2.0-dev/dialog/lib/commons-io.jar?version-id=2.5-tupkey-sectigo-2019]
[MESSAGE_ALL][Mon May 11 13:07:50 CEST 2020] Mon May 11 13:07:50 CEST 2020 [DEBUG  ] com.openwebstart.proxy.direct.DirectProxyProvider: Using NO_PROXY
[MESSAGE_ALL][Mon May 11 13:07:50 CEST 2020] Mon May 11 13:07:50 CEST 2020 [DEBUG  ] net.adoptopenjdk.icedteaweb.http.HttpUtils:
Following exception should be harmless, but may help in finding root cause.
java.io.FileNotFoundException: http://tupspa.ka.tup.com:8080/tupng2.0-dev/dialog/lib/commons-io.jar?version-id=2.5-tupkey-sectigo-2019
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1896)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1498)
    at net.adoptopenjdk.icedteaweb.http.CloseableConnection.getInputStream(CloseableConnection.java:58)
    at net.adoptopenjdk.icedteaweb.http.HttpUtils.consumeAndCloseConnection(HttpUtils.java:77)
    at net.adoptopenjdk.icedteaweb.http.HttpUtils.consumeAndCloseConnectionSilently(HttpUtils.java:64)
    at net.adoptopenjdk.icedteaweb.resources.initializer.UrlProber.getUrlResponseCodeWithRedirectionResult(UrlProber.java:71)
    at net.adoptopenjdk.icedteaweb.resources.initializer.BaseResourceInitializer.testUrl(BaseResourceInitializer.java:103)
    at net.adoptopenjdk.icedteaweb.resources.initializer.BaseResourceInitializer.lambda$null$0(BaseResourceInitializer.java:83)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

It seems that OWS adds a queryparameter "version" to the request instead of using __V.jar like JWS does.

Hope this informations help to find and fix the problem.

sclassen commented 4 years ago

Did you add the jnlp.versionEnabled property to your JNLP as described here: https://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/avoidingUnnecessaryUpdateChecks.html

sclassen commented 4 years ago

otherwise OWS will not attempt to download the jar with the __V version

mazze5 commented 4 years ago

Yes I had this property in my JNLP <property name="jnlp.versionEnabled" value="true" />

But only in the components.jnlp, not in the main JNLP. With JWS this works fine. In OWS 3.0.0-alpha1 I need to put that property in the main JNLP, then it works too.

Sosummarized that means that there are two differences between JWS and OWS. In OWS the main-JAR and the versionEnabled-Attribut have to be in the main-JNLP file. In the components-JNLP it is not working.

For my point of view it will be awesome if OWS works like JWS in this to points. If this is possible.

sclassen commented 4 years ago

Thanks for the debugging. We will look into this

mazze5 commented 4 years ago

Hi,

I have seen the milestone was changed from 1.2.0 to 3.0.0 That are bad news for me, I hoped that the issue will be fixed in the 12.0 august release... Do I understand this right, that you plan to fix this issue in version 3.0.0 and for this version exists currently no release date?

sclassen commented 4 years ago

Hi Yes and no. The version 1.2.0 was renamed to 3.0.0. Mainly because the scope of this version was growing constantly and we realized that it is a major change. So the 1.2.0 which will be released soon has nothing to do with the earlier version of 1.2.0. Sorry for the confusion which this has caused.

Regarding your issue: After analyzing the problem we learned that the root cause of this is due to the way IcedTeaWeb has implemented the parsing of the JNLP files. To properly resolve this, a rewrite of the parsing component is most likely inevitable. Unfortunately we currently do not have the budget to tackle such a profound change in the code. We are not even sure if this fix will make it into the 3.0.0 version.

mazze5 commented 4 years ago

Thanks for your quick and honest answer. Unfortunately this is not the answer I was hoping for.

karakun / OpenWebStart

JNLP aggregation leads to a missing attribute permission warning #107