[
https://issues.apache.org/jira/browse/DERBY-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478564
]
Dag H. Wanvik commented on DERBY-2409:
--------------------------------------
The last tidbit may merit its own issue: A superfluous bootPassword
(in a plain boot of an existing, already encrypted database) is also ignored.
Data point: In contrast, a superfluous 'create=true' will give a warning.
> Connecting to an already booted database with (re)encryption attributes gives
> no error or warning
> -------------------------------------------------------------------------------------------------
>
> Key: DERBY-2409
> URL: https://issues.apache.org/jira/browse/DERBY-2409
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.1.2.1,
> 10.1.3.1, 10.1.3.2, 10.1.4.0, 10.2.1.6, 10.2.2.0, 10.2.2.1, 10.2.3.0, 10.3.0.0
> Reporter: Dag H. Wanvik
> Priority: Minor
>
> If a database is shutdown and booted with (re)encryption,
> the (re)encryption boot will silently fail (i.e. no (re)encryption takes
> place), if another
> connection has booted the database in the meantime.
> Presumably, if the database was encrypted at creation time, only the dba will
> have the bootpassword and the above scenario is less likely.
> If it was created unencrypted, is is more of a hole, IMHO: Any other
> connection
> can then foil the encryption boot, even one which can not be authenticated,
> cf DERBY-2407. To further exacerbate this issue; when the database is shutdown
> and rebooted, using the boot password supplied (and the database was not
> encrypted),
> no error is given, since a boot password is not required. This can lull a dba
> into thinking the encryption took place! :(
> We may want to generate a warning or an error in these cases.
> This issue may affect upgrade boots as well?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
