ZipFile.isSignatureRelated returns true for files in META-INF subdirectories

Sean Mullan sean.mullan at oracle.com
Fri Jan 13 20:42:47 UTC 2023


Sure, no problem. I filed https://bugs.openjdk.org/browse/JDK-8300140 
for this issue.

Thanks,
Sean

On 1/13/23 12:22 PM, Eirik Bjørsnøs wrote:
> Sean,
> 
> I'm not an Author (yet! :), so I can't log in to JBS and create issues.
> 
> I guess the title and description of the draft PR could serve as a 
> starting point for a bug.
> 
> Note that the Jar File Specification does explicitly say:
> 
> "Note that if such files are located in META-INF subdirectories, they 
> are not considered signature-related"
> 
> Thanks,
> Eirik.
> 
> On Fri, Jan 13, 2023 at 6:17 PM Sean Mullan <sean.mullan at oracle.com 
> <mailto:sean.mullan at oracle.com>> wrote:
> 
>     Off hand it seems like a bug to me, can you file one? The jar
>     specification says that the SF file resides in the META-INF directory
>     and says nothing about subdirectories.
> 
>     --Sean
> 
>     On 1/13/23 6:40 AM, Eirik Bjørsnøs wrote:
>      > Thanks for forwarding me to the right list, Alan
>      >
>      > For context, I posted a follow-up on the core-libs-dev thread
>     yesterday
>      > showing that some other methods have the same problem:
>      >
>      >
>     https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/098656.html <https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/098656.html> <https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/098656.html <https://mail.openjdk.org/pipermail/core-libs-dev/2023-January/098656.html>>
>      >
>      > And here's a draft PR for a fix, including a test which provokes the
>      > various code paths:
>      >
>      > https://github.com/openjdk/jdk/pull/11976
>     <https://github.com/openjdk/jdk/pull/11976>
>      > <https://github.com/openjdk/jdk/pull/11976
>     <https://github.com/openjdk/jdk/pull/11976>>
>      >
>      > Cheers,
>      > Eirik.
>      >
>      >
>      > On Fri, Jan 13, 2023 at 9:32 AM Alan Bateman
>     <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>
>      > <mailto:Alan.Bateman at oracle.com
>     <mailto:Alan.Bateman at oracle.com>>> wrote:
>      >
>      >
>      >     Forwarding to security-dev as that is where issues around signed
>      >     JARs are usually discussed.
>      >
>      >     -Alan.
>      >
>      >
>      >     On 10/01/2023 17:00, Eirik Bjørsnøs wrote:
>      >>     Hi,
>      >>
>      >>     ZipFile.isSignatureRelated currently returns true for paths such
>      >>     as the following:
>      >>
>      >>   
>       META-INF/libraries/org.bouncycastle:bcprov-jdk15on:jar-1.70/META-INF/BC2048KE.DSA
>      >>
>      >>     While this path does start with "META-INF/" and ends with
>     ".DSA",
>      >>     the file does not live in the META-INF/ directory
>     _directly_, but
>      >>     rather several directories below.
>      >>
>      >>     This causes such .DSA files to be incorrectly (?) included
>     in the
>      >>     verification of META-INF/MANIFEST.MF in
>      >>     JarFile.initializeVerifier, which then fails with:
>      >>
>      >>         Exception in thread "main" java.lang.SecurityException:
>      >>         Invalid signature file digest for Manifest main attributes
>      >>         at
>      >>       
>       java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:340)
>      >>         at
>      >>       
>       java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:282)
>      >>         at
>      >>       
>       java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:327)
>      >>         at
>      >>       
>       java.base/java.util.jar.JarVerifier.update(JarVerifier.java:239)
>      >>         at
>      >>       
>       java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:760)
>      >>         at
>      >>       
>       java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1058)
>      >>         at
>      >>       
>       java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:72)
>      >>         at
>      >>       
>       java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:883)
>      >>         at
>      >>       
>       java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:848)
>      >>         at
>      >>       
>       java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
>      >>         at
>      >>       
>       java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
>      >>         at
>      >>       
>       java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
>      >>         at
>      >>       
>       java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>      >>         at
>      >>       
>       java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>      >>
>      >>
>      >>     A few questions:
>      >>
>      >>     1: Where Is the exact location of signature related files
>     specified?
>      >>
>      >>     2: Is the current behaviour indeed incorrect?
>      >>
>      >>     3: Should ZipFile.isSignatureRelated be updated such that it
>     only
>      >>     matches signature related files which reside exactly in
>     "META-INF/" ?
>      >>
>      >>     The context for this is that I'm making a fat jar Maven plugin
>      >>     which embeds dependency jars by "unpacking" them into
>      >>     subdirectories of META-INF/libraries/.
>      >>
>      >>     Cheers,
>      >>     Eirik.
>      >
> 



More information about the security-dev mailing list