You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <ji...@apache.org> on 2012/10/29 20:48:12 UTC
[jira] [Created] (DERBY-5970) Check that connection attributes have
legal values.
Rick Hillegas created DERBY-5970:
------------------------------------
Summary: 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
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
[jira] [Commented] (DERBY-5970) Check that connection attributes
have legal values.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488989#comment-13488989 ]
Rick Hillegas commented on DERBY-5970:
--------------------------------------
Tests passed cleanly for me on derby-5970-02-aa-vetDataEncryptionValue.diff.
> 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: 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
[jira] [Comment Edited] (DERBY-5970) Check that connection
attributes have legal values.
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (DERBY-5970) Check that connection attributes have
legal values.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-5970:
---------------------------------
Attachment: derby-5970-02-aa-vetDataEncryptionValue.diff
Attaching derby-5970-02-aa-vetDataEncryptionValue.diff. This patch causes Derby to raise an exception if the dataEncryption attribute is set to a value other than true. I will run regression tests.
Touches the following files:
-------------------
M java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java
Raise an exception of dataEncryption is set but is not set to true.
-------------------
M java/testing/org/apache/derbyTesting/functionTests/master/URLCheck.out
Verify that an exception is raised if dataEncryption is set to something other than true.
> 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: 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
[jira] [Updated] (DERBY-5970) Check that connection attributes have
legal values.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-5970:
---------------------------------
Attachment: AttributeChecks.html
Thanks for that additional feedback, Knut. Attaching a fourth rev of the spec, which incorporates that suggestion.
> 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, 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
[jira] [Updated] (DERBY-5970) Check that connection attributes have
legal values.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-5970:
---------------------------------
Attachment: AttributeChecks.html
Attaching AttributeChecks.html. This summarizes Derby's behavior when processing URL attributes with bad values. This may inform additional work done on this issue.
> 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
[jira] [Commented] (DERBY-5970) Check that connection attributes
have legal values.
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (DERBY-5970) Check that connection attributes
have legal values.
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501989#comment-13501989 ]
Knut Anders Hatlen commented on DERBY-5970:
-------------------------------------------
territory: The reference manual says one place that it can be used on creation and on upgrade, another place it says only on creation. I tried it and found that the territory attribute had no effect on upgrade (will file a JIRA to fix the docs). If that's correct, we should probably also raise a warning if territory is set on upgrade.
> 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, 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
[jira] [Updated] (DERBY-5970) Check that connection attributes have
legal values.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-5970:
---------------------------------
Attachment: derby-5970-01-aa-vetDecryptDatabaseValue.diff
Attaching derby-5970-01-aa-vetDecryptDatabaseValue.diff. This patch makes Derby raise an exception if the decryptDatabase attribute is set and it is set to some value other than "true". I am running regression tests now.
Touches the following files
------------
M java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java
Vet the value of decryptDatabase early on while processing the connection request.
------------
M java/testing/org/apache/derbyTesting/functionTests/tests/store/DecryptDatabaseTest.java
Add a test case.
> 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: derby-5970-01-aa-vetDecryptDatabaseValue.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
[jira] [Commented] (DERBY-5970) Check that connection attributes
have legal values.
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486915#comment-13486915 ]
Knut Anders Hatlen commented on DERBY-5970:
-------------------------------------------
Looks like a good improvement to me.
I'm wondering if it would be slightly more robust to use the case-insensitive Boolean.valueOf(String) library method instead of converting to lower case manually, in case there should be some exotic locale where lower-casing "TRUE" doesn't behave as one would expect (something similar to Turkish, where lower case of "I" is not "i").
> 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: derby-5970-01-aa-vetDecryptDatabaseValue.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
[jira] [Commented] (DERBY-5970) Check that connection attributes
have legal values.
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494944#comment-13494944 ]
Knut Anders Hatlen commented on DERBY-5970:
-------------------------------------------
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
[jira] [Updated] (DERBY-5970) Check that connection attributes have
legal values.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-5970:
---------------------------------
Attachment: derby-5970-01-ab-vetDecryptDatabaseValue.diff
Thanks for the quick review, Knut. Attaching derby-5970-01-ab-vetDecryptDatabaseValue.diff, which makes the improvement you suggested. Tests passed cleanly for me on the previous rev of the patch. Committed at subversion revision 1403735.
> 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: derby-5970-01-aa-vetDecryptDatabaseValue.diff, derby-5970-01-ab-vetDecryptDatabaseValue.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
[jira] [Updated] (DERBY-5970) Check that connection attributes have
legal values.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-5970:
---------------------------------
Attachment: AttributeChecks.html
Attaching rev 2 of AttributeChecks.html. In this second rev I offer recommendations for additional sanity-checking of 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
[jira] [Commented] (DERBY-5970) Check that connection attributes
have legal values.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489385#comment-13489385 ]
Rick Hillegas commented on DERBY-5970:
--------------------------------------
Committed derby-5970-02-aa-vetDataEncryptionValue.diff at subversion revision 1404944.
> 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: 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
[jira] [Updated] (DERBY-5970) Check that connection attributes have
legal values.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-5970:
---------------------------------
Attachment: AttributeChecks.html
Thanks for those good suggestions, Knut. Attaching a third rev of the spec, incorporating your feedback.
> 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, 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
[jira] [Commented] (DERBY-5970) Check that connection attributes
have legal values.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492567#comment-13492567 ]
Rick Hillegas commented on DERBY-5970:
--------------------------------------
We might be able to use the optional ij URLCheck logic to help us raise a SQLWarning when attributes have illegal values but backward compatibility concerns prevent us from raising an exception.
> 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: 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