signtool does not sign object with empty sub-dir

RESOLVED INVALID

Status

NSS
Tools
P3
normal
RESOLVED INVALID
15 years ago
11 years ago

People

(Reporter: Simon Ip, Assigned: Biswatosh Chakraborty)

Tracking

3.4.1
Sun
Solaris

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0

If I use NSS 3.4.1 (nspr-4.1.2) to sign a dir structure like test

test_patch
    |------------README
    |------------empty_subdir
    |------------non-empty_subdir
                         |---------- fileA

The output .jar file will contain the README file and non-empty_subdir (with
fileA). The empty_subdir is missing.




Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Expected Results:  
Should include empty subdir in the jar file.

Comment 1

15 years ago
Assigned the bug to Kirk.

Jamie, is there any reason why signtool should not
include an empty subdirectory in the output jar file?
Assignee: wtc → kirk.erickson
Status: UNCONFIRMED → NEW
Component: Build → Tools
Ever confirmed: true
OS: SunOS → Solaris
Priority: -- → P2
Target Milestone: --- → 3.8
Version: unspecified → 3.4.1

Comment 2

15 years ago
Actually, no directories at all are added to the JAR file, not even directories
that have files. If you do an "unzip -l" on the JAR file, you will see that only
the files are added, not directories. Each filename contains its relative path.
When you unzip the file, unzip pulls the directory name out of the relative path
to the file and creates the directory if it does not exist. Thus, only
directories that contain files will be created by unzip.

Here is an example of a directory hierarchy created by "zip":

> unzip -l test.zip
Archive:  test.zip
 Length    Date    Time    Name
 ------    ----    ----    ----
      0  02-06-03  10:28   test/
      0  02-06-03  10:28   test/empty/
      0  02-06-03  10:28   test/nonempty/
      5  02-06-03  10:28   test/nonempty/foo.txt
 ------                    -------
      5                    4 files

And here is the same hierarchy in a JAR file created by signtool:

> unzip -l test.jar
Archive:  test.jar
 Length    Date    Time    Name
 ------    ----    ----    ----
      5  02-06-03  10:39   test/nonempty/foo.txt
    248  02-06-03  10:39   test/META-INF/manifest.mf
    356  02-06-03  10:39   test/META-INF/zigbert.sf
    778  02-06-03  10:39   test/META-INF/zigbert.rsa
 ------                    -------
   1387                    4 files

"zip" adds a separate entry for each directory so it exists independently of its
files. I think that is the correct solution for signtool. Note that directories
are not signed, only files. It is therefore possible to add or remove empty
directories from the JAR file without affecting the validity of the signature.

The fix probably needs to go in the manifesto() and manifest_fn() functions in
sign.c. manifesto() uses the foreach() function to call manifest_fn() on each
file in the directory hierarchy. foreach() takes an argument indicating whether
manfiest_fn() should be called on directories or just files. Currently it is set
to be called just on files. This should be changed so that manifest_fn() is
called on directories as well. Then, manifest_fn() needs to check if it is being
called against a directory. If so, it should only call JzipAdd to add the
directory to the ZIP file. For non-directories, it should do everything that it
currently does (hash the file, add it to the manifest, etc). We also need to
change JzipAdd so that it can handle a directory; currently it expects to only
be passed a normal file.

Alternatively, we could use a two-pass approach. First add all the directories,
then the files. Then we wouldn't have to change manifest_fn(). Instead we would
write an add_directory_fn(), which would only operate on directories.
Remove target milestone of 3.8, since these bugs didn't get into that release.
Target Milestone: 3.8 → ---

Comment 4

15 years ago
Not likely to get to this in the 3.9 timeframe.
Set Target Milestone to Future.
Target Milestone: --- → Future

Updated

15 years ago
Target Milestone: Future → ---

Comment 5

14 years ago
Mass reassign of Kirk's bugs.
Assignee: kirk.erickson → glen.beasley
Summary: NSS 3.4.1 does not sign object with empty sub-dir → signtool does not sign object with empty sub-dir
QA Contact: wtchang → tools

Updated

12 years ago
Priority: P2 → P3
(Assignee)

Comment 6

11 years ago
I am going to work on this bug now.
Assignee: glen.beasley → biswatosh.chakraborty
I think this bug may be more complex than it looks.  

I suggest that, before any changes are attempted, you should go and use
Sun's signtool on this same hierarchy of files and directories, and see
what it creates, that is, see if it creates entries for the directories 
themselves in the JAR/zip.  

If it does, then the second step is to see if it also puts entries for 
those directories into the various files in META-INF, such as manifest.mf
and perhaps zigbert.sf
(Assignee)

Comment 8

11 years ago
It seems jarsigner creates entries for files only and not for directories in
MANIFEST.MF and the .SF file.

So, I created a dir called tmp in which there was an empty dir, a non-empty dir
and a file. Zipped it to tmp.zip and jarsigned it and tmp.zip was overwritten 
by a new tmp.zip. Unzipping tmp.zip gave the original tmp directory(which thus included the empty dir too) and META-INF dir. META-INF as usual contained
the .SF, .DSA and MANIFEST.MF file. The .SF and the MANIFEST.MF file contained
digests of the files only and not the directories. Pls see the details of the test below.


*************************************************************************

$pwd 
/testing
$mkdir tmp
$cd tmp
$mkdir d1 d2
$touch f1
$cd d1
$touch f11

[ Hence, d2 is an empty directory]
 
$cd /testing
$zip -r tmp.zip tmp/
$jarsigner tmp.zip gautam
[gautam-> alias name in keystore]
$ mkdir testdir
$cp tmp.zip testdir/
$cd testdir
$unzip tmp.zip
Archive:  tmp.zip
  inflating: META-INF/MANIFEST.MF
  inflating: META-INF/GAUTAM.SF
  inflating: META-INF/GAUTAM.DSA
   creating: tmp/
   creating: tmp/d1/
 extracting: tmp/d1/f11
 extracting: tmp/f1
   creating: tmp/d2/
$ls
META-INF tmp tmp.zip
$diff -r tmp /testing/tmp
[Thus no difference and hence the empty dir d2 is here too!]
$cd META-INF
$ls
GAUTAM.DSA  GAUTAM.SF  MANIFEST.MF
$cat MANIFEST.MF
Manifest-Version: 1.0
Created-By: 1.5.0_06 (Sun Microsystems Inc.)
 
Name: tmp/f1
SHA1-Digest: 2jmj7l5rSw0yVb/vlWAYkK/YBwk=
 
Name: tmp/d1/f11
SHA1-Digest: CZCAg3GTopWXPoW6NgKdA4eRsVI=
 
$cat GAUTAM.SF
Signature-Version: 1.0
Created-By: 1.5.0_06 (Sun Microsystems Inc.)
SHA1-Digest-Manifest-Main-Attributes: bIcDCLCgKingWhBfRxWHibFj4lw=
SHA1-Digest-Manifest: wbmNZ5+0VglzvBz9d6Wv670XIeU=

Name: tmp/d1/f11
SHA1-Digest: D+4lPzH5VYV9proIUNviAt0et9o=
 
Name: tmp/f1
SHA1-Digest: 7o49Q7nd5gmOhaYJXM77DMm5SX0=
 

[Thus MANIFEST.MF and GAUTAM.SF file do not contain any reference
to the empty dir]
************************************************************
(Assignee)

Comment 9

11 years ago
Based on the findings mentioned in Comment #8 ,it seems jarsigner and signtool
behave similarly as far as the manifest(.mf) and signature(.sf) files are concerned. Now, do we treat this feature(not signing an empty dir) a bug?
If not, we need to close this then. 
IMO this need not be treated as a bug.
And, if somebody thinks otherwise, I would like to know the reason for that.
(Assignee)

Comment 10

11 years ago
Marking the bug as INVALID for the reason mentioned in Comment #9. 
 
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.