RFR: 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed

Wang Weijun weijun.wang at oracle.com
Fri Jan 24 15:19:41 PST 2014


On Jan 24, 2014, at 23:55, Sean Mullan <sean.mullan at oracle.com> wrote:

> In JarFile, I think you should also upper-case the entry names before passing to SignatureFileVerifier.isBlockOrSF, as all other calls to this method in the JDK do that. The jar specification says that these filenames are case-insensitive, so a file named "*.rsa" should also be treated as a signature file.

Good.

> 
> Looks good otherwise, although I couldn't see any difference between the 8 and 9 fix.

In 9, there is a new code change (8030851: Update code in java.util to use newer language features)

@@ -356,8 +356,8 @@
         try {
             String[] names = getMetaInfEntryNames();
             if (names != null) {
-                for (int i = 0; i < names.length; i++) {
-                    JarEntry e = getJarEntry(names[i]);
+                for (String name : names) {
+                    JarEntry e = getJarEntry(name);
                     if (e == null) {
                         throw new JarException("corrupted jar file");
                     }

so all names[i] become name.

Thanks
Max

> --Sean
> 
> On 01/22/2014 02:01 AM, Wang Weijun wrote:
>> Hi All
>> 
>> Please take a look at the webrev at
>> 
>>    http://cr.openjdk.java.net/~weijun/8031572/8/webrev.00/
>> 
>> JarVerifier has a flag that separates parsing signatures and verifying other entries. The fix makes sure only signature-related files are processed in the beginning so JarVerifier does not enter the second stage prematurely. Please note that JarInputStream always feeds JarVerifier by natural order so once a non-signatued-related file is processed it goes into verification stage and will not parse a signature anymore.
>> 
>> Maybe a smarter solution is to be *always on alert*, which means at anytime an incoming entry can be anything, so that even if signature-related files appear at the middle of a file, at least those come after them can be treated as signed when opening with a JarInputStream. This will be a huge change to the JarVerifier class and IMHO does not really help much. Also I don’t want to consider it at this final time of JDK 8.
>> 
>> You can also find webrevs for jdk9 and jdk7u at
>> 
>>    http://cr.openjdk.java.net/~weijun/8031572/webrev.00/
>> 
>> and
>> 
>>    http://cr.openjdk.java.net/~weijun/8031572/7/webrev.00/
>> 
>> There are some tiny differences. For 9, the JarVerifier fix needs to be rebased on a language style changeset.  For 7u, there are some differences in the test because of class name change, implicit final, and default method.
>> 
>> Thanks
>> Max
>> 
> 



More information about the security-dev mailing list