db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4329) If you try to create an in-memory database with an illegal encryption key size, you get an ASSERT failure rather than a diagnostic telling you that the key size is unsupported.
Date Fri, 31 Jul 2009 16:10:14 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas updated DERBY-4329:
---------------------------------

    Attachment: derby-4329-01-aa-dontSwallowExceptions.diff

I have pushed this forward a small distance. It seems to me that there are two issues involved
here:

1) Cleanup logic in BaseMonitor swallows the initial triggering exception if an error occurs
while performing cleanup. I have attached a patch which addresses this particular swallowing:
derby-4329-01-aa-dontSwallowExceptions I suspect that this pattern of exception swallowing
occurs elsewhere in this class. The patch is incremental improvement but, as a follow-on effort,
it would be worthwhile to fix other instances of this exception swallowing.

2) I believe that the attached patch will fix this bug. However, checking in this patch will
mask a second issue. Before checking in this patch, it would be good to understand that second
issue: StorageFactoryService, during cleanup initiated by BaseMonitor, asserts that an in-memory
service does not have the expected name. I don't know why the expected service name is not
the service name returned by VFMemoryStorageFactory.getCanonicalName(). The expected service
name starts with the memory subsubprotocol keyword but that keyword is missing on the name
returned by VFMemoryStorageFactory.getCanonicalName(). Perhaps the in-memory experts can shed
some light on this.


> If you try to create an in-memory database with an illegal encryption key size, you get
an ASSERT failure rather than a diagnostic telling you that the key size is unsupported.
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4329
>                 URL: https://issues.apache.org/jira/browse/DERBY-4329
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>            Reporter: Rick Hillegas
>         Attachments: derby-4329-01-aa-dontSwallowExceptions.diff
>
>
> The following script shows this problem for me when I use a Java 5 VM on Mac OS X. The
first connection (to an in-memory database) raises an assertion. In contrast, the second connection
(to an on-disk database) gives useful diagnostics:
> ij version 10.6
> ij> connect 'jdbc:derby:memory:encdbcbc_256;create=true;dataEncryption=true;encryptionKeyLength=256;encryptionAlgorithm=AES/CBC/NoPadding;bootPassword=Thursday';
> ERROR XJ001: Java exception: 'ASSERT FAILED serviceName = memory:/Users/rh161140/derby/dummy/encdbcbc_256;storageFactory.getCanonicalName()
= /Users/rh161140/derby/dummy/encdbcbc_256: org.apache.derby.shared.common.sanity.AssertFailure'.
> ij> connect 'jdbc:derby:encdbcbc_256_disk;create=true;dataEncryption=true;encryptionKeyLength=256;encryptionAlgorithm=AES/CBC/NoPadding;bootPassword=Thursday';
> ERROR XJ041: Failed to create database 'encdbcbc_256_disk', see the next exception for
details.
> ERROR XBM01: Startup failed due to an exception. See next exception for details. 
> ERROR XBCX0: Exception from Cryptography provider. See next exception for details.
> ERROR XJ001: Java exception: 'Illegal key size: java.security.InvalidKeyException'.
> ij

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message