[RFC][icedtea-web] Signed JNLP file: added regression tests

[Jiri Vanek]

On 05/22/2012 09:33 PM, Saad Mohammad wrote:
> Hi,
>
> The patch attached tests the launch of applications with a signed JNLP file using matching and
> non-matching JNLP launch files.
>

Hi Saad!

Looks great! Your sin is half a redeemed;o)

I have one questions  and two minor, but a lot of affecting issues

Issues - Can we handle naming convention 
(http://www.oracle.com/technetwork/java/codeconv-138413.html) for classes and methods?
  - The classes should be in CamelCase So eg no "SignedJNLPTemplateTest" but 
"SignedJnlpTemplateTest". I would recommend also renaming of directories to keep the name consistent 
as you have it nicely now.
  - methods should not start with capital letter.
I know that those two errors leaked in past to reproducers but it would be nice to have it correct 
in new files.
  - APPLICATION_TEMPLATE.JNLP/APPLICATION.JNLP should be case insensitive. Can you test it?

Q: I thought that jnlp signing is working like this:
1 - (I'm unsure here) signed jar with JNLP-INF/*  and unsigned jar with the (signed?) 
same/tempalte_matching jnlp file.
So to test it properly you need to us two jars - signed and unsigned. And ensure that the second one 
obtains rights or launch terminate.
2 - or (more probably, but I'm still lost in this signing)  just jnlp file (and few others BUT NOT 
whole jar) should be signed in jar and the rest is evaluated by comparison of launching jnlp and 
signed jnlp inside.

What jnlp test engine is doing is that it signs whole jar.  So In my (I hope wrong!) opinion your 
tests are actually not testing jnlp signing (as whole jar is signed). But exception looks correct, 
so I hope I'm completely wrong :)


Thanx for explanations!

    J.


I have added citation from spec:
5.4 Signed Applications

The signing infrastructure for JNLP is built on top of the existing signing infrastructure for the 
Java 2 Platform. The Java 2 Platform supports signed JAR files. A JAR file can be signed and 
verified using, e.g., the standard jarsigner tool from the Java 2 SDK.

An application launched by a JNLP Client is considered to be signed, if and only if:

     All the JAR files are signed (both for jar and nativelib elements) and can be verified. A JAR 
file is signed if all the entries (excluding manifest entries, the signature iteself, and empty 
directories) are signed by a single signature.
     If a signed version of the JNLP file exists, then it must be verified, and it must match the 
JNLP file used to launch the application. This is described in the following subsection.
     The same certificate is used to sign all JAR files (jar and nativelib elements) that are part 
of a single JNLP file. This simplifies user management since only one certificate needs to be 
presented to the user during a launch per JNLP file (and hardly restricts the signing process in 
practice).
     The certificate used for signing the JAR files and JNLP file (if signed) must be verified 
against a set of trusted root certificates.

How the set of trusted root certificates are obtained depends on the particular JNLP Client 
implementation. Typically, a JNLP Client will be shipped with a set of trusted root certificates for 
all the major Certificate Authorities (CAs).

The JNLP Client must check a JAR file for signing information before it is used, i.e., before a 
class file or another resource is retrieved from it. If a JAR file is signed and the digital 
signature does not verify, the application must be aborted. For a lazily downloaded JAR file, i.e., 
a JAR file that is downloaded after the application is launched, this might require aborting an 
already-running application.
5.4.1 Signing of JNLP Files

A JNLP file can optionally be signed. A JNLP Client must check if a signed version of the JNLP file 
or JNLP template exist, and if so, verify that at least one of them match the JNLP file that is used 
to launch the application. If a match is not found (see below), then the launch must be aborted. If 
no signed JNLP file or JNLP template exist, then the JNLP file is not signed, and no check needs to 
be performed.

A JNLP file is signed either by including a copy of it in the signed main JAR file, or by including 
a matching (see below) template file in the signed main JAR file.
For the first method, the signed copy must be named: JNLP-INF/APPLICATION.JNLP. The APPLICATION.JNLP 
filename should be generated in upper case, but should be recognized in either upper or lower case. 
To match, the signed JNLP file must contain exactly the same XML elements and attributes, with 
identical values, as the JNLP file used to launch the application.

For the second method the signed copy must be named JNLP-INF/APPLICATION_TEMPLATE.JNLP. The 
APPLICATION_TEMPLATE.JNLP filename should be generated in upper case, but should be recognized in 
either upper or lower case. The template (APPLICATION_TEMPLATE.JNLP) may have fields for CDATA 
arguments or values denoted as "*". The signed template must have exactly the same elements and 
arguments as the JNLP file used to launch the app, and the value of each element and attribute must 
"match" as described below. An element value or attribute value matches if either the value in the 
template is identical to the value in the JNLP file used to launch the app, or all of the following 
are true:

1.) The element or attribute is defined (in the DTD in appendix C) to be of type CDATA (for 
attributes) or #PCDATA (for elements).
2.) The element or attribute value in the signed template is "*"
3.) The element or attribute value is not blacklisted or restricted by the JNLP Client.

It is expected that a JNLP Client will blacklist (or restrict) certain jnlp elements and argument 
values such as "java-vm-args" or property "name" and "value" to maintain security. The exact list is 
up to the individual JNLP Client implementations.

As an example, the following APPLICATION_TEMPLATE.JNLP could be used to host an application on 
various hosts with different icons:

     <?xml version="1.0" encoding="UTF-8"?>
     <jnlp codebase="*">
       <information>
         <title>Draw!</title>
         <vendor>My Web Company</vendor>
         <icon href="*"/>
         <offline-allowed/>
       </information>
       <resources>
         <java version="1.3+"/>
         <jar href="draw.jar"/>
       </resources>
       <application-desc main-class="com.mysite.Draw"/>
     </jnlp>

An Application with the above contents in JNLP-INF/APPLICATION_TEMPLATE.JNLP in it's main jar could 
be moved from one server to another, or could change it's icon without resigning the main jar.

As described above, a JNLP file is not required to be signed in order for an application to be 
signed. This is similar to the behavior of Applets, where the Applet tags in the HTML pages are not 
signed, even when granting unrestricted access to the Applet.