pkgsrc-Changes-HG archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

[pkgsrc/trunk]: pkgsrc/lang/openjdk8 Update to 1.8.121



details:   https://anonhg.NetBSD.org/pkgsrc/rev/970190e14e17
branches:  trunk
changeset: 358033:970190e14e17
user:      ryoon <ryoon%pkgsrc.org@localhost>
date:      Sat Feb 04 01:16:30 2017 +0000

description:
Update to 1.8.121

Changelog:
http://www.oracle.com/technetwork/java/javase/8u121-relnotes-3315208.html

core-libs/javax.naming
Improved protection for JNDI remote class loading
Remote class loading via JNDI object factories stored in naming and directory services is disabled by default. To enable remote class loading by the RMI Registry or COS Naming service provider, set 
the following system property to the string "true", as appropriate:

    com.sun.jndi.rmi.object.trustURLCodebase
    com.sun.jndi.cosnaming.object.trustURLCodebase

JDK-8158997 (not public)


security-libs/java.security
jarsigner -verbose -verify should print the algorithms used to sign the jar
The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak.

Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, 
even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property, jdk.jar.disabledAlgorithms, it will be labeled with 
"(weak)".

For example:

- Signed by "CN=weak_signer"
   Digest algorithm: MD2 (weak)
   Signature algorithm: MD2withRSA (weak), 512-bit key (weak)
 Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016
   Timestamp digest algorithm: SHA-256
   Timestamp signature algorithm: SHA256withRSA, 2048-bit key

See JDK-8163304


New Features

core-libs/java.io:serialization
Serialization Filter Configuration
Serialization Filtering introduces a new mechanism which allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. Every ObjectInputStream 
applies a filter, if configured, to the stream contents during deserialization. Filters are set using either a system property or a configured security property. The value of the "jdk.serialFilter" 
patterns are described in JEP 290 Serialization Filtering and in <JRE>/lib/security/java.security. Filter actions are logged to the 'java.io.serialization' logger, if enabled.
See JDK-8155760


core-libs/java.rmi
RMI Better constraint checking
RMI Registry and Distributed Garbage Collection use the mechanisms of JEP 290 Serialization Filtering to improve service robustness.
RMI Registry and DGC implement built-in white-list filters for the typical classes expected to be used with each service.
Additional filter patterns can be configured using either a system property or a security property. The "sun.rmi.registry.registryFilter" and "sun.rmi.transport.dgcFilter" property pattern syntax is 
described in JEP 290 and in <JRE>/lib/security/java.security.
JDK-8156802 (not public)


security-libs
Add mechanism to allow non-default root CAs to not be subject to algorithm restrictions

*New certpath constraint: jdkCA*
In the java.security file, an additional constraint named "jdkCA" is added to the jdk.certpath.disabledAlgorithms property. This constraint prohibits the specified algorithm only if the algorithm is 
used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are 
restricted. jdkCA may only be used once in a DisabledAlgorithm expression.

Example: To apply this constraint to SHA-1 certificates, include the following: SHA1 jdkCA
See JDK-8140422


Changes

tools/javadoc(tool)
New --allow-script-in-comments option for javadoc
The javadoc tool will now reject any occurrences of JavaScript code in the javadoc documentation comments and command-line options, unless the command-line option, --allow-script-in-comments is 
specified.

With the --allow-script-in-comments option, the javadoc tool will preserve JavaScript code in documentation comments and command-line options. An error will be given by the javadoc tool if JavaScript 
code is found and the command-line option is not set.
JDK-8138725 (not public)


security-libs/javax.xml.crypto
Increase the minimum key length to 1024 for XML Signatures
The secure validation mode of the XML Signature implementation has been enhanced to restrict RSA and DSA keys less than 1024 bits by default as they are no longer secure enough for digital 
signatures. Additionally, a new security property named jdk.xml.dsig.SecureValidationPolicy has been added to the java.security file and can be used to control the different restrictions enforced 
when the secure validation mode is enabled.

The secure validation mode is enabled either by setting the xml signature property org.jcp.xml.dsig.secureValidation to true with the javax.xml.crypto.XMLCryptoContext.setProperty method, or by 
running the code with a SecurityManager.

If an XML Signature is generated or validated with a weak RSA or DSA key, an XMLSignatureException will be thrown with the message, "RSA keys less than 1024 bits are forbidden when secure validation 
is enabled" or "DSA keys less than 1024 bits are forbidden when secure validation is enabled."
JDK-8140353 (not public)


docs/release_notes
Restrict certificates with DSA keys less than 1024 bits.
DSA keys less than 1024 bits are not strong enough and should be restricted in certification path building and validation. Accordingly, DSA keys less than 1024 bits have been deactivated by default 
by adding "DSA keySize < 1024" to the "jdk.certpath.disabledAlgorithms" security property. Applications can update this restriction in the security property ("jdk.certpath.disabledAlgorithms") and 
permit smaller key sizes if really needed (for example, "DSA keySize < 768").
JDK-8139565 (not public)


security-libs
More checks added to DER encoding parsing code
More checks are added to the DER encoding parsing code to catch various encoding errors. In addition, signatures which contain constructed inparsing. Note that signatures generated using JDK default 
providers are not affected by this change.
JDK-8168714 (not public)


core-libs/java.net
Additional access restrictions for URLClassLoader.newInstance
Class loaders created by the java.net.URLClasslasses from a list of given URLs. If the calling code does not have access to one or more of the URLs and the URL artifacts that can be accessed do not 
contain the required class, then a ClassNotFoundException, or similar, will be thrown. Previously, a Sege can be disabled by setting the jdk.net.URLClassPath.disableRestrictedPermissions system 
property.
JDK-8151934 (not public)

core-libs/java.util.logging
A new configurable property in logging.properties java.util.logging.FileHandler.maxLocks
A new "java.util.logging.FileHandler.maxLocks" configurable property is added to java.util.logging.FileHandler.

This new logging property can be defined in the logging configuration file and makes it possible to configure the maximum number of concurrent log file locks a FileHandler can handle. The default 
value is 100.

In a highly concurrent environment where multiple (more than 101) standalone client applications are using the JDK Logging API with FileHandler simultaneously, it may happen that the default limit of 
100 is reached, resulting in a failure to acquire FileHandler file locks and causing an IO Exception to be thrown. In such a case, the new logging property can be used to increase the maximum number 
of locks before deploying the application.

If not overridden, the default value of maxLocks (100) remains unchanged. See java.util.logging.LogManager and java.util.logging.FileHandler API documentation for more details.
See JDK-8153955

Bug Fixes

The following are some of the notable bug fixes included in this release:

client-libs/javax.swing
Trackpad scrolling of text on OS X 10.12 Sierra is very fast
The MouseWheelEvent.getWheelRotation() method returned rounded native NSEvent deltaX/Y events on Mac OS X. The latest macOS Sierra 10.12 produces very small NSEvent deltaX/Y values so rounding and 
summing them leads to the huge value returned from the MouseWheelEvent.getWheelRotation(). The JDK-8166591 fix accumulates NSEvent deltaX/Y and the MouseWheelEvent.getWheelRotation() method returns 
non-zero values only when the accumulated value exceeds a threshold and zero value. This is compliant with the MouseWheelEvent.getWheelRotation() specification 
(https://docs.oracle.com/javase/8/docs/api/java/awt/event/MouseWheelEvent.html#getWheelRotation):

"Returns the number of "clicks" the mouse wheel was rotated, as an integer. A partial rotation may occur if the mouse supports a high-resolution wheel. In this case, the method returns zero until a 
full "click" has been accumulated."

For the precise wheel rotation values, use the MouseWheelEvent.getPreciseWheelRotation() method instead.
See JDK-8166591

This release also contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see 
the JDK 8u121 Bug Fixes page.


Known Issues

deploy/packager
javapackager and fx:deploy bundle the whole JDK instead of JRE
There is a known bug in the Java Packager for Mac where the entire JDK may be bundled with the application bundle resulting in an unusually large bundle. The work around is to use the bundler option 
-Bruntime option. For example: -Bruntime=JavaAppletPlugin.plugin sets where the JavaAppletPlugin.plugin for the desired JRE to bundle is located in the current directory.
See JDK-8166835

install/install
Java Installation will fail for non-admin users with UAC off
The Java installation on Windows will fail without warning or prompting, for non-admin users with User Access Control (UAC) disabled. The installer will leave a directory, jds<number>.tmp, in the 
%TEMP% directory.
JDK-8161460 (not public)

diffstat:

 lang/openjdk8/Makefile |   7 +++----
 lang/openjdk8/distinfo |  10 +++++-----
 2 files changed, 8 insertions(+), 9 deletions(-)

diffs (39 lines):

diff -r 65353443aa5a -r 970190e14e17 lang/openjdk8/Makefile
--- a/lang/openjdk8/Makefile    Fri Feb 03 17:14:35 2017 +0000
+++ b/lang/openjdk8/Makefile    Sat Feb 04 01:16:30 2017 +0000
@@ -1,8 +1,7 @@
-# $NetBSD: Makefile,v 1.43 2016/12/15 23:56:53 joerg Exp $
+# $NetBSD: Makefile,v 1.44 2017/02/04 01:16:30 ryoon Exp $
 
-DISTNAME=      openjdk-1.8.112-20161027
-PKGNAME=       openjdk8-1.8.112
-PKGREVISION=   1
+DISTNAME=      openjdk-1.8.121-20170131
+PKGNAME=       openjdk8-1.8.121
 CATEGORIES=    lang
 MASTER_SITES=  ${MASTER_SITE_LOCAL:=openjdk7/}
 EXTRACT_SUFX=  .tar.xz
diff -r 65353443aa5a -r 970190e14e17 lang/openjdk8/distinfo
--- a/lang/openjdk8/distinfo    Fri Feb 03 17:14:35 2017 +0000
+++ b/lang/openjdk8/distinfo    Sat Feb 04 01:16:30 2017 +0000
@@ -1,4 +1,4 @@
-$NetBSD: distinfo,v 1.43 2016/12/15 23:56:53 joerg Exp $
+$NetBSD: distinfo,v 1.44 2017/02/04 01:16:30 ryoon Exp $
 
 SHA1 (openjdk7/bootstrap-jdk-1.7.76-freebsd-10-amd64-20150301.tar.xz) = 7408f52d3bbe35c2b14bbd3215cbf60f1335d334
 RMD160 (openjdk7/bootstrap-jdk-1.7.76-freebsd-10-amd64-20150301.tar.xz) = 24f1577b5fc86d137f070aedb4610c8c89e45815
@@ -44,10 +44,10 @@
 RMD160 (openjdk7/bootstrap-jdk7u60-bin-dragonfly-3.8-amd64-20140719.tar.bz2) = b13d0e42839fb746d41f9001e488162b47803140
 SHA512 (openjdk7/bootstrap-jdk7u60-bin-dragonfly-3.8-amd64-20140719.tar.bz2) = 
1403e582dacd0474e57d9aa8f1333060c50d099ef5d2c5a992ff7f63dcde2e538ff1e7fb78e45d12fd5aea6daf0704672e7f326399d415ee0d6bb53b6f925e9f
 Size (openjdk7/bootstrap-jdk7u60-bin-dragonfly-3.8-amd64-20140719.tar.bz2) = 37883700 bytes
-SHA1 (openjdk7/openjdk-1.8.112-20161027.tar.xz) = a1ffe7e3530a4076d2bb2f89b4ed7e964658e851
-RMD160 (openjdk7/openjdk-1.8.112-20161027.tar.xz) = 1dd7f5f586f256b133c802fb30df8d9ecbc6452f
-SHA512 (openjdk7/openjdk-1.8.112-20161027.tar.xz) = 301c1fdc803f227cd4cd2bd5c70a7c895097643ad9f089412bfa5b9b329a2bdef26b1c9e24f4dfd1617ed3a24efb59d05ff876687998ca781ed5922d6f5e01da
-Size (openjdk7/openjdk-1.8.112-20161027.tar.xz) = 55348620 bytes
+SHA1 (openjdk7/openjdk-1.8.121-20170131.tar.xz) = 27d39a21eede04b49e578cac3c8255cb6cf642fe
+RMD160 (openjdk7/openjdk-1.8.121-20170131.tar.xz) = 21bddcb4a8226f9ce6c2c1a912c1bfe3df86b75d
+SHA512 (openjdk7/openjdk-1.8.121-20170131.tar.xz) = 7674a466316a35966dab15e3252569364fe25941b3e378b08874b73f00e8347172a7eac77a41c81ea2476ac4a683bc87958ac54dd4b473d34e3fe3476509d338
+Size (openjdk7/openjdk-1.8.121-20170131.tar.xz) = 55385512 bytes
 SHA1 (patch-aa) = fd07ea984cb0127b56a9b591c21c8d4f236fd9fc
 SHA1 (patch-al) = f65f739805c2ef471a4de10d6da42e86c5561b8c
 SHA1 (patch-an) = fce4da00762770c1c0592bd225bf73e875252178



Home | Main Index | Thread Index | Old Index