JDK-4785851 : JWS fails to load jars signed and verified with jarsigner that have header info
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 1.2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-11-27
  • Updated: 2002-12-03
  • Resolved: 2002-12-03
Related Reports
Duplicate :  
Description

Name: nt126004			Date: 11/27/2002


FULL PRODUCT VERSION :
This bug is present in JWS version 1.2 when it invokes java version "1.4.1_01".

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

EXTRA RELEVANT SYSTEM CONFIGURATION :
This appears to be a problem in
com.sun.javaws.security.SigningInfo so I believe it would
be a problem on any JWS client that uses that code.

A DESCRIPTION OF THE PROBLEM :
I'm submitting a new bug for bug #4739089, which was closed
and tagged as "not a bug", though there is strong consensus
that it is still a bug.  I've identified the code that
causes the problem through JAD, please see that bug
description.

Aside from the behavior of failing to load jars that have
been signed with jarsigner, there is a separate problem in
that the error messages produced by JWS upon failure do not
describe the problem.  The exceptions are fairly anonymous
(i.e. "Missing signed entry in resource:
http://dfin01:7777/LittleAlex/common/lib/jconn2.jar"), when
the exceptions are thrown from a point in the code where it
is possible to identify exactly which resource or entry is
causing the problem.   Reporting the entry and generally
more detail will save developers hours of debugging.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This bug appears consistently with certain third party jar
files.  One one of them is the jconnect version 5.2 jar
file, jconn2.jar, but will happen with any jar file that
has header information in the manifest like this:

Name: com/sybase/jdbcx/
Implementation-Vendor: "Sybase, Inc."

Simply sign it with jarsigner, then include it in your JNLP
file and try to launch your app.  You'll get an exception
that reports "Missing signed entry in resource".  The
problem is entries in the jar file's MANIFEST that don't
map to entries in the jar file itself, such as directory
entries.

EXPECTED VERSUS ACTUAL BEHAVIOR :
JWS should not assume that every entry in the jar's
manifest file maps to an entry in the jar file.  It can
check for directories and exclude them or act
appropriately.  If there is an error, it should report a
detailed error message with the name of the entry causing
the problem.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
JNLPException[category: Download Error : Exception: null : LaunchDesc: null ]
	at com.sun.javaws.security.SigningInfo.checkSigning(Unknown Source)
	at com.sun.javaws.cache.DownloadProtocol$RetrieveAction.actionDownload
(Unknown Source)
	at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
	at com.sun.javaws.cache.DownloadProtocol.getResource(Unknown Source)
	at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
	at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)
	at com.sun.javaws.Launcher.downloadResources(Unknown Source)
	at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
	at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:536)



REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
There are source examples in bug 4739089.
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
My workaround is to sign the jar file, run a custom utility
that reports any entries in the manifest that are not in
the jar, then if any are found, unjar the jar, either edit
the MANIFEST file to remove the entries or create bogus
files that match the names used in the jar, re-jar the
file, and re-sign it.

For large applications such as ours with 27 third party
jars (and growing), this becomes an increasingly large
overhead expense as we develop and incorporate new third
party jars.
(Review ID: 166630) 
======================================================================

Comments
EVALUATION This is a dupe of 4739089 as it sais, which is not closed, but fixed in mantis. ###@###.### 2002-12-03
03-12-2002