8170157: Enable unlimited cryptographic policy by default in OracleJDK
Reviewed-by: wetmore
(cherry picked from commit 23f0b2e)
diff --git a/src/share/classes/javax/crypto/JceSecurity.java b/src/share/classes/javax/crypto/JceSecurity.java
index 5def277..e7e3a99 100644
--- a/src/share/classes/javax/crypto/JceSecurity.java
+++ b/src/share/classes/javax/crypto/JceSecurity.java
@@ -1,5 +1,5 @@
/*
- * 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 @@
* 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 @@
!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");
diff --git a/src/share/lib/security/java.security-aix b/src/share/lib/security/java.security-aix
index 4fdeba4..d8f4b97 100644
--- a/src/share/lib/security/java.security-aix
+++ b/src/share/lib/security/java.security-aix
@@ -733,69 +733,71 @@
# 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
diff --git a/src/share/lib/security/java.security-linux b/src/share/lib/security/java.security-linux
index 51eea18..27cb94e 100644
--- a/src/share/lib/security/java.security-linux
+++ b/src/share/lib/security/java.security-linux
@@ -733,67 +733,70 @@
# 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
#
diff --git a/src/share/lib/security/java.security-macosx b/src/share/lib/security/java.security-macosx
index 30ef845..2a08b6f 100644
--- a/src/share/lib/security/java.security-macosx
+++ b/src/share/lib/security/java.security-macosx
@@ -736,67 +736,70 @@
# 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
#
diff --git a/src/share/lib/security/java.security-solaris b/src/share/lib/security/java.security-solaris
index 89a9fc6..3cf0c49 100644
--- a/src/share/lib/security/java.security-solaris
+++ b/src/share/lib/security/java.security-solaris
@@ -735,67 +735,70 @@
# 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
#
diff --git a/src/share/lib/security/java.security-windows b/src/share/lib/security/java.security-windows
index 8d780e7..cc3f4c9 100644
--- a/src/share/lib/security/java.security-windows
+++ b/src/share/lib/security/java.security-windows
@@ -736,67 +736,70 @@
# 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
#
diff --git a/test/javax/crypto/CryptoPermission/CryptoPolicyFallback.java b/test/javax/crypto/CryptoPermission/CryptoPolicyFallback.java
new file mode 100644
index 0000000..4032666
--- /dev/null
+++ b/test/javax/crypto/CryptoPermission/CryptoPolicyFallback.java
@@ -0,0 +1,123 @@
+/*
+ * 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!");
+ }
+}
diff --git a/test/javax/crypto/CryptoPermission/TestUnlimited.java b/test/javax/crypto/CryptoPermission/TestUnlimited.java
index 25d29f8..ff0242c 100644
--- a/test/javax/crypto/CryptoPermission/TestUnlimited.java
+++ b/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 @@
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();
+ }
- System.out.println("Testing: " + args[0]);
+ Result expected = Result.UNKNOWN; // avoid NPE warnings
+ Result result;
- if (args[0].equals("\"\"")) {
+ 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");
+ }
+
+ 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 @@
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!");
