You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <de...@db.apache.org> on 2006/01/03 16:02:02 UTC
[jira] Created: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10
'store/encryptionKey.sql' fails on Solaris 10
---------------------------------------------
Key: DERBY-788
URL: http://issues.apache.org/jira/browse/DERBY-788
Project: Derby
Type: Bug
Components: Services, Test
Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
Environment: Solaris 10 (generic hardware)
Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
Reporter: Kristian Waagan
Assigned to: Kristian Waagan
Priority: Minor
Fix For: 10.2.0.0
The 'store/encryptionKey.sql' test fails on Solaris 10.
Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
Knut Anders Hatlen resolved DERBY-788:
--------------------------------------
Resolution: Fixed
Assign To: Kristian Waagan
Patch looks good. store/encryptionKey.sql does not fail under
Solaris 10 / Sun JVM 1.5.0. Derbyall passes without errors.
Committed revision 381333.
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=comments#action_12366473 ]
Kristian Waagan commented on DERBY-788:
---------------------------------------
For the cases I have tested, the exception comes from the Cipher.init method. The skf.translateKey seems to simply return what is passed in when it does not know what to do with the key. Note that the capabilities of the method depends on the implementation/provider.
I tried using AES instead of DES, but got a few errors. I suspect they are only minor changes in the error message that are reported, but I have not investigated.
I plan on rewriting this test to a JUnit test, but I am awaiting some JUnit framework commits. Then we could have the test run with both DES and AES with minimal changes and code duplication in the test.
My suggestion is that we create a new Jira issue to track the general problem regarding use of the skf.translageKey method (as Sunitha suggested), and that the 16 byte key is replaced with a 8 byte key to stop the test from failing in the regression test on Solaris10. I will start/do the rewrite during a few days if I don't get pushback.
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
Kristian Waagan reassigned DERBY-788:
-------------------------------------
Assign To: (was: Kristian Waagan)
According to the comment, Sunitha is having a look at the code/test. Awaiting feedback before we decide what to do with the test.
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=comments#action_12366257 ]
Sunitha Kambhampati commented on DERBY-788:
-------------------------------------------
there was some discussion on the derbydev list, cut & paste.
Kristian Waagan wrote:
>
> 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 lines.
>
> 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!
I looked at the test. As per the comments in the test, the tests are for testing using encryption using the encryptionKey. I dont think it is trying to pass in an invalid key length for DES.
So some possible options:
1) how about changing the algorithm to use AES , and in AES the cipher length is 16bytes. Is that available with the 'SunPCKS11-Solaris' ?
2) change the key length for DES ( as you suggest).
I'll look at the derby code too and see if we can/should be doing something else for DES or other algorithms and report back.
Thanks,
Sunitha.
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Andrew McIntyre (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
Andrew McIntyre resolved DERBY-788:
-----------------------------------
Fix Version: 10.1.3.0
10.1.2.4
Resolution: Fixed
Committed to 10.1 branch with revision 397972.
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.4
> Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Andrew McIntyre (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
Andrew McIntyre reopened DERBY-788:
-----------------------------------
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=comments#action_12366386 ]
Sunitha Kambhampati commented on DERBY-788:
-------------------------------------------
Since the test is testing the codepath when encryptionKey attribute is used, changing the test so it passes with the JCE provider on Solaris (SunPCKS11-Solaris) should be ok and I think this is what we should do ( either implement 1 or 2)
1) change test to either use DES with 8byte encryptionKey
2) change test to use AES algorithm with 16byte encryptionKey provided AES support is available with the PCKS11-Solaris.
That should solve the test failure issue and we would still be testing this case for encryptionKey.
Just as an fyi , I tried the first connection url with AES and it works ok with the Sun JCE with jdk 142 on windows.
=====================
That said, I think it is interesting that we cant expect the translateKey to always translate the key for us.
I found this in the java api for SecretKeySpec.
public SecretKeySpec(byte[] key,
String algorithm)Constructs a secret key from the given byte array.
This constructor does not check if the given bytes indeed specify a secret key of the specified algorithm. For example, if the algorithm is DES, this constructor does not check if key is 8 bytes long, and also does not check for weak or semi-weak keys. In order for those checks to be performed, an algorithm-specific key specification class (in this case: DESKeySpec) should be used.
In derby code, there is
// Since the key may be a series of bytes generated by an arbitary means
// we need to translate it into a key suitable for the algorithm.
secretKey = skf.translateKey(new SecretKeySpec(secretKey.getEncoded(), secretKey.getAlgorithm()));
I think you are right about - that we cannot assume that invalid key checks would not happen with the call. I looked at the Java api for 1.4.2 but I didnt find any AES specific KeySpec but found for others like DES and DESede.
I think we should open another jira so we can record what we learnt here so we can improve this.
Thanks Kristian for your analysis and following up on this jira.
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
Kristian Waagan updated DERBY-788:
----------------------------------
Other Info: [Patch available]
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
Kristian Waagan updated DERBY-788:
----------------------------------
Attachment: DERBY-788-1a.diff
DERBY-788-1a.stat
'DERBY-788-1a.diff' is a patch that replaces the 16 byte key with a 8 byte key for the DES encryption algorithm used in the test 'store/encryptionKey.sql'. The test still exercises the intended parts of the Derby code (according to my own analysis and that of Sunitha). The patch makes the test stop failing on Solaris10 (with security provider 'SunPCKS11-Solaris') .
One test case is changed; where it previously tested a key that was of incorrect length (longer than 8 bytes, shorter than 16), it now tests an incorrect key of the correct length. It is not possible to make the test pass on Solaris10 with a key of incorrect length, because keys of length less than 8 bytes are caught by a check in the code, and keys longer than 8 bytes cause the underlying security provider to fail ('SunPCKS11-Solaris'). This issue will be addressed in DERBY-1001 (rewrite of test to a JUnit-test).
Ran derbyall on Solaris10, which resulted in 6 known errors (some are already fixed according to the tinderbox test). 'store/encryptionKey.sql' passed.
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by Sunitha Kambhampati <ks...@gmail.com>.
Kristian Waagan wrote:
>
> 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 lines.
>
> 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!
I looked at the test. As per the comments in the test, the tests are
for testing using encryption using the encryptionKey. I dont think it
is trying to pass in an invalid key length for DES.
So some possible options:
1) how about changing the algorithm to use AES , and in AES the cipher
length is 16bytes. Is that available with the 'SunPCKS11-Solaris' ?
2) change the key length for DES ( as you suggest).
I'll look at the derby code too and see if we can/should be doing
something else for DES or other algorithms and report back.
Thanks,
Sunitha.
Re: [jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by Kristian Waagan <Kr...@Sun.COM>.
Myrna van Lunteren wrote:
> On 2/9/06, *Mike Matrigali* <mikem_app@sbcglobal.net
> <ma...@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
lines.
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!
--
Kristian
Re: [jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10
Posted by Andrew McIntyre <mc...@gmail.com>.
On Feb 9, 2006, at 4:15 PM, Myrna van Lunteren wrote:
> There is no platform-specific skipping, or diffing. (in the test
> harness)
I just want to say that the lack of diffing is somewhat by design.
Almost always, a difference in behavior on one platform (out of at
least 5 that are tested on a semi-regular basis) almost always
indicates a JVM bug, and should be addressed by the JVM vendor.
I admit, though, it would be nice to have a way to skip tests by
os.name with a property, something along the lines of
skipifos.name=SunOS, for situations like this.
andrew
Re: [jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10
Posted by Myrna van Lunteren <m....@gmail.com>.
On 2/9/06, Mike Matrigali <mi...@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
Re: [jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by Mike Matrigali <mi...@sbcglobal.net>.
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).
Kristian Waagan (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
>
> Kristian Waagan updated DERBY-788:
> ----------------------------------
>
> Component: Regression Test Failure
>
> Added component 'Regression Test Failure', as this test fails on Solaris10 with the 'SunPCKS11-Solaris' Java Security provider (which is the default provider). Will fail until the test is changed or the provider is changed/fixed. See earlier comment for more details.
>
>
>>'store/encryptionKey.sql' fails on Solaris 10
>>---------------------------------------------
>>
>> Key: DERBY-788
>> URL: http://issues.apache.org/jira/browse/DERBY-788
>> Project: Derby
>> Type: Bug
>> Components: Services, Test, Regression Test Failure
>> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
>> Environment: Solaris 10 (generic hardware)
>>Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
>> Reporter: Kristian Waagan
>> Assignee: Kristian Waagan
>> Priority: Minor
>> Fix For: 10.2.0.0
>
>
>>The 'store/encryptionKey.sql' test fails on Solaris 10.
>>Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
>>The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
>>The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
>
>
[jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
Kristian Waagan updated DERBY-788:
----------------------------------
Component: Regression Test Failure
Added component 'Regression Test Failure', as this test fails on Solaris10 with the 'SunPCKS11-Solaris' Java Security provider (which is the default provider). Will fail until the test is changed or the provider is changed/fixed. See earlier comment for more details.
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=comments#action_12367926 ]
Knut Anders Hatlen commented on DERBY-788:
------------------------------------------
I'm planning to review and commit this patch.
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=comments#action_12366388 ]
Sunitha Kambhampati commented on DERBY-788:
-------------------------------------------
One question - does the exception come from the Cipher.init , or the (SecretKeyFactory) skf.translateKey method ?
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
Kristian Waagan closed DERBY-788:
---------------------------------
Fix verified. Created DERBY-1088 to track general issues/weaknesses in the way external encryption keys are handled.
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=comments#action_12362838 ]
Kristian Waagan commented on DERBY-788:
---------------------------------------
I got a response to my inquiry about this issue:
"...it is not clearly defined how SecretKeyFactories and Ciphers behave when passed a key that is "too long". In most cases I would expect the two to behave the same. That means that even though your technique worked for DES and the providers you have tried, it may not work for other algorithms or providers."
This raises a few questions:
1) Is the approach used by Derby valid? (wrt. what we can expect from crypto providers)
Why allow the user to believe, say, a 512 byte key is used, when in fact only the first 8 bytes are used for encrypting/decrypting the database? Are we able to enforce a valid key length for a given algorithm? (without hardcoding limits in Derby code)
2) Why does the test use a 16 byte key for the DES algorithm?
Should it be changed to 8 byte, or is the test written to test the behavior of Derby when the key is not according to the specifications for the given algorithm?
I will take no further action until I get some feedback. Until a) the 'SunPCKS11-Solaris' is changed, b) the test is changed or c) another default provider is set for Solaris10, the test will continue to fail on Solaris10 (and probably higher versions).
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-788) 'store/encryptionKey.sql' fails on
Solaris 10
Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
Kristian Waagan closed DERBY-788:
---------------------------------
> 'store/encryptionKey.sql' fails on Solaris 10
> ---------------------------------------------
>
> Key: DERBY-788
> URL: http://issues.apache.org/jira/browse/DERBY-788
> Project: Derby
> Type: Bug
> Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.4
> Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior between the 'SunPCKS11-Solaris' provider and other providers (tested with 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified in the test) is not translated to a 8 byte DES key by SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 'impl.services.jce.JCECipherProvider'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira