Absence of Malice in JavaFX

Because JavaFX Script programs compile to Java CLASS files and run within the Java Runtime Environment (JRE), they are subject to the Java security model.  When a user clicks a Java Web Start link or navigates to a page that contains an applet, the Java code must play exclusively in "the sandbox" unless the user gives it permission to jump out.  There are a couple of ways to enable the user to give this permission to the application:

1. Option #1: Don't sign the JAR files that contain your JavaFX application.  By not signing the JAR files, you are ensuring that the user will be asked to authorize any out-of-sandbox-experiences.  For example, the Earthrise at Christmas post contains a Java Web Start link to a JavaFX application that isn't signed.  Because the application displays an image that is loaded from another website (in this case nasa.gov) the following Security Warning dialog is presented to the user:
   
   
   
   This option makes the user respond to Security Warnings, but if the code isn't signed, then the user shouldn't be expected to trust the application without receiving these kinds of warnings.
2. Option #2: Sign the JAR files that contain your JavaFX application.  By signing the JAR files, you are ensuring that the application will not execute unless the user indicates that he/she trusts the signer of the code.  In addition, the user won't be asked for permission for the application to play outside of the sandbox when, for example, the image from Nasa above is accessed, or a file is written.  To demonstrate this, if you click the following Java Web Start link to the Earthrise at Christmas application in which the JAR file is signed, you'll be presented with the Security dialog shown below it:
   
   
   
   
   
   
   Notice that the the dialog says that the signature has been verified/validated (because a code-signing certificate was used).  This is an important feature because if the signature can't be verified, then the user can't be sure who really signed it.  This opens the door for spoofed and malicious applications.  The only way that I would run an application whose signature hasn't been verified, is if I knew by some other means who published the application (e.g. the application was written by a colleague and it is located on a corporate intranet).

What about the Self-Signed Jar option in NetBeans (using the JavaFX Plug-in)?

If you select the Self Signed Jar option in NetBeans as shown below, then a dialog similar to the one above will appear when the user runs the application, but it will say that the signature can't be verified.

For reasons described above, posting or executing Java and JavaFX applications with self-signed JARs on the Internet is not a good practice.  It's better to go with option #1 above and let the user approve any out-of-the-sandbox behavior, or option #2 with a code-signing certificate (e.g. from VeriSign or Thawte).

Creating and Signing Pack200 (Compressed) Files

The JAR files that contain Java/JavaFX applications can be further compressed into the Pack200 format and deployed with JNLP.  To create and sign a Pack200 file, use the following commands available with the JDK, shown here in the context of the Earthrise at Christmas application:

pack200 --repack HelloEarthRise.jar

jarsigner -keystore [keystore url] -verbose -keypass [key password] 
  -storepass [keystore password] HelloEarthRise.jar [keystore alias]

pack200 HelloEarthRise.jar.pack.gz HelloEarthRise.jar

As always, please leave a comment if you have any questions.

Regards,
Jim Weaver
JavaFXpert.com