This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 98371 - Allow not to sign the JNLP jars
Summary: Allow not to sign the JNLP jars
Status: RESOLVED FIXED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Harness (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: David Strupl
URL:
Keywords:
Depends on: 118017
Blocks:
  Show dependency tree
 
Reported: 2007-03-20 16:43 UTC by David Strupl
Modified: 2007-10-06 22:27 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
Proposed patch (4.80 KB, patch)
2007-03-20 16:45 UTC, David Strupl
Details | Diff
Revised patch (15.26 KB, patch)
2007-03-29 11:45 UTC, David Strupl
Details | Diff
Revised patch (21.10 KB, patch)
2007-04-09 23:12 UTC, David Strupl
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Strupl 2007-03-20 16:43:14 UTC
I will attach the patch. I hope it is not conflicting patch since the default
behavior stays the same as before. Can you please review the patch? I will apply
it if there are no objections.
Comment 1 David Strupl 2007-03-20 16:45:48 UTC
Created attachment 39710 [details]
Proposed patch
Comment 2 Jesse Glick 2007-03-20 18:26:51 UTC
jnlp.xml should explicitly set a default:

  <property name="jnlp.sign.jars" value="false"/>


Typo: "Deafults"


I think it is a good start but I would like to know how it works. Do you need to
also set -J-Dnetbeans.jnlp.fixPolicy=true so that
org.netbeans.modules.apisupport.jnlplauncher.Main.fixPolicy() is run? (Otherwise
I guess JNLP will simply reject the application.)

If so, shouldn't setting jnlp.sign.jars=false during the build automatically add
this runtime switch to the generated app.conf, so the created app actually works
when you run it? Also, will run-jnlp work out of the box?


If the new mode is important for performance - it sounds like it is - then I
would suggest a new checkbox in suite Properties to control it, e.g. default:

  [X] Use JNLP Security
Comment 3 Jaroslav Tulach 2007-03-20 20:12:03 UTC
Y01 Write tests.
Comment 4 David Strupl 2007-03-22 13:00:06 UTC
I have just tried with the following entry in the main .jnlp file:

<property name="netbeans.jnlp.fixPolicy" value="true"/>

and following 2 entries in project.properties:

jnlp.sign.jars=false
jnlp.permissions=<security/>

With these the local launch of .jnlp file works. I will try also the .war
deployment.

Y01 - Ok, I will try to add some.

I will refine the patch and come back to you.

BTW what (where) is app.conf? And also is it really necessary to put this into
the project GUI?
Comment 5 Jesse Glick 2007-03-22 19:26:07 UTC
${appname}.conf would be used for ZIP distributions. For JNLP builds you are
correct in modifying the main .jnlp file. So I think if the project property is
set, then (1) only the main JAR should be signed, (2) the main .jnlp file should
be created with netbeans.jnlp.fixPolicy defined as you say (and probably with
the corrected <security> element too).

A GUI is not strictly necessary if everything can be controlled from one
property definition in project.properties, but it would be nice (improves
discoverability).
Comment 6 David Strupl 2007-03-29 11:45:37 UTC
Created attachment 40131 [details]
Revised patch
Comment 7 David Strupl 2007-03-29 11:48:16 UTC
The revised patch adds some tests + adds an entry to the .jnlp file. Currently
the entry is commented out with an explaining comment. The permissions are also
updated according to the property.

The last thing for a discussion is IMHO following: currently I have removed the
signing for the NB platform, not for the suite. The suite modules are still
signed - should I change also that?
Comment 8 Jesse Glick 2007-04-05 20:18:18 UTC
Sorry I am taking so long to respond. Some comments:

harness/README should note the new conditional default value for jnlp.permissions.

What is the (commented-out) netbeans.jnlp.fixPolicy? Left in there by accident?
I don't see any other mention of such a property.

Probably suite modules should also be unsigned if jnlp.sign.jars=false. I don't
see any purpose in them being signed if nothing in the platform is.
Comment 9 David Strupl 2007-04-05 20:39:11 UTC
> harness/README should note the new conditional default value 
> for jnlp.permissions.

Ok, I will add it.

> What is the (commented-out) netbeans.jnlp.fixPolicy? Left in there by 
> accident? I don't see any other mention of such a property.

No, you have to uncomment it if you want the JNLP to work as the above the line
comment says. You have to do that manually with the current proposed change.

> Probably suite modules should also be unsigned if jnlp.sign.jars=false. 
> I don't see any purpose in them being signed if nothing in the platform is.

Ok, I will change also that.

I will attach the new patch and then ask you for opinions again. Thanks for the
comments so far.
Comment 10 Jesse Glick 2007-04-06 17:32:23 UTC
I think netbeans.jnlp.fixPolicy ought to be turned on automatically if you turn
off JAR signing. Otherwise the app simply won't run unless you track down this
cryptic flag and edit it in your master.jnlp. Right? Although it would be
preferable to permit the signing mode to be turned on or off dynamically, after
master.jnlp has been created, which makes me think that it should be substituted
in the filterchain in build-jnlp-nowar. That would enable us to reliably control
the entire mode switch using a checkbox in the GUI.
Comment 11 David Strupl 2007-04-09 23:12:06 UTC
Created attachment 40642 [details]
Revised patch
Comment 12 David Strupl 2007-04-09 23:14:55 UTC
I have attached a patch that should address the comments. Please note that I
have created one more .jnlp file (branding.jnlp) because in order to use the
signing only for one file the branding jars must be accessed from an extension
and not from the main .jnlp file.
Comment 13 Jesse Glick 2007-04-12 17:27:47 UTC
Looks good to me, commit at your leisure. At some point I want to write a JNLP
validator that we can run to verify that all hrefs are valid, signatures are
correct, etc. This would assist in catching stupid mistakes when writing scripts
like this. But it is not available yet, alas.


Typo: "Deafults"


3 uses of getSignTask vs. Copy could probably be factored out into a separate
method.
Comment 14 David Strupl 2007-04-13 21:57:44 UTC
Committing with the typo corrected and the method factored out:

Checking in apisupport/harness/release/README;
/cvs/apisupport/harness/release/README,v  <--  README
new revision: 1.57; previous revision: 1.56
done
Checking in apisupport/harness/release/jnlp.xml;
/cvs/apisupport/harness/release/jnlp.xml,v  <--  jnlp.xml
new revision: 1.42; previous revision: 1.41
done
Checking in nbbuild/templates/common.xml;
/cvs/nbbuild/templates/common.xml,v  <--  common.xml
new revision: 1.61; previous revision: 1.60
done
Checking in nbbuild/antsrc/org/netbeans/nbbuild/MakeJNLP.java;
/cvs/nbbuild/antsrc/org/netbeans/nbbuild/MakeJNLP.java,v  <--  MakeJNLP.java
new revision: 1.22; previous revision: 1.21
done
Checking in nbbuild/test/unit/src/org/netbeans/nbbuild/MakeJNLPTest.java;
/cvs/nbbuild/test/unit/src/org/netbeans/nbbuild/MakeJNLPTest.java,v  <-- 
MakeJNLPTest.java
new revision: 1.16; previous revision: 1.15
done
Comment 15 David Strupl 2007-04-13 22:00:43 UTC
Forgot to change the target milestone...
Comment 16 mirza 2007-06-01 15:26:48 UTC
So, can we expect this to be in 6.0 M10?
Comment 17 David Strupl 2007-06-01 23:10:59 UTC
It is already in M9. But it has no GUI and it is not about signing "normal"
application using Web Start but about using platform based application using Web
Start. Details should be in harness/README.
Comment 18 mirza 2007-06-02 21:05:10 UTC
how about making signing optional (not needed by default) for jnlp everyhere? I
would like to use Web Start as launcher for all my in-house applications that
*really* will never be in danger of cyber-attack, so it would be cool not to
bother with signing.
Comment 19 David Strupl 2007-06-04 09:05:11 UTC
Please file a separate Enhancement Request for this. Jesse, Jarda any advice as
to which component and subcomponent such issue should be filed under?
Comment 20 mirza 2007-06-04 10:07:07 UTC
Issue 105534 created.