[9] request for review: 8049171: Additional tests for jarsigner's warnings

[Artem Smotrakov]

Hi Max,

Please see inline.

On 01/23/2015 05:18 AM, Wang Weijun wrote:
>> I have updated the webrev, updateJar() method does the following:
>> >- creates a new jar file (destJarFilename)
>> >- puts files which are specified in files parameter to destJarFilename
>> >- copies files from srcJarFilename to destJarFilename if they are no files with the same names in destJarFilename
> The process above means the new files are added at the beginning.
Yes, "jar -tvf" shows the following for an original signed jar (before 
updateJar() is called)

jar -tvf JTwork/scratch/0/signed.jar
     83 Fri Jan 23 10:06:16 MSK 2015 META-INF/MANIFEST.MF
    327 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.SF
   1091 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.RSA
      0 Fri Jan 23 10:06:10 MSK 2015 first.txt

After pdateJar() is called, "jar -tvf" shows the following for modified jar

jar -tvf JTwork/scratch/0/updated_signed.jar
      0 Fri Jan 23 10:06:16 MSK 2015 second.txt
     83 Fri Jan 23 10:06:16 MSK 2015 META-INF/MANIFEST.MF
    327 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.SF
   1091 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.RSA
      0 Fri Jan 23 10:06:10 MSK 2015 first.txt

> While jarsigner is able to verify such a file (it uses JarFile) the output is actually invalid because the MANIFEST and the signature files must be at the beginning (otherwise a JarInputStream cannot verify it).
jarsigner successfully verifies a jar file that was modified by 
updateJar() method, please see a piece of log for 
sun/security/tools/jarsigner/warnings/HasUnsignedEntryTest.java test

Copy signed.jar to updated_signed.jar, and add second.txt.class, so it 
contains unsigned entry
Updating updated_signed.jar with second.txt
Copying META-INF/MANIFEST.MF to updated_signed.jar
Copying META-INF/ALIAS.SF to updated_signed.jar
Copying META-INF/ALIAS.RSA to updated_signed.jar
Copying first.txt to updated_signed.jar

Command line: 
[/home/artem/ws/jdk/jdk9_dev/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jarsigner 
-verify -verbose -keystore keystore.jks -storepass password -keypass 
password updated_signed.jar]

            0 Fri Jan 23 10:06:16 MSK 2015 second.txt
s k       83 Fri Jan 23 10:06:16 MSK 2015 META-INF/MANIFEST.MF
          327 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.SF
         1091 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.RSA
smk        0 Fri Jan 23 10:06:10 MSK 2015 first.txt

   s = signature was verified
   m = entry is listed in manifest
   k = at least one certificate was found in keystore
   i = at least one certificate was found in identity scope

jar verified.

Warning:
This jar contains unsigned entries which have not been integrity-checked.
This jar contains signatures that does not include a timestamp. Without 
a timestamp, users may not be able to validate this jar after the signer 
certificate's expiration date (2016-01-23) or after any future 
revocation date.

Re-run with the -verbose and -certs options for more details.

If the MANIFEST and the signature files must be at the beginning, should 
it be considered as a bug in jarsigner? Should it reject such files?
>
> The "jar u" way is to copy each old entry into destination unless the entry name is in the updated list where the new file will be read. Finally the untouched files in the updated list are appended.
Since tests were not originally for checking some unusual ways for 
updating jars, I think they need to be updated to use the "jar u" way 
for adding unsigned entry.

Artem
>