Hi Mathias,
Good Catch, this might be broken in 10.1 branch too. Please file a
Jira entry for the problem and attach your patch; that way we won't
lose it in the e-mails.
I think the verifyKey file can be read by wrapping the file
InputStream with a DataInputStream instead of reading it as
RandomAccessFile in the JCECipherFactory itself. If that works then
there is no need to add InputStreamRandomAccessFile.java class.
Thanks
-suresh
Mathias Herberts wrote:
The current trunk (410361) does not allow to have encrypted databases
using encryptionKey with the jar subprotocol (and probably also the
http/https and classpath subprotocols also).
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.
Included in this email is 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.
Also included in this email is a patch to
org/apache/derby/impl/io/InputStreamFile.java so the
getRandomAccessFile creates an instance of InputStreamRandomAccessFile
instead of returning null.
I have tested my patch with an encrypted db accessed via the jar
subprotocol, it has not been tested with any other subprotocol.
Regards,
Mathias.
------------------------------------------------------------------------
package org.apache.derby.impl.io;
import java.io.DataInput;
import java.io.DataOutput;
import java.io.EOFException;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.InputStream;
import org.apache.derby.io.StorageRandomAccessFile;
public class InputStreamRandomAccessFile implements DataInput, DataOutput,
StorageRandomAccessFile {
private InputStream is = null;
public InputStreamRandomAccessFile (InputStreamFile isf) throws
FileNotFoundException {
this.is = isf.getInputStream();
}
...<snip>
