[
https://jira.codehaus.org/browse/MNBMODULE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299068#comment-299068
]
Pino Silvaggio commented on MNBMODULE-50:
-----------------------------------------
There are many reasons to be able to unsign and resign jars. Timestamping an
application that has jars that expires is useless. Asking a customer to accept
multiple certificates, some of which might be unsigned is sometimes (most of
the time) unacceptable.
JNLP Spec 1.0 requires all JAR files used in a single JNLP file to be signed by
the same certificate. This restriction avoids having the user to accept
multiple certificates from the same source, as well as it allows Java Web Start
to know if the user has accepted all certificates that are used for a
particular application.
JAR files that are signed with different certificates can still be used with
Java Web Start. If the JAR files contain code from different packages, they can
be places in different JNLP files, by use of the component extension mechanism.
However, this can become complex and very hard to maintain.
> Signing of already signed jars for Java Webstart application
> ------------------------------------------------------------
>
> Key: MNBMODULE-50
> URL: https://jira.codehaus.org/browse/MNBMODULE-50
> Project: Maven NetBeans Module Plugin
> Issue Type: Improvement
> Affects Versions: 3.0
> Environment: All
> Reporter: Pavel Jisl
> Assignee: Jesse Glick
>
> For releasing webstart applications is crucial to have all jars included
> signed with one certificate of the releasing company. If these jars are not
> signed with one unified certificate, Java Webstart system asks for each
> unsigned (or jar with another signature) if user agrees and grants access to
> the system.
> For this case, we need to sign all jars, included in package, with one
> certificate. As we looked into source code of this plugin, one part of
> signing is in org.netbeans.nbbuild.MakeJNLP#signOrCopy(from, to), another in
> CreateWebstartAppMojo (for jnlp-launcher.jar and branding jars). As all these
> uses the ant SignJar task, we submit issue with patch, allowing us to force
> signing of jars (see
> https://issues.apache.org/bugzilla/show_bug.cgi?id=46891). But we are not
> sure, if this will be accepted, because solving of issues in ant is really
> slow.
> Another solution is usage of Maven Jar Plugin. But this plugin denied to sign
> already signed jar. In this case, we must submit patch, allowing us to force
> signing of already signed jars. But there is problem with the MakeJNLP task.
> Using this solution, we must disable signing of jars in MakeJNLP and sign
> jars programmatically using JarSignMojo from Maven Jar Plugin.
> We can see, that the first solution with modification of SignJar task is more
> complex as it solves problems with signing in both MakeJNLP task and
> CreateWebstartAppMojo, but we can expected long delay before the patch will
> be accepted (or worst - rejected). Another solution is not so conceptual, but
> maybe more clear.
> As last instance, we can also contribute modified JarSignMojo class from
> Maven Jar Plugin , that was used in our corporate modified Maven NBM plugin
> 2.7 for creating webstart application. This must be also used programatically
> as the previous solution directly using Maven Jar Plugin.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
