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
