db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathias Herberts (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1373) Encrypted databases cannot be booted using the jar subprotocol (and possibly also using http/https/classpath)
Date Sun, 25 Jun 2006 12:34:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1373?page=comments#action_12417674 ] 

Mathias Herberts commented on DERBY-1373:
-----------------------------------------

I had a look to the suggestion Suresh made. Implementing his idea would require changes to
JCECipherFactory to return a RandomAccessFile when the verifyKey file has to be written (created)
and a DataInput when it has to be read. This is a change I do not have time to implement as
it would mean revalidate all other cases which are currently working.

Therefore I'll stick with my initial fix consisting in adding an InputStreamRandomAccessFile
class.

As for a test I do not see an easy way of implementing it as it requires to create a DB with
encryption, package it into a jar and boot it from the jar. I do not know how to do that simply
using JUnit. What I could think of would imply running Ant from the test to create a jar file
and then access it. I do not know if this is the cleanest way to do it.
 

> Encrypted databases cannot be booted using the jar subprotocol (and possibly also using
http/https/classpath)
> -------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1373
>          URL: http://issues.apache.org/jira/browse/DERBY-1373
>      Project: Derby
>         Type: Bug

>   Components: Store
>     Versions: 10.1.2.4
>  Environment: Environment does not matter.
>     Reporter: Mathias Herberts
>     Assignee: Mathias Herberts
>      Fix For: 10.2.0.0
>  Attachments: InputStreamFile.java-patch, InputStreamRandomAccessFile.java
>
> An encrypted database cannot be booted when using the jar subprotocol.
> The problem lies in the method run from JCECipherFactory. The call to getRandomAccessFile
returns null when the verifyKeyFile is an instance of InputStreamFile and the key verification
therefore fails.
> The implementation of getRandomAccessFile for InputStreamFile states that its code cannot
be reached which is untrue.
> The provided patch does two things, it provides a new class InputStreamRandomAccessFile
in package org.apache.derby.impl.io. This class provides simple implementations of readInt
and readFully so the key verification process succeeds. A quick scan of the derby source tree
showed no problem or possible impact of this simple implementation.
> The second thing the patch does is to modify org/apache/derby/impl/io/InputStreamFile.java
so the getRandomAccessFile creates an instance of InputStreamRandomAccessFile instead of returning
null.
> This patch has been tested against trunk 410361. It solves the problem at least under
the jar subprotocol.
> The patch has not been tested against http/https/classpath.

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