FULL PRODUCT VERSION :
java version "1.4.1-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b19)
Java HotSpot(TM) Client VM (build 1.4.1-rc-b19, mixed mode)

FULL OPERATING SYSTEM VERSION :Windows NT Version 4.0


ADDITIONAL OPERATING SYSTEMS :(probalbly all supported OS)



A DESCRIPTION OF THE PROBLEM :
i wanted to use  customer -Jakrta-POI inmy application and
deploy it with java webstart.
But it looks like webstart still contains the bugs 4348802
and 4348800.
The jarfile jakarta-poi-1.5.1-FINAL-20020615.jar is built
by  customer  (or the ant-script that came with the source) and
starts like this (jarsingner -verbose -verify):
       33105 Thu Aug 22 15:52:28 CEST 2002 META-
INF/MANIFEST.MF
       32983 Thu Aug 22 15:52:30 CEST 2002 META-INF/MC-DWH.SF
        1088 Thu Aug 22 15:52:30 CEST 2002 META-INF/MC-DWH.DSA
           0 Sat Jun 15 13:43: customer  CEST 2002 META-INF/
           0 Sat Jun 15 13:30:54 CEST 2002 org/
           0 Sat Jun 15 13:30:54 CEST 2002 org/ customer /
           0 Sat Jun 15 13:30:54 CEST 2002 org/ customer /poi/
           0 Sat Jun 15 13:30:54 CEST 2002 org/ customer /poi/dev/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hpsf/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hpsf/littleendian/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hpsf/wellknown/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hssf/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hssf/dev/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hssf/eventmodel/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hssf/model/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hssf/record/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hssf/record/aggregates/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hssf/record/formula/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hssf/records/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hssf/usermodel/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/hssf/util/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/poifs/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/poifs/common/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/poifs/dev/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/poifs/eventfilesystem/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/poifs/filesystem/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/poifs/property/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/poifs/storage/
           0 Sat Jun 15 13:30:58 CEST 2002 org/ customer /poi/util/
sm       410 Sat Jun 15 13:30:58 CEST 2002 log4j.properties

the entries with length == 0 are directories, but webstart
seems to treat them like normal files with length==0 and
throws an exception like this:

Missing signed entry in resource:
http://erlf496a.erlf. customer .de/dwh/files/fsq/sjakarta-poi-1.5.1-FINAL-20020615.jar

signed jars, that do not include zero-length entries of any
kind seem to be accepted.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.download jakarta from
http://jakarta. customer .org/builds/jakarta-poi/release/src/
2. sign sjakarta-poi-1.5.1-FINAL-20020615.jar to sjakarta-
poi-1.5.1-FINAL-20020615.jar
3. include that signed jar in any existing JNLP-file

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected:
1.
webstart should consider the type of the entry that is
verified. directory-entries will always have zero length,
and will never be signed, but that does not matter at all.
2.
webstart should not issue error-message of the kind :
"i know what is wrong, but i won't tell you"
instead of just printing a message like "Missing signed
entry in resource: " it should print at least the name of
the entry that is considered to be unsigned.



ERROR MESSAGES/STACK TRACES THAT OCCUR :
  Category: Download Error

Missing signed entry in resource:
http://erlf496a.erlf. customer .de/dwh/files/fsq/sjakarta-poi-1.5.1-FINAL-
20020615.jar


REPRODUCIBILITY :
This bug can be reproduced always.

-------------- SOURCE CODE -----------------
<jnlp spec="1.0+" version="0.1" href="fsq.jnlp" codebase="http://erlf496a.erlf.s
iemens.de/dwh/files/fsq/">
  <information>
    <title>(TEST)FSQ</title>
    <vendor>SIEMENS AG, A&D MC IT</vendor>
    <homepage href="http://erlf496a.erlf. customer .de/dwh/files/fsq/index.html" />
    <description kind="one-line">FSQ Test</description>
    <description kind="tooltip">dies ist die aktuelle Entwicklungsversion des FS
Q-Frontends</description>
    <description kind="short">Testversion vom 13.08.2002</description>
    <icon href="fsq_logo.gif" />
    <offline-allowed />
  </information>
  <security>
  </security>
  <resources>
    <j2se version="1.4+"  />
    <jar href="sFSQimages.jar" />
    <jar href="sFSQproperties.jar" />
    <jar href="sFSQini.jar" />
    <jar href="sclasses12.jar" />
    <jar href="scommons-logging-1.0.jar" />
    <jar href="sjakarta-poi-1.5.1-FINAL-20020615.jar" />
    <jar href="sJCT.jar" />
    <jar href="sJCTds.jar" />
    <jar href="sJCE.jar" />
    <jar href="sFSQ.jar" main="true" />
    <property name="user.name" value="FSQ-Frontend" />
    <property name="poi.logging" value="ON" />
    <property name="logging" value="0" />
  </resources>
  <application-desc main-class="FSQMain" />
  <installer-desc main-class="FSQMain" />
</jnlp>
--------------- END SOURCE --------------------
(Review ID: 163604) 
======================================================================

N/A

The problem was caused by some version of jarsigner acting on a jar allready
containing a manifest with the contents:
> Manifest-Version: 1.0^M 
> Built-By: Glen Stampoultzis^M
> ^M
> Name: common^M
> Specification-Title: jakarta-poi^M
> Specification-Version: 1.5.1^M
> Specification-Vendor: Apache Software Foundation^M
> Implementation-Title: jakarta-poi^M
> Implementation-Version: 1.5.1-final^M
> Implementation-Vendor: Apache Software Foundation^M 

jarisgner would insert this in the middle of the new manifest file it generated.
This would then have an entry:
> Name: common^M
corrisponding to a file not existant in the jar.  thus the error.

later versions of jarsigner do not have this problem.
signing this jar with jarsigner from 1.3.1 or later fixes the problem

  xxxxx@xxxxx   2002-08-30


Although the original bug description delt with empty directorys, there have been many jdc comments to this bug dealing with manifest entrys that contain
package versioning information that was discarded by jarsigner thru java 1.3.1,
and now, due to a fix for bug 4404260: jarsigner discards package versioning information, is now maintained byjarsigner from versions beyond 1.4.0.
I am re-opening this question to determine if the assumption javaws is making (that all entries in the manifest must have corrisponding entries in the jar file) is still valid after this change in jarsigner.

  xxxxx@xxxxx   2002-11-12

I'm sorry, but any issue that causes a developer hours of 
frustration is a bug, whether you think the behavior is proper 
or not.

If jarsigner verifies a signed jar, then Web Start should 
accept it.

If non-existant files in MANIFEST.MF are a security issue, 
then jarsigner shouldn't verify these JARs.

How are we supposed to automate a build that doesn't work 
until run under Web Start?

And the second part of the submitter's bug is still valid:

webstart should not issue error-message of the kind :
"i know what is wrong, but i won't tell you"
instead of just printing a message like "Missing signed
entry in resource: " it should print at least the name of
the entry that is considered to be unsigned.

I've submitted a new bug titled "Web Start rejects JARs 
signed and verified with jarsigner"

Also, see the developer forum thread 
http://forum.java.sun.com/thread.jsp?
forum=38&thread=275890

I think this is a bug, because any application can use the 
MANIFEST.MF file using Name: for its own configuration. 
Jarsigner does correctly support third-party in MANIFEST.MF.

Why don't you want JavaWebStart do the same ???

I really think this is still a bug !!!!

I agree that this is a bug.  Indeed, the jarsigner in version 
1.4.0 appears to cause the problem, whereas 1.3.1 does not.  

Using the jarsigner in 1.4.0, if I sign a jar that already 
contains a named resource, it seems to succeed but 
generates a jar that causes Web Start to die with a "missing 
signed entry" error.

This is misleading and annoying behaviour!

now i have installed JDK1.4.1-FCS, BUG still exists.
then i deleted the manifest from the original jar before 
signing, the BUG still exists.

so my conclusion is, that Webstart treats directory-entries in 
the jarfile as "possibly dangerous", with does not make any 
sense at all.

What kind of dangerous things could a completely empty 
entry in a jarfile do?


But why 

I'm also running into a variation of this and agree that this is 
a bug and that it is still open.  I'm working on a JWS 
application with 27 third party jars and some of them have 
the problem described above, where the jar's MANIFEST.MF 
file contains some header information such as this:

Name: com/sybase/jdbc2/timedio
Implementation-Title: "com.sybase.jdbc2.timedio" 
Specification-Title: "jConnect for JDBC 2.0" 
Specification-Version: "5.2"
Specification-Vendor: "Sybase, Inc."
Implementation-Version: "Build (20765)"
Implementation-Vendor: "Sybase, Inc."

This gets inserted into the middle of the new MANIFEST file.  
But because "com/sybase/jdbc2/timedio" in this example 
refers to a directory, there is no explicit entry for it in the jar 
file, and when JWS tries to read the signed file, it looks for an 
entry in the jar for every entry in the MANIFEST, and when it 
doesn't find one, it throws an exception.  Meanwhile jarsigner 
reports that the jar file is fine.  Further, the exception doesn't 
provide any information to the developer.

The code that causes the problem is below.  This has been 
decompiled with JAD, so this isn't the exact code from the 
baseline, but the logic is clear.  This is from 
SigningInfo.checkSigning()

Manifest manifest = jarfile.getManifest();
Set set = manifest.getEntries().entrySet();
for(Iterator iterator = set.iterator(); iterator.hasNext();)
{
   java.util.Map.Entry entry = (java.util.Map.Entry)iterator.next
();
   String s1 = (String)entry.getKey();
   if(jarfile.getEntry(s1) == null)
       throw new JARSigningException(url, s, 4);
}

The result of this is a lot of work by hand which is required to 
sign a third party jar file (sign, run through a custom utility to 
find the problem, unjar the file, fix the manifest, rejar, resign, 
retest), which is really getting to be a problem with us.

I also have the error, and the unjar'ing, manual editing of the 
manifest file doesn't work either.

This still looks like it is a problem.   If I sign
xml-apis.jar using the jarsigner from 1.4.1_01 then it
fails.  But If I use 1.3.1_03 then things work great.

This bug is back again. I have jar-files signed with 1.4.1_03 
and now upgraded to 1.4.2. Web Start always tells me that 
there are unsigned entries. I even tried to unpack and sign 
them again with 1.4.2 but this also does not work. jarsigner -
verify tells me that the jar-file is ok.

Bug still exists in 1.4.2_01. A third party jar signed by me could not be 
started via JNLP because of unsigned classes. jarsigner says all classes 
are signed. After removing all MANIFEST information from the jar and 
re-signing it worked.