Page Menu
Home
Phabricator
Search
Configure Global Search
Log In
Paste
P6880
u162 conffile update
Active
Public
Actions
Authored by
MoritzMuehlenhoff
on Mar 22 2018, 10:47 AM.
Edit Paste
Archive Paste
View Raw File
Subscribe
Mute Notifications
Award Token
Flag For Later
Tags
None
Referenced Files
F15960971: u162 conffile update
Mar 22 2018, 10:47 AM
2018-03-22 10:47:17 (UTC+0)
Subscribers
None
--- /etc/java-8-openjdk/security/java.security 2018-01-11 22:36:00.657591634 +0000
+++ /etc/java-8-openjdk/security/java.security.dpkg-new 2018-03-15 23:05:30.000000000 +0000
@@ -1,4 +1,3 @@
-# NOTE: This file is managed by Puppet.
#
# This is the "master security properties file".
#
@@ -224,6 +223,7 @@
jdk.internal.,\
jdk.nashorn.internal.,\
jdk.nashorn.tools.,\
+ jdk.xml.internal.,\
com.sun.activation.registries.
#
@@ -273,6 +273,7 @@
jdk.internal.,\
jdk.nashorn.internal.,\
jdk.nashorn.tools.,\
+ jdk.xml.internal.,\
com.sun.activation.registries.
#
@@ -543,12 +544,8 @@
# jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
#
#
-# NOTE: The disabledAlgorithms has been modified for use with WMF Kafka brokers.
-# See: https://phabricator.wikimedia.org/T182993
jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
- RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
-
-jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1, SHA224, DSA, RSA keySize < 2048, EC keySize < 224
+ RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
#
# Algorithm restrictions for signed JAR files
@@ -591,7 +588,7 @@
#
# See "jdk.certpath.disabledAlgorithms" for syntax descriptions.
#
-jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
+jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024
#
# Algorithm restrictions for Secure Socket Layer/Transport Layer Security
@@ -623,8 +620,8 @@
#
# Example:
# jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
-jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, \
- EC keySize < 224
+jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \
+ EC keySize < 224, DES40_CBC, RC4_40
# Legacy algorithms for Secure Socket Layer/Transport Layer Security (SSL/TLS)
# processing in JSSE implementation.
@@ -678,8 +675,6 @@
#
jdk.tls.legacyAlgorithms= \
K_NULL, C_NULL, M_NULL, \
- DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_anon_EXPORT, DH_DSS_EXPORT, \
- DH_RSA_EXPORT, RSA_EXPORT, \
DH_anon, ECDH_anon, \
RC4_128, RC4_40, DES_CBC, DES40_CBC, \
3DES_EDE_CBC
# 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.
-#
-# YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY
-# TO DETERMINE THE EXACT REQUIREMENTS.
+# 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:
+#
+# unlimited: These policy files contain no restrictions on cryptographic
+# strengths or algorithms.
+#
+# limited: These policy files contain more restricted cryptographic
+# strengths, and are still available if your country or
+# usage requires the traditional restrictive policy.
+#
+# 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.
+#
+# The following logic determines which policy files are used:
+#
+# <java-home> refers to the directory where the JRE was
+# installed and may be determined using the "java.home"
+# System property.
#
-# <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:
-#
-# /home/user1/jdk1.8.0/jre [Unix]
-# C:\jdk1.8.0\jre [Windows]
-#
-# 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:
-#
-# /home/user1/jre1.8.0 [Unix]
-# C:\jre1.8.0 [Windows]
-#
-# 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
#
@@ -888,6 +886,8 @@
# If the pattern is equal to the class name, it matches.
# Otherwise, the status is UNDECIDED.
#
+# Primitive types are not configurable with this filter.
+#
#jdk.serialFilter=pattern;pattern
#
@@ -895,11 +895,37 @@
#
# The filter pattern uses the same format as jdk.serialFilter.
# This filter can override the builtin filter if additional types need to be
-# allowed or rejected from the RMI Registry.
+# allowed or rejected from the RMI Registry or to decrease limits but not
+# to increase limits.
+# If the limits (maxdepth, maxrefs, or maxbytes) are exceeded, the object is rejected.
+#
+# The maxdepth of any array passed to the RMI Registry is set to
+# 10000. The maximum depth of the graph is set to 20.
+# These limits can be reduced via the maxarray, maxdepth limits.
#
#sun.rmi.registry.registryFilter=pattern;pattern
#
+# Array construction of any component type, including subarrays and arrays of
+# primitives, are allowed unless the length is greater than the maxarray limit.
+# The filter is applied to each array element.
+#
+# The built-in filter allows subclasses of allowed classes and
+# can approximately be represented as the pattern:
+#
+#sun.rmi.registry.registryFilter=\
+# maxarray=1000000;\
+# maxdepth=20;\
+# java.lang.String;\
+# java.lang.Number;\
+# java.lang.reflect.Proxy;\
+# java.rmi.Remote;\
+# sun.rmi.server.UnicastRef;\
+# sun.rmi.server.RMIClientSocketFactory;\
+# sun.rmi.server.RMIServerSocketFactory;\
+# java.rmi.activation.ActivationID;\
+# java.rmi.server.UID
+#
# RMI Distributed Garbage Collector (DGC) Serial Filter
#
# The filter pattern uses the same format as jdk.serialFilter.
@@ -913,4 +939,25 @@
# java.rmi.server.UID;\
# java.rmi.dgc.VMID;\
# java.rmi.dgc.Lease;\
-# maxdepth=5;maxarray=10000
\ No newline at end of file
+# maxdepth=5;maxarray=10000
+
+# CORBA ORBIorTypeCheckRegistryFilter
+# Type check enhancement for ORB::string_to_object processing
+#
+# An IOR type check filter, if configured, is used by an ORB during
+# an ORB::string_to_object invocation to check the veracity of the type encoded
+# in the ior string.
+#
+# The filter pattern consists of a semi-colon separated list of class names.
+# The configured list contains the binary class names of the IDL interface types
+# corresponding to the IDL stub class to be instantiated.
+# As such, a filter specifies a list of IDL stub classes that will be
+# allowed by an ORB when an ORB::string_to_object is invoked.
+# It is used to specify a white list configuration of acceptable
+# IDL stub types which may be contained in a stringified IOR
+# parameter passed as input to an ORB::string_to_object method.
+#
+#
+# Note: This property is currently used by the JDK Reference implementation.
+# It is not guaranteed to be examined and used by other implementations.
+#
+#com.sun.CORBA.ORBIorTypeCheckRegistryFilter=binary_class_name;binary_class_name
Event Timeline
MoritzMuehlenhoff
created this paste.
Mar 22 2018, 10:47 AM
2018-03-22 10:47:17 (UTC+0)
Log In to Comment