Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Sun, 11 Nov 2012 19:31:14 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <332504954.98112.1352662274358.JavaMail.jiratomcat@arcas>
In-Reply-To: <499139948.40460.1351540092229.JavaMail.jiratomcat@arcas>
Subject: [jira] [Comment Edited] (DERBY-5970) Check that connection
 attributes have legal values.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494944#comment-13494944 ] 

Knut Anders Hatlen edited comment on DERBY-5970 at 11/11/12 7:30 PM:
---------------------------------------------------------------------

DERBY-5907 suggests that we move that logic out of ij. After support for warnings on connect calls is added to the client, that is.
                
      was (Author: knutanders):
    DERBY-5907 suggests that we move that logic from ij. After support for warnings on connect calls is added to the client, that is.
                  
> Check that connection attributes have legal values.
> ---------------------------------------------------
>
>                 Key: DERBY-5970
>                 URL: https://issues.apache.org/jira/browse/DERBY-5970
>             Project: Derby
>          Issue Type: Bug
>          Components: Services
>    Affects Versions: 10.10.0.0
>            Reporter: Rick Hillegas
>         Attachments: AttributeChecks.html, derby-5970-01-aa-vetDecryptDatabaseValue.diff, derby-5970-01-ab-vetDecryptDatabaseValue.diff, derby-5970-02-aa-vetDataEncryptionValue.diff
>
>
> At boot time, Derby does not check whether connection attributes are set to legal values. This can cause them to be silently ignored. In the case of security operations like re(un)encryption, these silent failures deceive the DBO into thinking that the security behavior of the database has changed when, in fact, it hasn't. We should do the following:
> 1) Prevent decryptDatabase from being set to an illegal value. Since this is a new attribute, there are no backward compatibility issues.
> 2) Evaluate other attributes on a case-by-case basis to determine which ones should raise exceptions if they are set to illegal values. Technically, this may result in backwardly incompatible behavior. However, I think that for most attributes, we will decide that the incompatibility is minor and is a welcome bugfix.

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