db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <derby-...@db.apache.org>
Subject [jira] Reopened: (DERBY-746) NullPointerException when 'encryptionKey' length is an odd number, or it contains invalid chars
Date Fri, 28 Apr 2006 13:30:39 GMT
     [ http://issues.apache.org/jira/browse/DERBY-746?page=all ]
     
Kristian Waagan reopened DERBY-746:
-----------------------------------


Reopening to port to 10.1.3 maintenance release.

Merge commands, executed from the 10.1 branch directory:
svn merge -r 365784:365785 https://svn.apache.org/repos/asf/db/derby/code/trunk/
svn merge -r 367711:367712 https://svn.apache.org/repos/asf/db/derby/code/trunk/

I ran derbyall with JDK 1.5 (Solaris 10) and got 4 errors, of which I can account for 2 of
them:
derbyall/derbynetclientmats/derbynetmats.fail:derbynet/dataSourcePermissions_net.java
derbyall/encryptionAll/encryptionAll.fail:store/aes.sql (due to JDK 1.5, ok with JDK 1.4)
derbyall/encryptionAll/encryptionAll.fail:store/encryptionKey.sql (ok, see DERBY-788)
derbyall/derbyall.fail:unit/T_Diagnosticable.unit

Don't think the other failures are related to the port, I see other people have gotten them
as well.

Should DERBY-788 BE PORTED as well? It is only a test fix.


> NullPointerException when 'encryptionKey' length is an odd number, or it contains invalid
chars
> -----------------------------------------------------------------------------------------------
>
>          Key: DERBY-746
>          URL: http://issues.apache.org/jira/browse/DERBY-746
>      Project: Derby
>         Type: Bug

>   Components: Security
>     Versions: 10.1.1.2, 10.1.2.1, 10.2.0.0, 10.1.3.0, 10.1.2.2
>  Environment: All environments.
>     Reporter: Kristian Waagan
>     Assignee: Kristian Waagan
>     Priority: Minor
>      Fix For: 10.2.0.0
>  Attachments: derby-746.diff, derby-746.stat, derby-746a.diff, derby-746a.stat
>
> When booting/creating an encrypted database, a NullPointerException is thrown if the
length of the connection string attribute 'encryptionKey' is an odd number, or the encryption
key contains invalid characters for hexadecimal numbers (char not in the set [0-9a-fA-F]).
> The reason for the exception being thrown, is that the method 'iapi.util.StringUtil.fromHexString(String,
int, int)' returns null for the cases described above. The code calling the method in 'JCECipherFactory.boot(boolean,
Properties)' does not check that the return value is not null.
> A related trivial issue is that 'fromHexString' does not allow the caller to see the
distinction between a string with invalid length and a string containing invalid characters
(both cases return null).
> [To reproduce]
> (connection string copied from test 'store/encryptionKey.sql' and then modified)
> Supply the following connection string, for instance in ij:
> connect 'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656';
> (deleted the last digit in the encryption key)
> 'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656X';
> (replaced last digit with an X)

-- 
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


Mime
View raw message