[ https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439382#comment-17439382 ]
Richard N. Hillegas commented on DERBY-7126: -------------------------------------------- The engineer responsible for the work on https://bugs.openjdk.java.net/browse/JDK-8269039 had this to say about the security regression we stumbled across. It appears that the Open JDK team is not going to fix this behavior: {noformat} Hello Rick, It is behaving as expected. Let me explain in more detail. First, loading a signed JAR off the classpath only verifies the signature and digests of the JAR file. It does not validate the signer's certificate chain or determine if the signer is trusted. The JarFile API class description includes this warning [1]: "Please note that the verification process does not include validating the signer's certificate. A caller should inspect the return value of JarEntry.getCodeSigners() to further determine if the signature can be trusted." Some frameworks such as Web Start have this additional checking built-in. Or, if you run your code with a Security Manager, then additional steps will be performed at run-time to check that the code is signed and that the signer's public key is trusted before granting permissions to that code. If you don't perform these additional steps, then the JAR can be modified without detection. For example, the signature related files could be removed from the JAR (thus making it an unsigned JAR), or the JAR could be modified and then re-signed with a different key. In either of these cases, the JVM would load the JAR without any exception. It is also possible that a JAR signed with a weak or broken algorithm (such as MD5 or SHA-1) could be modified without detection. This is why the JDK implementation supports several security properties which are used to disable cryptographic algorithms and protocols that are weak or broken. This provides out-of-the-box security and is important to safeguard against crypto algorithms that inevitably become weaker over time. One of these properties is "jdk.jar.disabledAlgorithms". The specification of this property defines the behavior if a signed JAR file is signed with an algorithm that is disabled [2]: "JARs signed with any of the disabled algorithms or key sizes will be treated as unsigned." The JDK determined after step 1 of the JAR verification process [3] that the JAR was signed with SHA-1, and therefore stopped further processing. You may ask why we don't throw an Exception in this case. Although this was considered, the compatibility risk was too high. These restrictions are nearly always backported to earlier JDK update releases. Throwing an Exception would be too high of a risk for applications that happen to load signed JARs off the classpath but don't otherwise behave any differently. Our primary focus is to protect applications that verify that the code is signed by someone they trust. Consider updating and re-signing your signed jar with a stronger, non-broken algorithm such as SHA-2. SHA-2 is the default digest algorithm used by jarsigner when the -digestalg option is not specified. I hope this information is useful. I do think this is an area where our javadocs and guides could be improved to provide more information about how signed JARs are verified including more details on the behavior of the JDK implementation with respect to disabled algorithms. We will be working to try to improve the docs for JDK 18. --Sean [1] https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/util/jar/JarFile.html [2] https://github.com/openjdk/jdk/blob/master/src/java.base/share/conf/security/java.security#L667 [3] https://docs.oracle.com/en/java/javase/17/docs/specs/jar/jar.html#signed-jar-file {noformat} I'm not sure how to address the fallout from this change. Here are some ideas: 1) Add a release note about this issue to the next Derby release (maybe update the download pages for the currently mirrored releases 10.15.2.0 and 10.14.2.0). 2) Remove support for signed jars files from our security documentation. I don't think that our support for signed jar files does enough to be worth advertising. The most significant part (verifying the identity of the signer) has always been left to the application. > Make it possible to build and test Derby cleanly with OpenJDK 18 > ---------------------------------------------------------------- > > Key: DERBY-7126 > URL: https://issues.apache.org/jira/browse/DERBY-7126 > Project: Derby > Issue Type: Task > Components: Build tools > Affects Versions: 10.16.0.0 > Reporter: Richard N. Hillegas > Assignee: Richard N. Hillegas > Priority: Major > Attachments: DERBY_7126_A.java, dcl_emc2sm.jar, > derby-7126-01-aa-regenerateSignedJars.diff > > > Releases of Open JDK 18 can be found at https://jdk.java.net/178. We should > adjust Derby as necessary so that it builds cleanly (including javadoc) and > tests cleanly with this version of the platform. -- This message was sent by Atlassian Jira (v8.3.4#803005)