db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3711) convert store/aes.sql to junit test & add unrestricted test cases.
Date Wed, 11 Jun 2008 14:18:45 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604228#action_12604228

Myrna van Lunteren commented on DERBY-3711:

You're right, I happily stole some setup code from EncryptionKeyTest and its subclass EncryptionKeyAESTest.

The tests do test different things; the old aes.sql test had one test case (case 5) which
was indeed covered in EncryptionKeyAESTest so I didn't include that in the new Encryption
AESTest. The Encryption Key*Test covers using the 'encryptionKey' attribute; EncryptionAESTEst
(as well as several other encryption tests) test with 'bootPassword'.

I was focused solely on converting aes.sql while adding testing for larger (non-exportable
for US) keylengths.

Now that I look, it seems
- reasonable to test various feedback modes with other algorithms (testFeedBackModes fixture)
- based on the code coverage results you'd think there's room for testing unsupported padding
strings, but what else can we test except that anything except 'NoPadding' is invalid? Some
of the other encryption .sql tests check this also.
- some further testing with other keylengths might be useful to other algorithms, especially
using keylengthbits-EncodedKeyLength format, but the 128/192/256 is specific to AES.

While looking, I noticed also that
- there is reference in one of the presentations (one by jean, one by dan) of derby.encryptionBlockSize,
but I find no test of that at all
- the reference manual doesn't mention the property encryptionKeyLength

I have no plans at this time to extend the feedbackmode testing to other algorithms nor to
add testing for constructions like 'encryptionKeyLength=56-8' (valid for DES; what happens
with other algorithms?), but they might be interesting.

> convert store/aes.sql to junit test & add unrestricted test cases.
> ------------------------------------------------------------------
>                 Key: DERBY-3711
>                 URL: https://issues.apache.org/jira/browse/DERBY-3711
>             Project: Derby
>          Issue Type: Task
>          Components: Test
>            Reporter: Myrna van Lunteren
>            Assignee: Myrna van Lunteren
>            Priority: Minor
>             Fix For:
>         Attachments: DERBY-3711-2.diff, DERBY-3711-2.stat, DERBY-3711_1.diff
> The store/aes.sql test can, because it's a master-based test, only test what's guaranteed
available, i.e. only the encryptionKeyLength=128.
> If it were a junit test, we could make it ignore the expected failures if the larger
key sizes weren't supported, but test otherwise.
> Having a junit test doesn't guarantee the test would get executed, of course, but at
least the test would exist. 
> Would it be useful/ok to have a message print to the console as a warning?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message