Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
openanolis
dragonwell8_jdk
提交
a5d5ea1a
D
dragonwell8_jdk
项目概览
openanolis
/
dragonwell8_jdk
通知
3
Star
2
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
D
dragonwell8_jdk
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
a5d5ea1a
编写于
9月 26, 2017
作者:
C
coffeys
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
8170157: Enable unlimited cryptographic policy by default in OracleJDK
Reviewed-by: wetmore
上级
8120c89b
变更
8
隐藏空白更改
内联
并排
Showing
8 changed file
with
419 addition
and
230 deletion
+419
-230
src/share/classes/javax/crypto/JceSecurity.java
src/share/classes/javax/crypto/JceSecurity.java
+6
-6
src/share/lib/security/java.security-aix
src/share/lib/security/java.security-aix
+44
-42
src/share/lib/security/java.security-linux
src/share/lib/security/java.security-linux
+44
-41
src/share/lib/security/java.security-macosx
src/share/lib/security/java.security-macosx
+44
-41
src/share/lib/security/java.security-solaris
src/share/lib/security/java.security-solaris
+44
-41
src/share/lib/security/java.security-windows
src/share/lib/security/java.security-windows
+44
-41
test/javax/crypto/CryptoPermission/CryptoPolicyFallback.java
test/javax/crypto/CryptoPermission/CryptoPolicyFallback.java
+123
-0
test/javax/crypto/CryptoPermission/TestUnlimited.java
test/javax/crypto/CryptoPermission/TestUnlimited.java
+70
-18
未找到文件。
src/share/classes/javax/crypto/JceSecurity.java
浏览文件 @
a5d5ea1a
/*
* Copyright (c) 1997, 201
6
, Oracle and/or its affiliates. All rights reserved.
* Copyright (c) 1997, 201
7
, 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
un
limited crypto policy files found in the
*
<java-home>/lib/security/policy/un
limited/ 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
un
limited policy mode.
cpPath
=
Paths
.
get
(
javaHomeProperty
,
"lib"
,
"security"
,
"policy"
,
"limited"
);
javaHomeProperty
,
"lib"
,
"security"
,
"policy"
,
"
un
limited"
);
// 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
浏览文件 @
a5d5ea1a
...
...
@@ -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
浏览文件 @
a5d5ea1a
...
...
@@ -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
浏览文件 @
a5d5ea1a
...
...
@@ -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
浏览文件 @
a5d5ea1a
...
...
@@ -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
浏览文件 @
a5d5ea1a
...
...
@@ -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
0 → 100644
浏览文件 @
a5d5ea1a
/*
* 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
浏览文件 @
a5d5ea1a
...
...
@@ -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!"
);
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录