Derby
  1. Derby
  2. DERBY-4602

10 failures and 11 errors with IBM weme6.2/j9/cdc-foundation after revision 922304 for DERBY-4483

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.6.1.0
    • Fix Version/s: 10.6.1.0
    • Component/s: Services, Test
    • Labels:
      None
    • Environment:
      IBM's j2ME/cdc/foundation implementation (j9 jvm from weme6.2)
    • Issue & fix info:
      Release Note Needed
    • Bug behavior facts:
      Regression Test Failure, Security

      Description

      Since March 12 there's been 10 failures and 11 errors in the nightly test run with IBM's j2ME/CDC-foundation profile implementation, see: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-922467.html. Things were ok on March 10, see: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-921667.html.

      I believe these were the effect of the following checkin for DERBY-4483:

      r922304 | kahatlen | 2010-03-12 08:01:20 -0800 (Fri, 12 Mar 2010) | 8 lines
      DERBY-4483: Provide a way to change the hash algorithm used by BUILTIN authentication

      I'll attach the full failure stacks in a separate file, but I believe perhaps new tests have been added that need to be excluded from the run, because the provider doesn't support the intended mechanism.

      I'd also be interested to know if these same failures occur with Sun's/Oracle's phoneME.

      This is the top of the first error:
      -------------------
      1) testVariousBuiltinAlgorithms(org.apache.derbyTesting.functionTests.tests.jdbcapi.AuthenticationTest)java.sql.SQLException: The message digest algorithm 'SHA-256' is not supported by any of the available cryptography providers. Please install a cryptography provider that supports that algorithm, or specify another algorithm in the derby.authentication.builtin.algorithm property.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
      at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.AuthenticationTest.setDatabaseProperty(AuthenticationTest.java:1208)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.AuthenticationTest.setDatabaseProperty(AuthenticationTest.java:1218)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.AuthenticationTest.testVariousBuiltinAlgorithms(AuthenticationTest.java:1118)
      ------------------

      The failures are likely a result of this - the stack shows issues like no cleaning up of databases etc.

      1. derby-4602-1b.diff
        5 kB
        Knut Anders Hatlen
      2. releaseNote.html
        6 kB
        Knut Anders Hatlen
      3. derby-4602-1a.diff
        6 kB
        Knut Anders Hatlen
      4. derby-4602-1a.stat
        0.2 kB
        Knut Anders Hatlen
      5. ListAlgorithms.java
        0.7 kB
        Knut Anders Hatlen
      6. j9errorsandfailures.txt
        93 kB
        Myrna van Lunteren

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          The failure in testVariousBuiltinAlgorithm() is not so serious in itself, as it could just be disabled on JVMs that don't support SHA-256. However, SHA-256 was made the default algorithm in revision 927368, so with a more recent version of trunk, you'd probably see even more of these errors.

          The phoneME tests have been running cleanly after the DERBY-4483 changes. http://dbtg.foundry.sun.com/derby/test/Daily/javaME/testing/Limited/

          Show
          Knut Anders Hatlen added a comment - The failure in testVariousBuiltinAlgorithm() is not so serious in itself, as it could just be disabled on JVMs that don't support SHA-256. However, SHA-256 was made the default algorithm in revision 927368, so with a more recent version of trunk, you'd probably see even more of these errors. The phoneME tests have been running cleanly after the DERBY-4483 changes. http://dbtg.foundry.sun.com/derby/test/Daily/javaME/testing/Limited/
          Hide
          Knut Anders Hatlen added a comment -

          If the problem is that SHA-256 is missing, we could always make SHA-1 the default algorithm (it must be supported on weme, since that's what the old authentication scheme used). But before we do that, it would be interesting to see which security providers are available on weme, and which message digest algorithms they support. Myrna, could you please attach the output produced by the attached java class on weme? Thanks.

          Show
          Knut Anders Hatlen added a comment - If the problem is that SHA-256 is missing, we could always make SHA-1 the default algorithm (it must be supported on weme, since that's what the old authentication scheme used). But before we do that, it would be interesting to see which security providers are available on weme, and which message digest algorithms they support. Myrna, could you please attach the output produced by the attached java class on weme? Thanks.
          Hide
          Myrna van Lunteren added a comment -

          The output with weme 6.2 is:
          Digest algorithms:
          MD5
          SHA-1

          Providers:
          OTI
          J9JCE
          J9JSSE

          And indeed, there's more errors since March 25 (revision 927661) we've now gotten up to 10 failures and 122 errors...(not all are because of missing SHA-256, some of those are due to a lock being held from some previous test, or similar trouble).

          Perhaps it's possible to have some exception code to have SHA-1 be the default for weme...The weme jvm is recognizable by a number of properties starting with 'com.ibm.oti'... We already have one weme specific code snippet in BaseTestCase to find the executable name...

          Show
          Myrna van Lunteren added a comment - The output with weme 6.2 is: Digest algorithms: MD5 SHA-1 Providers: OTI J9JCE J9JSSE And indeed, there's more errors since March 25 (revision 927661) we've now gotten up to 10 failures and 122 errors...(not all are because of missing SHA-256, some of those are due to a lock being held from some previous test, or similar trouble). Perhaps it's possible to have some exception code to have SHA-1 be the default for weme...The weme jvm is recognizable by a number of properties starting with 'com.ibm.oti'... We already have one weme specific code snippet in BaseTestCase to find the executable name...
          Hide
          Knut Anders Hatlen added a comment -

          Thanks Myrna. Looks like we don't have many options on that platform, then. We could have a different default for weme, but then we may run into portability issues when moving a database created on another platform to weme, so I think having the same default on all platforms is the safest choice.

          Show
          Knut Anders Hatlen added a comment - Thanks Myrna. Looks like we don't have many options on that platform, then. We could have a different default for weme, but then we may run into portability issues when moving a database created on another platform to weme, so I think having the same default on all platforms is the safest choice.
          Hide
          Knut Anders Hatlen added a comment -

          Rick also suggested (in a comment on DERBY-4483) that we should keep SHA-256 as the default on platforms that support it and fall back to SHA-1 on those that don't, so I'm attaching a patch that makes the suggested changes and updates AuthenticationTest to skip tests for unsupported algorithms.

          Show
          Knut Anders Hatlen added a comment - Rick also suggested (in a comment on DERBY-4483 ) that we should keep SHA-256 as the default on platforms that support it and fall back to SHA-1 on those that don't, so I'm attaching a patch that makes the suggested changes and updates AuthenticationTest to skip tests for unsupported algorithms.
          Hide
          Knut Anders Hatlen added a comment -

          I think we would need a release note if the 1a patch is committed to explain weme users what to do if they get a message saying algorithm not supported when they try to connect. (This may happen if they create a database on a more capable platform, enable authentication, and copy the database to a restricted platform.) I think the error message they'll see is pretty self-explanatory, but I still think a release note is in order, as users may wonder why this started happening now.

          Show
          Knut Anders Hatlen added a comment - I think we would need a release note if the 1a patch is committed to explain weme users what to do if they get a message saying algorithm not supported when they try to connect. (This may happen if they create a database on a more capable platform, enable authentication, and copy the database to a restricted platform.) I think the error message they'll see is pretty self-explanatory, but I still think a release note is in order, as users may wonder why this started happening now.
          Hide
          Knut Anders Hatlen added a comment -

          Came to think about one issue... The 1a patch introduces a dependency on SHA-256 or SHA-1 being available at database creation time, even if the database does not actually use authentication. I think it would be better if it didn't fail when the database was created, but rather when/if the unsupported algorithm is attempted used, as it does today, so that it's still possible to create databases on JVMs without SHA-1 support as long as authentication is not used.

          Show
          Knut Anders Hatlen added a comment - Came to think about one issue... The 1a patch introduces a dependency on SHA-256 or SHA-1 being available at database creation time, even if the database does not actually use authentication. I think it would be better if it didn't fail when the database was created, but rather when/if the unsupported algorithm is attempted used, as it does today, so that it's still possible to create databases on JVMs without SHA-1 support as long as authentication is not used.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching release note.

          Show
          Knut Anders Hatlen added a comment - Attaching release note.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching updated patch (1b) that does not fail on database creation if SHA-1 is not present.

          Show
          Knut Anders Hatlen added a comment - Attaching updated patch (1b) that does not fail on database creation if SHA-1 is not present.
          Hide
          Myrna van Lunteren added a comment -

          I tried out the test lang.GrantRevokeTest with the patch, and it fails without, and passes with the patch. I'll assume the other issues will work also, I'll try a full test run later to confirm, but any other fall-out can be addressed in a new issue... +1 from me.

          Show
          Myrna van Lunteren added a comment - I tried out the test lang.GrantRevokeTest with the patch, and it fails without, and passes with the patch. I'll assume the other issues will work also, I'll try a full test run later to confirm, but any other fall-out can be addressed in a new issue... +1 from me.
          Hide
          Knut Anders Hatlen added a comment -

          Thanks for testing the patch, Myrna!
          Committed revision 929715.

          Show
          Knut Anders Hatlen added a comment - Thanks for testing the patch, Myrna! Committed revision 929715.
          Hide
          Myrna van Lunteren added a comment -

          All tests pass again with weme 6.2.

          Show
          Myrna van Lunteren added a comment - All tests pass again with weme 6.2.

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Myrna van Lunteren
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development