JDK-8031748 : Clarify jar entry orders in a jar file
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2014-01-15
  • Updated: 2022-03-10
  • Resolved: 2022-03-10
Related Reports
Relates :  
JDK-8021788 - JarInputStream doesn't provide certificates for some file under META-INF
Relates :  
JDK-8031572 - jarsigner -verify exits with 0 when a jar file is not properly signed
Description
From the beginning, the jar file has an “undocumented” assumption that the MANIFEST.MF file and signature-related files (block and SF) should appear at the beginning (except for directory entries, say, META-INF/). Otherwise, depending on if we open the file as a JarFile or as a JarInputStream, a file can be treated sometimes as signed and sometimes not (JDK-8021788). We need to clarify this in the javadoc.

Precisely, if opened as JarFile, we will support any entries order (JDK-8031572). If opened as JarInputStream, MANIFEST.MF must be at the beginning, and supported signature-related files follow (one exception, META-INF/). Otherwise, the behavior is not defined.

An @implNote should be added to JarInputStream documenting the constraints.
Comments
The jarsigner tool and the JarSigner API both add entries after the signature related files, so this issue can only occur if an application is using custom signing code. I'm closing this as "Won't Fix". Unless we see evidence of this issue occurring more in practice, I don't think it is that useful to add an @implNote to the JarInputStream javadocs.
10-03-2022
Now there are 2 kinds of entries: signature-related (plus MANIFEST.MF) and others. The latter contains all normal entries and other non-signature-related entries in META-INF, and there is no difference between them. Do you mean we only cache META-INF entries because they are more likely to be before signature-related files? Anyway, caching then need extra memory but more inconvenient is that before signature files are read a JarEntry's getCertificates() returns null. And then, when the signature file is read, it suddenly throws an exception saying verification fails. So this is somewhat doable but will be quite difficult to describe the behavior.
23-01-2014
If the entries are not in the right order, can we instead read and cache the entries in META-INF until we find the Manifest and signature files, and then go back and verify them?
22-01-2014