[
https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434984#comment-17434984
]
Richard N. Hillegas commented on DERBY-7126:
--------------------------------------------
DatabaseClassLoader has instructions for signing a jar file used by the test
(see the method header for testSignedJar()). The instructions don't work any
more but can be fixed thusly:
{noformat}
keytool -delete -alias emccto -keystore emcks -storepass ab987c
keytool -genkey -keyalg "DSA" -validity 2555000 -dname "cn=EMC CTO,
ou=EMC APP, o=Easy Mail Company, c=US" -alias emccto -keystore emcks -storepass
ab987c
keytool -selfcert -alias emccto -validity 36500 -keystore emcks
-storepass ab987c
jarsigner -keystore emcks -storepass ab987c -signedjar dcl_emc2s.jar
dcl_emc2.jar emccto
{noformat}
With the regenerated jar file, 3 of the 4 failures go away. But one remains:
{noformat}
There was 1 failure:
1)
testHackedJarReplacedClass(org.apache.derbyTesting.functionTests.tests.lang.DatabaseClassLoadingTest)junit.framework.AssertionFailedError:
procedure call worked on hacked jar
at
org.apache.derbyTesting.functionTests.tests.lang.DatabaseClassLoadingTest.testHackedJarReplacedClass(DatabaseClassLoadingTest.java:585)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:51)
at
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:124)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:60)
FAILURES!!!
Tests run: 31, Failures: 1, Errors: 0
{noformat}
This is troubling because it means that Derby no longer detects
corrupted/hacked jar files. The problem is that Derby is expecting a class
loading error on the hacked jar file. But JDK 18 doesn't raise that error.
Maybe that is because the jar file was signed with SHA1 and JDK 18 doesn't
consider the jar to be signed at all.
The following program shows that the corrupted jar file raises class loading
errors under Java 11 but not under JDK 18 (see the attached DERBY_7126_A
program):
{noformat}
import java.io.File;
import java.net.URL;
import java.net.URLClassLoader;
public class DERBY_7126_A
{
private static final String CLASS_NAME =
"org.apache.derbyTesting.databaseclassloader.emc";
public static void main(String... args) throws Exception
{
String fileName = args[0];
URL fileURL = (new File(fileName)).toURI().toURL();
println(fileURL.toString());
println("Try to load a class from a corrupted jar file...");
try
{
URLClassLoader urlClassLoader = new URLClassLoader( new URL[] {
fileURL } );
Class<?> sampleClass = urlClassLoader.loadClass(CLASS_NAME);
println("Oops, unexpectedly loaded class " + sampleClass.getName());
} catch (SecurityException se)
{
println("Class correctly failed to load: " + se.toString());
}
}
private static void println(String text) { System.out.println(text); }
}
{noformat}
When I run this program thusly...
{noformat}
java DERBY_7126_A
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/lang/dcl_emc2sm.jar
{noformat}
...I get the following output under Java 11...
{noformat}
Try to load a class from a corrupted jar file...
Class correctly failed to load: java.lang.SecurityException: SHA1 digest error
for org/apache/derbyTesting/databaseclassloader/emc.class
{noformat}
...and the following output under Java 18:
{noformat}
Try to load a class from a corrupted jar file...
Oops, unexpectedly loaded class org.apache.derbyTesting.databaseclassloader.emc
{noformat}
I am confused about how to proceed:
1) I don't see any instructions for regenerating the hacked jar file so that
the test will do what it used to do.
2) I have misgivings about the JDK 18 behavior. I think that it would be better
for the JDK to raise an error when it encounters a jar file which was signed
with an SHA1 crytographic hash. Silently accepting a badly signed file seems
wrong to me.
3) I don't know how much time to invest in this problem. I don't know who uses
signed jar files in Derby. The Derby support for signed jar files seems very
minimal. At first blush, it seems that this security could be subverted by
replacing the jar file with an unsigned jar. See
https://db.apache.org/derby/docs/10.15/security/index.html
Maybe we should deprecate the Derby support for signed jar files and disable
these tests.
Does anyone understand the value provided by Derby's support for signed jar
files? Any suggestions about how to handle this failing test?
> 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
>
>
> 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)
