Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 76616D119 for ; Tue, 18 Sep 2012 15:54:08 +0000 (UTC) Received: (qmail 80127 invoked by uid 500); 18 Sep 2012 15:54:08 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 80099 invoked by uid 500); 18 Sep 2012 15:54:08 -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 80091 invoked by uid 99); 18 Sep 2012 15:54:08 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Sep 2012 15:54:08 +0000 Date: Wed, 19 Sep 2012 02:54:08 +1100 (NCT) From: "Kim Haase (JIRA)" To: derby-dev@db.apache.org Message-ID: <1354844824.92781.1347983648257.JavaMail.jiratomcat@arcas> In-Reply-To: <409367018.16174.1338385403126.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Commented] (DERBY-5792) Make it possible to turn off encryption on an already encrypted database. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DERBY-5792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13457897#comment-13457897 ] Kim Haase commented on DERBY-5792: ---------------------------------- I agree that using "dataEncryption=false" would create confusion -- currently that does seem to mean the same thing as not specifying anything, though it's not documented. Also, I think it might make more sense to use "decryptDatabase=true" than to use "dataDecryption=true". If the decryption attribute is very different from the encryption one, people will be less likely to specify the wrong attribute by accident. The one-time operation point seems a bit less compelling, if my guess (just a guess) is correct that "dataEncryption=true" is also a one-time operation? Or can you re-encrypt an encrypted database, changing from, say, one encryption algorithm to another? Would that work, or would it totally mess up your database? Anyway, I think reducing the possibility of confusion is desirable. The docs say, "The dataEncryption attribute must be combined with the bootPassword=key attribute or the newEncryptionKey=key attribute." But what it should say is "The dataEncryption=true attribute must be combined ..." It might also make sense to document the meaning of "false" explicitly. (If I specify false, I don't get an error message if I don't specify a key.) I'm finding various issues with the encryption documentation as I poke through it -- for example, the "encryptionAlgorithm" topic doesn't say that you can use that attribute in combination with the "encryptionKey" one, though the "encryptionKey" topic has an example showing exactly that. Also, the Developer's Guide has one main section on encryption under "Derby and Security" and several more topics under "Working with the database connection URL attributes". Might be a good idea to overhaul some of this. > Make it possible to turn off encryption on an already encrypted database. > ------------------------------------------------------------------------- > > Key: DERBY-5792 > URL: https://issues.apache.org/jira/browse/DERBY-5792 > Project: Derby > Issue Type: Improvement > Components: JDBC, Store > Affects Versions: 10.10.0.0 > Reporter: Rick Hillegas > Assignee: Kristian Waagan > Attachments: derby-5792-1a-boilerplate_and_preparation.diff > > > Currently, you can encrypt an unencrypted database and you can change the encryption key on an already encrypted database. However, Derby does not expose a way to turn off (unencrypt) an already encrypted database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira