db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10
Date Fri, 10 Feb 2006 01:47:38 GMT
Myrna van Lunteren wrote:
> On 2/9/06, *Mike Matrigali* <mikem_app@sbcglobal.net 
> <mailto:mikem_app@sbcglobal.net>> wrote:
>     It would seem reasonable to mark this test to not run in nightly
>     under solaris 10 until you resolve the jvm issue or change the test.
>     Maybe someone can give some hints if this is possible under the
>     current test harness (I know it is pretty easy to mark not run
>     under a specific JVM, just not sure of OS).
> The only way to handle os-specific details right now is to modify the 
> test, or, for .sql files the *only* solution, to mask differing lines 
> in the output using a <test>_sed.properties file, if the test doesn't 
> fail too miserably.
> There is no platform-specific skipping, or diffing.
> Myrna

The test does fail too miserably :)

Actually, the test won't be able to create the encrypted database, which 
is the initial step for almost all test cases exercised by the ij script.

An alternative solution would be to reduce the key length, as I have 
described in the Jira issue. Since there are no comments about the key 
length, I do not know if the test was written to test the handling of 
keys that are too long, or if the key is just too long (for the 
specified encryption algorithm) for some other reason. We could perhaps 
modify the test to use a key of correct length for all test cases except 
one, and then use Myrna's trick of using sed to mask out the differing 

Just for information, the code block where things go wrong is a 
try-catch. If the code inside the try block fails, a security provider 
method is executed in the catch block to translate the apparently 
invalid key to a valid key. Then the same steps as those inside the try 
block are retried. If it fails again (but this time in the catch block - 
the code is duplicated), i.e. the key was/could not be translated to a 
valid key, the exception from the Cipher.init method is wrapped and thrown.

I would appreciate some more information of what the test is actually 
written to test before I go ahead and change it!


View raw message