JDK-8061842 : Package jurisdiction policy files as something other than JAR
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-10-22
  • Updated: 2017-08-11
  • Resolved: 2016-08-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b134Fixed
Related Reports
Relates :  
JDK-8157561 - Ship the unlimited policy files in JDK Updates
Sub Tasks
JDK-8186094 :  
Release Note: Updated Java Cryptography Jurisdiction Policy File Mechanism - Closed
Description
With the modular image then the classes and resources for the runtime will be packaged in a new container format. The only JAR files in open builds are the  jurisdiction policy files packaged as US_export_policy.jar and local_policy.jar.

This issue asks that this be re-examined to see if they really need to be packaged as JAR files. They don't appear to be signed.
Comments
Current proposal: (policydir-tbd is a build-time configuration switch which reads --enable-unlimited-crypto) # Cryptographic Jurisdiction Policy defaults # # Due to the import control restrictions of some countries, the default # JCE policy files allow for strong but "limited" cryptographic key # lengths to be used. If your country's cryptographic regulations allow, # the "unlimited" strength policy files can be used instead, which contain # no restrictions on cryptographic strengths. # # If your country has restrictions that don't fit either "limited" or # "unlimited", an appropriate set of policy files should be created and # configured before using this distribution. The jurisdiction policy file # configuration must reflect the cryptographic restrictions appropriate # for your country. # # YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY # TO DETERMINE THE EXACT REQUIREMENTS. # # The policy files are flat text files organized into subdirectories of # <java-home>/conf/security/policy. Each directory contains a complete # set of policy files. # # The "crypto.policy" Security property controls the directory selection, # and thus the effective cryptographic policy. # # The default set of directories is: # # limited | unlimited # # however other directories can be created and configured. # # Within a directory, the effective policy is the combined minimum # permissions of the grant statements in the file(s) with the filename # pattern "default_*.policy". At least one grant is required. # # limited = Export (all) + Import (limited) = Limited # unlimited = Export (all) + Import (all) = Unlimited # # The effective exemption policy is the combined minimum permissions # of the grant statements in the file(s) with the filename pattern # "exempt_*.policy". Exemption grants are optional. # # limited = grants exemption permissions, by which the # effective policy can be circumvented. # e.g. KeyRecovery/Escrow/Weakening. # # Please see the JCA documentation for additional information on these # files and formats. crypto.policy=policydir-tbd
04-08-2016
Current proposal is to move the policy files into <java-home>/conf/security/policy and break the jars into flat text files. (3 files currently, but admins could add/remove files as policy needs change.)
21-07-2016
A patch to avoid changing the jar checksums was posted to build-dev & security-dev. This may not be needed depending on how this bug shakes out. http://mail.openjdk.java.net/pipermail/build-dev/2016-May/017213.html http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013982.html
26-05-2016
Originally still packaged as jars as it was minimal work when JCE build changes went it. We could change it, but need the ability to contain two files unless we change the current format/syntax/semantics. One suggestion was to turn it into a module that could be replaced. This was one of the things to talk about post m2 integration when modules go live.
22-10-2014