From derby-dev-return-20291-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Tue May 09 20:16:09 2006 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 9475 invoked from network); 9 May 2006 20:16:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 May 2006 20:16:08 -0000 Received: (qmail 4519 invoked by uid 500); 9 May 2006 20:15:54 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 4478 invoked by uid 500); 9 May 2006 20:15:53 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 4468 invoked by uid 99); 9 May 2006 20:15:53 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 May 2006 13:15:53 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 May 2006 13:15:52 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 8894E41000B for ; Tue, 9 May 2006 20:15:05 +0000 (GMT) Message-ID: <8355855.1147205705556.JavaMail.jira@brutus> Date: Tue, 9 May 2006 20:15:05 +0000 (GMT+00:00) From: "Suresh Thalamati (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-1156) allow the encrypting of an existing unencrypted db and allow the re-encrypting of an existing encrypted db In-Reply-To: <906547337.1143541201736.JavaMail.jira@ajax> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-1156?page=all ] Suresh Thalamati updated DERBY-1156: ------------------------------------ Attachment: reencrypt_1.diff DERBY -1156 ( first patch) This patch adds some code required to support to configure an existing database for encryption of an un-encrypted database. Users can now specify the dataEncryption=true attribute along with other encryption attributed to encrypt an existing un-encrypted database at boot time. This patch implements encryption of an existing data in the database with new encryption key and also added new log operation requried to restore the database to its original state incase of crash/error. This patch also adds a test to test encryption of an un-encrypted database. TESTS : derbyall test suite passed on Windows XP/JDK142 It would be great if some can review and commit this patch. svn stat: M java\engine\org\apache\derby\impl\services\jce\JCECipherFactory.java M java\engine\org\apache\derby\impl\store\raw\log\ReadOnly.java M java\engine\org\apache\derby\impl\store\raw\log\LogToFile.java M java\engine\org\apache\derby\impl\store\raw\RawStore.java A java\engine\org\apache\derby\impl\store\raw\data\EncryptData.java M java\engine\org\apache\derby\impl\store\raw\data\InputStreamContainer.java M java\engine\org\apache\derby\impl\store\raw\data\BaseDataFileFactory.java M java\engine\org\apache\derby\impl\store\raw\data\StreamFileContainer.java M java\engine\org\apache\derby\impl\store\raw\data\FileContainer.java A java\engine\org\apache\derby\impl\store\raw\data\EncryptContainerUndoOperation.java A java\engine\org\apache\derby\impl\store\raw\data\EncryptContainerOperation.java M java\engine\org\apache\derby\impl\store\raw\data\BaseContainer.java M java\engine\org\apache\derby\impl\store\raw\data\BaseContainerHandle.java M java\engine\org\apache\derby\impl\store\raw\data\RAFContainer.java M java\engine\org\apache\derby\iapi\services\crypto\CipherFactory.java M java\engine\org\apache\derby\iapi\services\io\RegisteredFormatIds.java M java\engine\org\apache\derby\iapi\services\io\StoredFormatIds.java M java\engine\org\apache\derby\iapi\store\raw\log\LogFactory.java M java\engine\org\apache\derby\iapi\store\raw\data\DataFactory.java M java\engine\org\apache\derby\iapi\store\raw\data\RawContainerHandle.java M java\engine\org\apache\derby\iapi\store\raw\RawStoreFactory.java A java\testing\org\apache\derbyTesting\functionTests\tests\store\encryptDatabaseTest1.sql M java\testing\org\apache\derbyTesting\functionTests\tests\store\copyfiles.ant A java\testing\org\apache\derbyTesting\functionTests\tests\store\encryptDatabaseTest1_app.properties A java\testing\org\apache\derbyTesting\functionTests\master\encryptDatabaseTest1.out M java\testing\org\apache\derbyTesting\functionTests\suites\encryptionAll.runall > allow the encrypting of an existing unencrypted db and allow the re-encrypting of an existing encrypted db > ---------------------------------------------------------------------------------------------------------- > > Key: DERBY-1156 > URL: http://issues.apache.org/jira/browse/DERBY-1156 > Project: Derby > Type: Improvement > Components: Store > Versions: 10.1.2.3 > Reporter: Mike Matrigali > Assignee: Suresh Thalamati > Priority: Minor > Fix For: 10.2.0.0 > Attachments: encryptspec.html, reencrypt_1.diff > > encrypted database to be re-encrypted with a new password. > Here are some ideas for an initial implementation. > The easiest way to do this is to make sure we have exclusive access to the > data and that no log is required in the new copy of the db. I want to avoid > the log as it also is encrypted. Here is my VERY high level plan: > 1) Force exclusive access by putting all the work in the low level store, > offline boot method. We will do redo recovery as usual, but at the end > there will be an entry point to do the copy/encrypt operation. > copy/encrypt process: > 0) The request to encrypt/re-encrypt the db will be handled with a new set > of url flags passed into store at boot time. The new flags will provide > the same inputs as the current encrypt flags. So at high level the > request will be "connect db old_encrypt_url_flags; new_encrypt_url_flags". > TODO - provide exact new flag syntax. > 1) Open a transaction do all logged work to do the encryption. All logging > will be done with existing encryption. > 2) Copy and encrypt every db file in the database. The target files will > be in the data directory. There will be a new suffix to track the new > files, similar to the current process used for handling drop table in > a transaction consistent manner without logging the entire table to the log. > Entire encrypted destination file is guaranteed synced to disk before > transaction commits. I don't think this part needs to be logged. > Files will be read from the cache using existing mechanism and written > directly into new encrypted files (new encrypted data does not end up in > the cache). > 3) Switch encrypted files for old files. Do this under a new log operation > so the process can be correctly rolled back if the encrypt db operation > transaction fails. Rollback will do file at a time switches, no reading > of encrypted data is necessary. > 4) log a "change encryption of db" log record, but do not update > system.properties with the change. > 5) commit transaction. > 6) update system.properties and sync changes. > 7) TODO - need someway to handle crash between steps 5 and 6. > 6) checkpoint all data, at this point guaranteed that there is no outstanding > transaction, so after checkpoint is done there is no need for the log. > ISSUES: > o there probably should be something that catches a request to encrypt to > whatever db was already encrypted with. -- 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