Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      This is an java.net jira OpenJDK 6 bug entry for http://bugs.sun.com/view_bug.do?bug_id=7188845

      Cleanup "restricted" crypto support

      There is still a lot of cruft in the codebase for preventing the usage of
      certain crypto algorithms or key-sizes. And we were actually shipping
      restricted policies preventing people from using unlimited crypto. Oops.

      So if you saw: "java.securityInvalidKeyException: Illegal key size or default
      parameters" that was caused by wrongly installed security policy files. The
      code was actually there, just not properly activated.

      This patch cleans up the crypto code so it doesn't go out of its way to prevent
      usage of "restricted crypto" and makes sure no restricted crypto security
      policies are installed. It removes all the unneeded classes like JarVerifier
      (that didn't actually do anything) and JceSecurityManager (that did all the
      unnecessary tricky class loader stack walking stuff) and reduces the
      JceSecurity class to just the method getInstance() and the static field RANDOM
      for the shared SecureRandom instance.

      For now I also kept the canUseProvider() method, that can now just return true.
      This last one was kept because the SecretKeyFactory, KeyGenerator, Mac and
      KeyAgreement classes still call it. It could be removed completely but I wanted
      to keep something that in principle could be easily used for some closed
      proprietary version that still insists on this "restricted crypto" thing.

      I believe this is now pretty clean. And it should be simple to verify that it
      works correctly now since all unnecessary code is just thrown out. Of course I
      threw all the crypto and security tests at it that I could find and all happily
      passed. I did alter the TestUtil class so that it always checks all algorithms
      and full keys.

      It would be nice to push this in OpenJDK proper so there is less divergence and
      so the GPLed version always has full crypto support enabled.

      This has been in production use for over a year now through IcedTea on various
      GNU/Linux distros and so should be pretty well tested.

      See also the discussions on the mailinglists:
      http://mail.openjdk.java.net/pipermail/security-dev/2008-August/000283.html
      http://mail.openjdk.java.net/pipermail/security-dev/2008-September/000329.html
      http://mail.openjdk.java.net/pipermail/security-dev/2008-November/000385.html

        Activity

        Hide
        gnu_andrew added a comment -

        We're not including that. It was also already NACK by Oracle years ago. There's a simpler fix that will be tested and backported in due course.

        Show
        gnu_andrew added a comment - We're not including that. It was also already NACK by Oracle years ago. There's a simpler fix that will be tested and backported in due course.

          People

          • Assignee:
            Unassigned
            Reporter:
            xerxes_ranby
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: