blog.david14.com: Application Blocked By Java Security

Solution to the following error

Fig.1

This documentes the requirements for launching an app with all-permissions.

Now, the history of this is that I have been previously signing jar files and deploying them onto my server without issue for quite some time (apart from the initial hiccups and lack of my understanding in these things).

However, when I had some ADSL issues, I decided to move JamBuddyLite to another domain and had issues as noted here: https://stackoverflow.com/questions/60187434/signed-jar-blocked-from-running-by-java-security This however was resolved as detailed in the post by ensuring that the same information in the manifest file was also in the jnlp file, so what follows in an expansion on this issue and how to resolve it.

After messing around for a few hours, rebuilding, resigning, messing around with jnlp files and generally going around in circles, I decided to start again, with a fresh and very simple file, the basis of which follows.

Note: We're testing with JRE 1.8.0_241

1). When I build the jar without signing it and launch with the jnlp file locally, I get the same as per Fig.1. (will need to revisit this stage, as a local app without any specific permissions, should in my mind launch, even it is hasn't been signed).

2). When I build and sign the jar and launch with the jnlp file locally, it launches, firstly showing Fig.2

Fig.2

Note, at this stage we are running the launch.jnlp file as below;

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<vendor>plisken</vendor>

</information>

</resources>

<application-desc main-class="jnlp_test.NewJFrame">

</application-desc>

</jnlp>

Note, we are running this from the local machine, there is no codebase.

Also, if we look in nbproject/project.properties, the following is empty:

manifest.custom.permissions=

3). If we now change the line above in nbproject/project.properties to;

manifest.custom.permissions=all-permissions

then build and sign the jar and launch with the jnlp file locally, we get the same as per Fig.1

However if we then change the launch.jnlp file to the following;

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<vendor>plisken</vendor>

</information>

<all-permissions/>

</security>

</resources>

<application-desc main-class="jnlp_test.NewJFrame">

</application-desc>

</jnlp>

then launch with the jnlp file locally the app will launch, showing Fig.2

Note: There was no need to rebuild the jar file or resign it, we only made a change to the launch.jnlp file for this step.

The above was also tested with a remote codebase, as per https://github.com/plisken1/JNLP_Test_Remote

and

https://gist.github.com/plisken1/a530f44cfd166207d0c505cceb6955a8

The bottom line is that if the manifest.mf file inside the jar has all-permissions then so too must the jnlp file.

Additionally, the codebase in the manifest.mf file must also match the jnlp file.

See here for examples of the launch.jnlp, manifest.mf and project.properties files for an app that will launch locally with all permissions;

https://gist.github.com/plisken1/7a9748b5b9dbdea714f1f9fdb32980ed

and see here for examples of the launch.jnlp, manifest.mf and project.properties files for an app that will launch remotely with all permissions;

https://gist.github.com/plisken1/a530f44cfd166207d0c505cceb6955a8

Additionally, see here for the repository relating to the latter;

https://github.com/plisken1/JNLP_Test_Remote

Some links for reference;

https://www.oracle.com/technical-resources/articles/javase/ds-jnlp-javawebstart.html

https://blog.david14.com/2019/12/multiple-jar-files-signed-with.html

https://blog.david14.com/2019/12/code-signing-with-certum-and-simplysign.html