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