db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5970) Check that connection attributes have legal values.
Date Mon, 19 Nov 2012 15:38:58 GMT

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

Knut Anders Hatlen commented on DERBY-5970:
-------------------------------------------

Thanks for writing this up so systematically, Rick. The proposed changes look reasonable to
me.

For the drop attribute, I think it would be OK to throw an exception rather than a warning
if it's set to an invalid value. Applications that break because of that change have a bug
and need fixing, so I wouldn't worry about backward compatibility in that particular case.

failover: Should we raise an error when the value is not true/false, for consistency with
the proposed changes for the other replication attributes?
                
> 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, 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

Mime
View raw message