8170157: Enable unlimited cryptographic policy by default in OracleJDK

Reviewed-by: wetmore

src/share/classes/javax/crypto/JceSecurity.java

 /*
- * Copyright (c) 1997, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -257,12 +257,12 @@ final class JceSecurity {
      * user edit or an application call is required.
      *
      * Otherwise, if user has policy jar files installed in the legacy
-     * jre/lib/security/ directory, the JDK will honor whatever
+     * <java-home>/lib/security/ directory, the JDK will honor whatever
      * setting is set by those policy files. (legacy/current behavior)
      *
      * If none of the above 2 conditions are met, the JDK will default
-     * to using the limited crypto policy files found in the
-     * jre/lib/security/policy/limited/ directory
+     * to using the unlimited crypto policy files found in the
+     * <java-home>/lib/security/policy/unlimited/ directory
      */
     private static void setupJurisdictionPolicies() throws Exception {
         // Sanity check the crypto.policy Security property.  Single
@@ -300,9 +300,9 @@ final class JceSecurity {
                 !importJar.exists())) {
             // Compatibility set up. If crypto.policy is not defined.
             // check to see if legacy jars exist in lib directory. If
-            // they don't exist, we default to limited policy mode.
+            // they don't exist, we default to unlimited policy mode.
             cpPath = Paths.get(
-                    javaHomeProperty, "lib", "security", "policy", "limited");
+                    javaHomeProperty, "lib", "security", "policy", "unlimited");
             // point to the new jar files in limited directory
             exportJar = new File(cpPath.toFile(),"US_export_policy.jar");
             importJar = new File(cpPath.toFile(),"local_policy.jar");

src/share/lib/security/java.security-aix

@@ -737,69 +737,71 @@ jdk.tls.legacyAlgorithms= \
 
 # 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.
+# Import and export control rules on cryptographic software vary from
+# country to country.  By default, the JDK provides two different sets of
+# cryptographic policy files:
 #
-# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
-# TO DETERMINE THE EXACT REQUIREMENTS.
+#     unlimited:  These policy files contain no restrictions on cryptographic
+#                 strengths or algorithms.
 #
-# <java-home> (below) refers to the directory where the JRE was
-# installed. It is determined based on whether you are running JCE
-# on a JRE or a JRE contained within the Java Development Kit, or
-# JDK(TM). The JDK contains the JRE, but at a different level in the
-# file hierarchy. For example, if the JDK is installed in
-# /home/user1/jdk1.8.0 on Unix or in C:\jdk1.8.0 on Windows, then
-# <java-home> is:
+#     limited:    These policy files contain more restricted cryptographic
+#                 strengths, and are still available if your country or
+#                 usage requires the traditional restrictive policy.
 #
-#  /home/user1/jdk1.8.0/jre           [Unix]
-#  C:\jdk1.8.0\jre                    [Windows]
+# The JDK JCE framework uses the unlimited policy files by default.
+# However the user may explicitly choose a set either by defining the
+# "crypto.policy" Security property or by installing valid JCE policy
+# jar files into the traditional JDK installation location.  To better
+# support older JDK Update releases, the "crypto.policy" property is not
+# defined by default.  See below for more information.
 #
-# If on the other hand the JRE is installed in /home/user1/jre1.8.0
-# on Unix or in C:\jre1.8.0 on Windows, and the JDK is not
-# installed, then <java-home> is:
+# The following logic determines which policy files are used:
 #
-#  /home/user1/jre1.8.0               [Unix]
-#  C:\jre1.8.0                        [Windows]
+#         <java-home> refers to the directory where the JRE was
+#         installed and may be determined using the "java.home"
+#         System property.
 #
-# On Windows, for each JDK installation, there may be additional
-# JREs installed under the "Program Files" directory. Please make
-# sure that you install the unlimited strength policy JAR files
-# for all JREs that you plan to use.
+# 1.  If the Security property "crypto.policy" has been defined,
+#     then the following mechanism is used:
 #
-# The policy files are jar files organized into subdirectories of
+#     The policy files are stored as jar files in subdirectories of
 # <java-home>/lib/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 "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.
-#
-# To support older JDK Update releases, the crypto.policy property
-# is not defined by default. When the property is not defined, an
-# update release binary aware of the new property will use the following
-# logic to decide what crypto policy files get used :
-#
-# * If the US_export_policy.jar and local_policy.jar files are located
-# in the (legacy) <java-home>/lib/security directory, then the rules
-# embedded in those jar files will be used. This helps preserve compatibility
+# 2.  If the "crypto.policy" property is not set and the traditional
+#     US_export_policy.jar and local_policy.jar files
+#     (e.g. limited/unlimited) are found in the legacy
+#     <java-home>/lib/security directory, then the rules embedded within
+#     those jar files will be used. This helps preserve compatibility
 # for users upgrading from an older installation.
 #
-# * If crypto.policy is not defined and no such jar files are present in
-# the legacy locations, then the JDK will use the limited settings
-# (equivalent to crypto.policy=limited)
+# 3.  If the jar files are not present in the legacy location
+#     and the "crypto.policy" Security property is not defined,
+#     then the JDK will use the unlimited settings (equivalent to
+#     crypto.policy=unlimited)
 #
 # Please see the JCA documentation for additional information on these
 # files and formats.
-#crypto.policy=unlimited
 #
+# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
+# TO DETERMINE THE EXACT REQUIREMENTS.
+#
+# Please note that the JCE for Java SE, including the JCE framework,
+# cryptographic policy files, and standard JCE providers provided with
+# the Java SE, have been reviewed and approved for export as mass market
+# encryption item by the US Bureau of Industry and Security.
+#
+# Note: This property is currently used by the JDK Reference implementation.
+# It is not guaranteed to be examined and used by other implementations.
+#
+#crypto.policy=unlimited
 
 # The policy for the XML Signature secure validation mode. The mode is
 # enabled by setting the property "org.jcp.xml.dsig.secureValidation" to

src/share/lib/security/java.security-linux

@@ -737,67 +737,70 @@ jdk.tls.legacyAlgorithms= \
 
 # 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.
+# Import and export control rules on cryptographic software vary from
+# country to country.  By default, the JDK provides two different sets of
+# cryptographic policy files:
 #
-# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
-# TO DETERMINE THE EXACT REQUIREMENTS.
+#     unlimited:  These policy files contain no restrictions on cryptographic
+#                 strengths or algorithms.
 #
-# <java-home> (below) refers to the directory where the JRE was
-# installed. It is determined based on whether you are running JCE
-# on a JRE or a JRE contained within the Java Development Kit, or
-# JDK(TM). The JDK contains the JRE, but at a different level in the
-# file hierarchy. For example, if the JDK is installed in
-# /home/user1/jdk1.8.0 on Unix or in C:\jdk1.8.0 on Windows, then
-# <java-home> is:
+#     limited:    These policy files contain more restricted cryptographic
+#                 strengths, and are still available if your country or
+#                 usage requires the traditional restrictive policy.
 #
-#  /home/user1/jdk1.8.0/jre           [Unix]
-#  C:\jdk1.8.0\jre                    [Windows]
+# The JDK JCE framework uses the unlimited policy files by default.
+# However the user may explicitly choose a set either by defining the
+# "crypto.policy" Security property or by installing valid JCE policy
+# jar files into the traditional JDK installation location.  To better
+# support older JDK Update releases, the "crypto.policy" property is not
+# defined by default.  See below for more information.
 #
-# If on the other hand the JRE is installed in /home/user1/jre1.8.0
-# on Unix or in C:\jre1.8.0 on Windows, and the JDK is not
-# installed, then <java-home> is:
+# The following logic determines which policy files are used:
 #
-#  /home/user1/jre1.8.0               [Unix]
-#  C:\jre1.8.0                        [Windows]
+#         <java-home> refers to the directory where the JRE was
+#         installed and may be determined using the "java.home"
+#         System property.
 #
-# On Windows, for each JDK installation, there may be additional
-# JREs installed under the "Program Files" directory. Please make
-# sure that you install the unlimited strength policy JAR files
-# for all JREs that you plan to use.
+# 1.  If the Security property "crypto.policy" has been defined,
+#     then the following mechanism is used:
 #
-# The policy files are jar files organized into subdirectories of
+#     The policy files are stored as jar files in subdirectories of
 # <java-home>/lib/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 "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.
-#
-# To support older JDK Update releases, the crypto.policy property
-# is not defined by default. When the property is not defined, an
-# update release binary aware of the new property will use the following
-# logic to decide what crypto policy files get used :
-#
-# * If the US_export_policy.jar and local_policy.jar files are located
-# in the (legacy) <java-home>/lib/security directory, then the rules
-# embedded in those jar files will be used. This helps preserve compatibility
+# 2.  If the "crypto.policy" property is not set and the traditional
+#     US_export_policy.jar and local_policy.jar files
+#     (e.g. limited/unlimited) are found in the legacy
+#     <java-home>/lib/security directory, then the rules embedded within
+#     those jar files will be used. This helps preserve compatibility
 # for users upgrading from an older installation.
 #
-# * If crypto.policy is not defined and no such jar files are present in
-# the legacy locations, then the JDK will use the limited settings
-# (equivalent to crypto.policy=limited)
+# 3.  If the jar files are not present in the legacy location
+#     and the "crypto.policy" Security property is not defined,
+#     then the JDK will use the unlimited settings (equivalent to
+#     crypto.policy=unlimited)
 #
 # Please see the JCA documentation for additional information on these
 # files and formats.
+#
+# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
+# TO DETERMINE THE EXACT REQUIREMENTS.
+#
+# Please note that the JCE for Java SE, including the JCE framework,
+# cryptographic policy files, and standard JCE providers provided with
+# the Java SE, have been reviewed and approved for export as mass market
+# encryption item by the US Bureau of Industry and Security.
+#
+# Note: This property is currently used by the JDK Reference implementation.
+# It is not guaranteed to be examined and used by other implementations.
+#
 #crypto.policy=unlimited
 
 #

src/share/lib/security/java.security-macosx

@@ -740,67 +740,70 @@ jdk.tls.legacyAlgorithms= \
 
 # 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.
+# Import and export control rules on cryptographic software vary from
+# country to country.  By default, the JDK provides two different sets of
+# cryptographic policy files:
 #
-# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
-# TO DETERMINE THE EXACT REQUIREMENTS.
+#     unlimited:  These policy files contain no restrictions on cryptographic
+#                 strengths or algorithms.
 #
-# <java-home> (below) refers to the directory where the JRE was
-# installed. It is determined based on whether you are running JCE
-# on a JRE or a JRE contained within the Java Development Kit, or
-# JDK(TM). The JDK contains the JRE, but at a different level in the
-# file hierarchy. For example, if the JDK is installed in
-# /home/user1/jdk1.8.0 on Unix or in C:\jdk1.8.0 on Windows, then
-# <java-home> is:
+#     limited:    These policy files contain more restricted cryptographic
+#                 strengths, and are still available if your country or
+#                 usage requires the traditional restrictive policy.
 #
-#  /home/user1/jdk1.8.0/jre           [Unix]
-#  C:\jdk1.8.0\jre                    [Windows]
+# The JDK JCE framework uses the unlimited policy files by default.
+# However the user may explicitly choose a set either by defining the
+# "crypto.policy" Security property or by installing valid JCE policy
+# jar files into the traditional JDK installation location.  To better
+# support older JDK Update releases, the "crypto.policy" property is not
+# defined by default.  See below for more information.
 #
-# If on the other hand the JRE is installed in /home/user1/jre1.8.0
-# on Unix or in C:\jre1.8.0 on Windows, and the JDK is not
-# installed, then <java-home> is:
+# The following logic determines which policy files are used:
 #
-#  /home/user1/jre1.8.0               [Unix]
-#  C:\jre1.8.0                        [Windows]
+#         <java-home> refers to the directory where the JRE was
+#         installed and may be determined using the "java.home"
+#         System property.
 #
-# On Windows, for each JDK installation, there may be additional
-# JREs installed under the "Program Files" directory. Please make
-# sure that you install the unlimited strength policy JAR files
-# for all JREs that you plan to use.
+# 1.  If the Security property "crypto.policy" has been defined,
+#     then the following mechanism is used:
 #
-# The policy files are jar files organized into subdirectories of
+#     The policy files are stored as jar files in subdirectories of
 # <java-home>/lib/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 "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.
-#
-# To support older JDK Update releases, the crypto.policy property
-# is not defined by default. When the property is not defined, an
-# update release binary aware of the new property will use the following
-# logic to decide what crypto policy files get used :
-#
-# * If the US_export_policy.jar and local_policy.jar files are located
-# in the (legacy) <java-home>/lib/security directory, then the rules
-# embedded in those jar files will be used. This helps preserve compatibility
+# 2.  If the "crypto.policy" property is not set and the traditional
+#     US_export_policy.jar and local_policy.jar files
+#     (e.g. limited/unlimited) are found in the legacy
+#     <java-home>/lib/security directory, then the rules embedded within
+#     those jar files will be used. This helps preserve compatibility
 # for users upgrading from an older installation.
 #
-# * If crypto.policy is not defined and no such jar files are present in
-# the legacy locations, then the JDK will use the limited settings
-# (equivalent to crypto.policy=limited)
+# 3.  If the jar files are not present in the legacy location
+#     and the "crypto.policy" Security property is not defined,
+#     then the JDK will use the unlimited settings (equivalent to
+#     crypto.policy=unlimited)
 #
 # Please see the JCA documentation for additional information on these
 # files and formats.
+#
+# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
+# TO DETERMINE THE EXACT REQUIREMENTS.
+#
+# Please note that the JCE for Java SE, including the JCE framework,
+# cryptographic policy files, and standard JCE providers provided with
+# the Java SE, have been reviewed and approved for export as mass market
+# encryption item by the US Bureau of Industry and Security.
+#
+# Note: This property is currently used by the JDK Reference implementation.
+# It is not guaranteed to be examined and used by other implementations.
+#
 #crypto.policy=unlimited
 
 #

src/share/lib/security/java.security-solaris

@@ -739,67 +739,70 @@ jdk.tls.legacyAlgorithms= \
 
 # 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.
+# Import and export control rules on cryptographic software vary from
+# country to country.  By default, the JDK provides two different sets of
+# cryptographic policy files:
 #
-# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
-# TO DETERMINE THE EXACT REQUIREMENTS.
+#     unlimited:  These policy files contain no restrictions on cryptographic
+#                 strengths or algorithms.
 #
-# <java-home> (below) refers to the directory where the JRE was
-# installed. It is determined based on whether you are running JCE
-# on a JRE or a JRE contained within the Java Development Kit, or
-# JDK(TM). The JDK contains the JRE, but at a different level in the
-# file hierarchy. For example, if the JDK is installed in
-# /home/user1/jdk1.8.0 on Unix or in C:\jdk1.8.0 on Windows, then
-# <java-home> is:
+#     limited:    These policy files contain more restricted cryptographic
+#                 strengths, and are still available if your country or
+#                 usage requires the traditional restrictive policy.
 #
-#  /home/user1/jdk1.8.0/jre           [Unix]
-#  C:\jdk1.8.0\jre                    [Windows]
+# The JDK JCE framework uses the unlimited policy files by default.
+# However the user may explicitly choose a set either by defining the
+# "crypto.policy" Security property or by installing valid JCE policy
+# jar files into the traditional JDK installation location.  To better
+# support older JDK Update releases, the "crypto.policy" property is not
+# defined by default.  See below for more information.
 #
-# If on the other hand the JRE is installed in /home/user1/jre1.8.0
-# on Unix or in C:\jre1.8.0 on Windows, and the JDK is not
-# installed, then <java-home> is:
+# The following logic determines which policy files are used:
 #
-#  /home/user1/jre1.8.0               [Unix]
-#  C:\jre1.8.0                        [Windows]
+#         <java-home> refers to the directory where the JRE was
+#         installed and may be determined using the "java.home"
+#         System property.
 #
-# On Windows, for each JDK installation, there may be additional
-# JREs installed under the "Program Files" directory. Please make
-# sure that you install the unlimited strength policy JAR files
-# for all JREs that you plan to use.
+# 1.  If the Security property "crypto.policy" has been defined,
+#     then the following mechanism is used:
 #
-# The policy files are jar files organized into subdirectories of
+#     The policy files are stored as jar files in subdirectories of
 # <java-home>/lib/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 "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.
-#
-# To support older JDK Update releases, the crypto.policy property
-# is not defined by default. When the property is not defined, an
-# update release binary aware of the new property will use the following
-# logic to decide what crypto policy files get used :
-#
-# * If the US_export_policy.jar and local_policy.jar files are located
-# in the (legacy) <java-home>/lib/security directory, then the rules
-# embedded in those jar files will be used. This helps preserve compatibility
+# 2.  If the "crypto.policy" property is not set and the traditional
+#     US_export_policy.jar and local_policy.jar files
+#     (e.g. limited/unlimited) are found in the legacy
+#     <java-home>/lib/security directory, then the rules embedded within
+#     those jar files will be used. This helps preserve compatibility
 # for users upgrading from an older installation.
 #
-# * If crypto.policy is not defined and no such jar files are present in
-# the legacy locations, then the JDK will use the limited settings
-# (equivalent to crypto.policy=limited)
+# 3.  If the jar files are not present in the legacy location
+#     and the "crypto.policy" Security property is not defined,
+#     then the JDK will use the unlimited settings (equivalent to
+#     crypto.policy=unlimited)
 #
 # Please see the JCA documentation for additional information on these
 # files and formats.
+#
+# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
+# TO DETERMINE THE EXACT REQUIREMENTS.
+#
+# Please note that the JCE for Java SE, including the JCE framework,
+# cryptographic policy files, and standard JCE providers provided with
+# the Java SE, have been reviewed and approved for export as mass market
+# encryption item by the US Bureau of Industry and Security.
+#
+# Note: This property is currently used by the JDK Reference implementation.
+# It is not guaranteed to be examined and used by other implementations.
+#
 #crypto.policy=unlimited
 
 #

src/share/lib/security/java.security-windows

@@ -740,67 +740,70 @@ jdk.tls.legacyAlgorithms= \
 
 # 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.
+# Import and export control rules on cryptographic software vary from
+# country to country.  By default, the JDK provides two different sets of
+# cryptographic policy files:
 #
-# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
-# TO DETERMINE THE EXACT REQUIREMENTS.
+#     unlimited:  These policy files contain no restrictions on cryptographic
+#                 strengths or algorithms.
 #
-# <java-home> (below) refers to the directory where the JRE was
-# installed. It is determined based on whether you are running JCE
-# on a JRE or a JRE contained within the Java Development Kit, or
-# JDK(TM). The JDK contains the JRE, but at a different level in the
-# file hierarchy. For example, if the JDK is installed in
-# /home/user1/jdk1.8.0 on Unix or in C:\jdk1.8.0 on Windows, then
-# <java-home> is:
+#     limited:    These policy files contain more restricted cryptographic
+#                 strengths, and are still available if your country or
+#                 usage requires the traditional restrictive policy.
 #
-#  /home/user1/jdk1.8.0/jre           [Unix]
-#  C:\jdk1.8.0\jre                    [Windows]
+# The JDK JCE framework uses the unlimited policy files by default.
+# However the user may explicitly choose a set either by defining the
+# "crypto.policy" Security property or by installing valid JCE policy
+# jar files into the traditional JDK installation location.  To better
+# support older JDK Update releases, the "crypto.policy" property is not
+# defined by default.  See below for more information.
 #
-# If on the other hand the JRE is installed in /home/user1/jre1.8.0
-# on Unix or in C:\jre1.8.0 on Windows, and the JDK is not
-# installed, then <java-home> is:
+# The following logic determines which policy files are used:
 #
-#  /home/user1/jre1.8.0               [Unix]
-#  C:\jre1.8.0                        [Windows]
+#         <java-home> refers to the directory where the JRE was
+#         installed and may be determined using the "java.home"
+#         System property.
 #
-# On Windows, for each JDK installation, there may be additional
-# JREs installed under the "Program Files" directory. Please make
-# sure that you install the unlimited strength policy JAR files
-# for all JREs that you plan to use.
+# 1.  If the Security property "crypto.policy" has been defined,
+#     then the following mechanism is used:
 #
-# The policy files are jar files organized into subdirectories of
+#     The policy files are stored as jar files in subdirectories of
 # <java-home>/lib/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 "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.
-#
-# To support older JDK Update releases, the crypto.policy property
-# is not defined by default. When the property is not defined, an
-# update release binary aware of the new property will use the following
-# logic to decide what crypto policy files get used :
-#
-# * If the US_export_policy.jar and local_policy.jar files are located
-# in the (legacy) <java-home>/lib/security directory, then the rules
-# embedded in those jar files will be used. This helps preserve compatibility
+# 2.  If the "crypto.policy" property is not set and the traditional
+#     US_export_policy.jar and local_policy.jar files
+#     (e.g. limited/unlimited) are found in the legacy
+#     <java-home>/lib/security directory, then the rules embedded within
+#     those jar files will be used. This helps preserve compatibility
 # for users upgrading from an older installation.
 #
-# * If crypto.policy is not defined and no such jar files are present in
-# the legacy locations, then the JDK will use the limited settings
-# (equivalent to crypto.policy=limited)
+# 3.  If the jar files are not present in the legacy location
+#     and the "crypto.policy" Security property is not defined,
+#     then the JDK will use the unlimited settings (equivalent to
+#     crypto.policy=unlimited)
 #
 # Please see the JCA documentation for additional information on these
 # files and formats.
+#
+# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
+# TO DETERMINE THE EXACT REQUIREMENTS.
+#
+# Please note that the JCE for Java SE, including the JCE framework,
+# cryptographic policy files, and standard JCE providers provided with
+# the Java SE, have been reviewed and approved for export as mass market
+# encryption item by the US Bureau of Industry and Security.
+#
+# Note: This property is currently used by the JDK Reference implementation.
+# It is not guaranteed to be examined and used by other implementations.
+#
 #crypto.policy=unlimited
 
 #

test/javax/crypto/CryptoPermission/CryptoPolicyFallback.java

+/*
+ * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.  Oracle designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Oracle in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+/**
+ * @test
+ * @bug 8169335
+ * @summary Add a crypto policy fallback in case Security Property
+ * 'crypto.policy' does not exist.
+ * @run main/othervm CryptoPolicyFallback
+ */
+import java.io.*;
+import java.nio.file.*;
+import java.util.stream.*;
+import javax.crypto.*;
+
+/*
+ * Take the current java.security file, strip out the 'crypto.policy' entry,
+ * write to a new file in the current directory, then use that file as the
+ * replacement java.security file.  This test will fail if the crypto.policy
+ * entry doesn't match the compiled in value.
+ */
+public class CryptoPolicyFallback {
+
+    private static final String FILENAME = "java.security";
+
+    public static void main(String[] args) throws Exception {
+
+        String javaHome = System.getProperty("java.home");
+
+        Path path = Paths.get(javaHome, "lib", "security", FILENAME);
+
+        /*
+         * Get the default value.
+         */
+        String defaultPolicy;
+        try (Stream<String> lines = Files.lines(path)) {
+            /*
+             * If the input java.security file is malformed
+             * (missing crypto.policy, attribute/no value, etc), throw
+             * exception.  split() might throw AIOOB which
+             * is ok behavior.
+             */
+             String s = lines.filter(x -> x.startsWith("crypto.policy="))
+                    .findFirst().orElse("");
+             if (!s.isEmpty()) {
+                 defaultPolicy = s.split("=")[1].trim();
+             } else {
+                 defaultPolicy = s;
+             }
+        }
+
+        /*
+         * We know there is at least one crypto.policy entry, strip
+         * all of them out of the java.security file.
+         */
+        try (PrintWriter out = new PrintWriter(FILENAME);
+                Stream<String> lines = Files.lines(path)) {
+            lines.filter(x -> !x.trim().startsWith("crypto.policy="))
+                    .forEach(out::println);
+        }
+
+        /*
+         * "-Djava.security.properties==file" does a complete replacement
+         * of the system java.security file.  i.e. value must be "=file"
+         */
+        System.setProperty("java.security.properties", "=" + FILENAME);
+
+        /*
+         * Find out expected value.
+         */
+        int expected;
+        switch (defaultPolicy) {
+        case "limited":
+            expected = 128;
+            break;
+        case "":
+        case "unlimited":
+            expected = Integer.MAX_VALUE;
+            break;
+        default:
+            throw new Exception(
+                    "Unexpected Default Policy Value: " + defaultPolicy);
+        }
+
+        /*
+         * Do the actual check.  If the JCE Framework can't initialize
+         * an Exception is normally thrown here.
+         */
+        int maxKeyLen = Cipher.getMaxAllowedKeyLength("AES");
+
+        System.out.println("Default Policy: " + defaultPolicy
+                + "\nExpected max AES key length: " + expected
+                + ", received : " + maxKeyLen);
+
+        if (expected != maxKeyLen) {
+            throw new Exception("Wrong Key Length size!");
+        }
+
+        System.out.println("PASSED!");
+    }
+}

test/javax/crypto/CryptoPermission/TestUnlimited.java

@@ -25,12 +25,13 @@
 
 /**
  * @test
- * @bug 8157561
- * @summary Ship the unlimited policy files in JDK Updates
+ * @bug 8061842
+ * @summary Package jurisdiction policy files as something other than JAR
+ * @run main/othervm TestUnlimited use_default default
  * @run main/othervm TestUnlimited "" exception
- * @run main/othervm TestUnlimited limited fail
- * @run main/othervm TestUnlimited unlimited pass
- * @run main/othervm TestUnlimited unlimited/ pass
+ * @run main/othervm TestUnlimited limited limited
+ * @run main/othervm TestUnlimited unlimited unlimited
+ * @run main/othervm TestUnlimited unlimited/ unlimited
  * @run main/othervm TestUnlimited NosuchDir exception
  * @run main/othervm TestUnlimited . exception
  * @run main/othervm TestUnlimited /tmp/unlimited exception
@@ -40,9 +41,39 @@
  */
 import javax.crypto.*;
 import java.security.Security;
+import java.nio.file.*;
+import java.util.stream.*;
 
 public class TestUnlimited {
 
+    private enum Result {
+        UNLIMITED,
+        LIMITED,
+        EXCEPTION,
+        UNKNOWN
+    };
+
+    /*
+     * Grab the default policy entry from java.security.
+     *
+     * If the input java.security file is malformed
+     * (missing crypto.policy, attribute/no value, etc), throw
+     * exception.  split() might throw AIOOB which
+     * is ok behavior.
+     */
+    private static String getDefaultPolicy() throws Exception {
+        String javaHome = System.getProperty("java.home");
+        Path path = Paths.get(javaHome, "lib", "security", "java.security");
+
+        try (Stream<String> lines = Files.lines(path)) {
+            String s = lines.filter(x -> x.startsWith("crypto.policy="))
+                    .findFirst().orElse("");
+            if (!s.isEmpty())
+                return s.split("=")[1].trim();
+            return s;
+        }
+    }
+
     public static void main(String[] args) throws Exception {
         /*
          * Override the Security property to allow for unlimited policy.
@@ -53,16 +84,38 @@ public class TestUnlimited {
             throw new Exception("Two args required");
         }
 
-        boolean expected = args[1].equals("pass");
-        boolean exception = args[1].equals("exception");
-        boolean result = false;
+        String testStr = args[0];
+        String expectedStr = args[1];
+        if (testStr.equals("use_default")) {
+            expectedStr = getDefaultPolicy();
+        }
+
+        Result expected = Result.UNKNOWN;  // avoid NPE warnings
+        Result result;
 
-        System.out.println("Testing: " + args[0]);
+        switch (expectedStr) {
+        case "":
+        case "unlimited":
+            expected = Result.UNLIMITED;
+            break;
+        case "limited":
+            expected = Result.LIMITED;
+            break;
+        case "exception":
+            expected = Result.EXCEPTION;
+            break;
+        default:
+            throw new Exception("Unexpected argument");
+        }
 
-        if (args[0].equals("\"\"")) {
+        System.out.println("Testing: " + testStr);
+        if (testStr.equals("\"\"")) {
             Security.setProperty("crypto.policy", "");
         } else {
-            Security.setProperty("crypto.policy", args[0]);
+            // skip default case.
+            if (!testStr.equals("use_default")) {
+                Security.setProperty("crypto.policy", testStr);
+            }
         }
 
         /*
@@ -74,21 +127,20 @@ public class TestUnlimited {
             System.out.println("max AES key len:" + maxKeyLen);
             if (maxKeyLen > 128) {
                 System.out.println("Unlimited policy is active");
-                result = true;
+                result = Result.UNLIMITED;
             } else {
                 System.out.println("Unlimited policy is NOT active");
-                result = false;
+                result = Result.LIMITED;
             }
         } catch (Throwable e) {
-            if (!exception) {
-                throw new Exception();
-            }
+            //ExceptionInInitializerError's
+            result = Result.EXCEPTION;
         }
 
         System.out.println(
                 "Expected:\t" + expected + "\nResult:\t\t" + result);
-        if (expected != result) {
-            throw new Exception();
+        if (!expected.equals(result)) {
+            throw new Exception("Didn't match");
         }
 
         System.out.println("DONE!");