7u161 Update Release Notes

Update Release Notes Index

Java™ SE Development Kit 7, Update 161 (JDK 7u161)

October 17, 2017

The full version string for this update release is 1.7.0_161-b13 (where "b" means "build"). The version number is 7u161.

IANA Data 2017b

JDK 7u161 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 7u161 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
7 1.7.0_161-b13
6 1.6.0_171-b13

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u161) will expire with the release of the next critical patch update scheduled for January 16, 2018.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 7u161) on February 16, 2018. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

Notes

install

Demo references in Solaris install documentation

Demos were removed from package tar.Z bundle (JDK-7066713). There is a separate Demos&Samples bundle beginning with 7u2 b08 and 6u32 b04, but Solaris patches still contain SUNWj7dmo/SUNWj6dmo. The 64 bit packages are SUNWj7dmx/SUNWj6dmx

Demo packages remain in the existing Solaris patches; however, just because they are there doesn't mean they are installed. They will be patched only if the end user has them installed on the system.

http://docs.oracle.com/javase/7/docs/webnotes/install/solaris/solaris-jdk.html

The link above is to the Solaris OS Install Directions for the JDK. The SUNWj7dmx package is mentioned in the tar.Z portion of the directions. This is confusing to some as, according to the cited bug, the SUNWj7dmx package shouldn't be part of the tar.Z bundle.

See JDK-8175866

core-libs/java.net

Default timeouts have changed for FTP URL handler

Timeouts used by the FTP URL protocol handler have been changed from infinite to 5 minutes. This will result in an IOException from connect and read operations if the FTP server is unresponsive. For example, new URL("ftp://example.com").openStream().read(), will fail with java.net.SocketTimeoutException in case a connection or reading could not be completed within 5 minutes.

To revert this behaviour to that of previous releases, the following system properties may be used, sun.net.client.defaultReadTimeout=0, sun.net.client.defaultConnectTimeout=0

JDK-8181612 (not public)

Certificate Changes

Remove revoked Swisscom root certificate "swisscomrootevca2"

One Swisscom root certificate has been revoked by Swisscom and has been removed:



Swisscom Root EV CA 2
alias: "swisscomrootevca2 [jdk]"
DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch

JDK-8186330 (not public)

Changes

deploy

JRE 6 and JRE 7 update releases will no longer include deployment technologies

Starting with the Oct 2017 Critical Patch Update, updates for JRE 6 and JRE 7 will no longer include the Java Deployment Technologies required for launching Java applications.

If an application requires a Java SE 6 or 7 JRE, the Java Deployment technology in JRE 8 release can be used to run such applications.

If you need this functionality, please refer to the following deployment invocation methods:

See also: Support Note: the Java SE Deployment Technology Support Lifetime (Doc ID 1640397.1)

JDK-8185747 (not public)

core-libs/java.util:collections

Collections use serialization filter to limit array sizes

Deserialization of certain collection instances will cause arrays to be allocated. The ObjectInputFilter.checkInput() method is now called prior to allocation of these arrays. Deserializing instances of ArrayDeque, ArrayList, IdentityHashMap, PriorityQueue, java.util.concurrent.CopyOnWriteArrayList, and the immutable collections (as returned by List.of, Set.of, and Map.of) will call checkInput() with a FilterInfo instance whose style="font-family: Courier New;">serialClass() method returns Object[].class. Deserializing instances of HashMap, HashSet, Hashtable, and Properties will call checkInput() with a FilterInfo instance whose serialClass() method returns Map.Entry[].class. In both cases, the FilterInfo.arrayLength() method will return the actual length of the array to be allocated. The exact circumstances under which the serialization filter is called, and with what information, is subject to change in future releases.

JDK-8174109 (not public)

security-libs/java.security

Refactor existing providers to refer to the same constants for default values for key length

Two important changes have been made for this issue:

  1. A new system property has been introduced that allows users to configure the default key size used by the JDK provider implementations of KeyPairGenerator and AlgorithmParameterGenerator. This property is named "jdk.security.defaultKeySize" and the value of this property is a list of comma-separated entries. Each entry consists of a case-insensitive algorithm name and the corresponding default key size (in decimal) separated by ":". In addition, white space is ignored.

    2. By default, this property will not have a value, and JDK providers will use their own default values. Entries containing an unrecognized algorithm name will be ignored. If the specified default key size is not a parseable decimal integer, that entry will be ignored as well.

  2. The DSA KeyPairGenerator implementation of the SUN provider no longer implements java.security.interfaces.DSAKeyPairGenerator. Applications which cast the SUN provider's DSA KeyPairGenerator object to a java.security.interfaces.DSAKeyPairGenerator can set the system property "jdk.security.legacyDSAKeyPairGenerator". If the value of this property is "true", the SUN provider will return a DSA KeyPairGenerator object which implements the java.security.interfaces.DSAKeyPairGenerator interface. This legacy implementation will use the same default value as specified by the javadoc in the interface.

    3. By default, this property will not have a value, and the SUN provider will return a DSA KeyPairGenerator object which does not implement the java.security.interfaces.DSAKeyPairGenerator interface and thus can determine its own provider-specific default value as stated in the java.security.KeyPairGenerator class or by the "jdk.security.defaultKeySize" system property if set.

JDK-8181048 (not public)

security-libs/java.security

New defaults for DSA keys in jarsigner and keytool

For DSA keys, the default signature algorithm for keytool and jarsigner has changed from SHA1withDSA to SHA256withDSA and the default key size for keytool has changed from 1024 bits to 2048 bits.

Users wishing to revert to the previous behavior can use the -sigalg option of keytool and jarsigner and specify SHA1withDSA and the -keysize option of keytool and specify 1024.

There are a few potential compatibility risks associated with this change:

  1. If you have a script that uses the default key size of keytool to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex:
    2. 
  
keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ...
keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey 
...

    it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA:

    

keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits

    The workaround is to remove the -sigalg option and use the stronger SHA256withDSA default or, at your own risk, use the -keysize option of keytool to specify a smaller key size (1024).

  2. If you use jarsigner to sign JARs with the new defaults, previous versions (than this release) of JDK 6 and 7 do not support the stronger defaults and will not be able to verify the JAR. jarsigner -verify on an earlier release of JDK 6 or 7 will output the following error:

    3. jar is unsigned. (signatures missing or not parsable)

    If you add -J-Djava.security.debug=jar to the jarsigner command line, the cause will be output:

    jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available

    If compatibility with earlier releases is important, you can, at your own risk, use the -sigalg option of jarsigner and specify the weaker SHA1withDSA algorithm.

  3. If you use a PKCS11 keystore, the SunPKCS11 provider does not support the SHA256withDSA algorithm. jarsigner and some keytool commands may fail with the following exception if PKCS11 is specified with the -storetype option, ex:

keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey

A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the -sigalg option of keytool and specify SHA1withDSA.

See JDK-8057810

Bug Fixes

This release contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 7u161 Bug Fixes page.

Known Issues

deploy

Windows - There is a Java icon in control panel after installing 6u171 or 7u161

The deployment features of 6u171 and 7u161 have been removed, as a result there is a "Java" icon in the Windows control panel after installing these versions.

Please use the built-in Windows installed programs control panel feature to determine the installed Java version after installing 6u171 or 7u161.

JDK-8185373 (not public)