openjdk-8 (8u362-ga-1) unstable; urgency=medium Upstream-provided “Notes on individual issues”: client-libs/javax.imageio: JDK-8295687: Better BMP bounds ============================== Loading a linked ICC profile within a BMP image is now disabled by default. To re-enable it, set the new system property `sun.imageio.bmp.enabledLinkedProfiles` to `true`. This new property replaces the old property, `sun.imageio.plugins.bmp.disableLinkedProfiles`. client-libs/javax.sound: JDK-8293742: Better Banking of Sounds ===================================== Previously, the SoundbankReader implementation, `com.sun.media.sound.JARSoundbankReader`, would download a JAR soundbank from a URL. This behaviour is now disabled by default. To re-enable it, set the new system property `jdk.sound.jarsoundbank` to `true`. other-libs/corba:idl: JDK-8285021: Improve CORBA communication ======================================== The JDK's CORBA implementation now refuses by default to deserialize objects, unless they have the "IOR:" prefix. The previous behaviour can be re-enabled by setting the new property `com.sun.CORBA.ORBAllowDeserializeObject` to `true`. security-libs/java.security: JDK-8269039: Disabled SHA-1 Signed JARs ======================================= JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. These restrictions also apply to signed JCE providers. To reduce the compatibility risk for JARs that have been previously timestamped, there is one exception to this policy: - Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted. This exception may be removed in a future JDK release. To determine if your signed JARs are affected by this change, run: $ jarsigner -verify -verbose -certs` on the signed JAR, and look for instances of "SHA1" or "SHA-1" and "disabled" and a warning that the JAR will be treated as unsigned in the output. For example: Signed by "CN="Signer"" Digest algorithm: SHA-1 (disabled) Signature algorithm: SHA1withRSA (disabled), 2048-bit key WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property: jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01 JARs affected by these new restrictions should be replaced or re-signed with stronger algorithms. Users can, *at their own risk*, remove these restrictions by modifying the `java.security` configuration file (or override it by using the `java.security.properties` system property) and removing "SHA1 usage SignedJAR & denyAfter 2019-01-01" from the `jdk.certpath.disabledAlgorithms` security property and "SHA1 denyAfter 2019-01-01" from the `jdk.jar.disabledAlgorithms` security property. -- Thorsten Glaser Sun, 29 Jan 2023 11:48:13 +0100 openjdk-8 (8u352-ga-1) unstable; urgency=medium Warning: JVM_Exit and the ability to run finalisers on exit are gone as part of aligning OpenJDK with an updated reference implementation. These apparently were not well supported before and the removed symbol was considered private, anyway. Upstream-provided “Notes on individual issues”: core-libs/java.lang: JDK-8201793: (ref) Reference object should not support cloning ============================================================== `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`. `Reference` objects cannot be meaningfully cloned. To create a new Reference object, call the constructor to create a `Reference` object with the same referent and reference queue instead. JDK-8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing ====================================================================== `java.lang.ref.Reference.enqueue` method clears the reference object before it is added to the registered queue. When the `enqueue` method is called, the reference object is cleared and `get()` method will return null in OpenJDK 8u352. Typically when a reference object is enqueued, it is expected that the reference object is cleared explicitly via the `clear` method to avoid memory leak because its referent is no longer referenced. In other words the `get` method is expected not to be called in common cases once the `enqueue`method is called. In the case when the `get` method from an enqueued reference object and existing code attempts to access members of the referent, `NullPointerException` may be thrown. Such code will need to be updated. JDK-8071507: (ref) Clear phantom reference as soft&weak references do ===================================================================== This enhancement changes phantom references to be automatically cleared by the garbage collector as soft and weak references. An object becomes phantom reachable after it has been finalized. This change may cause the phantom reachable objects to be GC'ed earlier - previously the referent is kept alive until PhantomReference objects are GC'ed or cleared by the application. This potential behavioral change might only impact existing code that would depend on PhantomReference being enqueued rather than when the referent be freed from the heap. core-libs/java.net: JDK-8286918: Better HttpServer service ====================================== The HttpServer can be optionally configured with a maximum connection limit by setting the jdk.httpserver.maxConnections system property. A value of 0 or a negative integer is ignored and considered to represent no connection limit. In the case of a positive integer value, any newly accepted connections will be first checked against the current count of established connections and, if the configured limit has been reached, then the newly accepted connection will be closed immediately. security-libs/javax.net.ssl: JDK-8282859: Enable TLSv1.3 by Default on JDK 8 for Client Roles ================================================================ The TLSv1.3 implementation is now enabled by default for client roles in 8u352. It has been enabled by default for server roles since 8u272. Note that TLS 1.3 is not directly compatible with previous versions. Enabling it on the client may introduce compatibility issues on either the server or the client side. Here are some more details on potential compatibility issues that you should be aware of: * TLS 1.3 uses a half-close policy, while TLS 1.2 and prior versions use a duplex-close policy. For applications that depend on the duplex-close policy, there may be compatibility issues when upgrading to TLS 1.3. * The signature_algorithms_cert extension requires that pre-defined signature algorithms are used for certificate authentication. In practice, however, an application may use non-supported signature algorithms. * The DSA signature algorithm is not supported in TLS 1.3. If a server is configured to only use DSA certificates, it cannot upgrade to TLS 1.3. * The supported cipher suites for TLS 1.3 are not the same as TLS 1.2 and prior versions. If an application hard-codes cipher suites which are no longer supported, it may not be able to use TLS 1.3 without modifying the application code. * The TLS 1.3 session resumption and key update behaviors are different from TLS 1.2 and prior versions. The compatibility should be minimal, but it could be a risk if an application depends on the handshake details of the TLS protocols. The TLS 1.3 protocol can be disabled by using the jdk.tls.client.protocols system property: java -Djdk.tls.client.protocols="TLSv1.2" ... Alternatively, an application can explicitly set the enabled protocols with the javax.net.ssl APIs e.g. sslSocket.setEnabledProtocols(new String[] {"TLSv1.2"}); or: SSLParameters params = sslSocket.getSSLParameters(); params.setProtocols(new String[] {"TLSv1.2"}); sslSocket.setSSLParameters(params); -- Thorsten Glaser Thu, 20 Oct 2022 18:11:00 +0200 openjdk-8 (8u312-b07-1) unstable; urgency=medium Upstream-provided “Notes on individual issues”: core-libs/java.net: JDK-8164200: Modified HttpURLConnection behavior w/o suitable proxy =================================================================== The behavior of HttpURLConnection when using a ProxySelector has been modified with this JDK release. HttpURLConnection used to fall back to a DIRECT connection attempt if the configured proxy(s) failed to make a connection. This release introduces a change whereby no DIRECT connection will be attempted in such a scenario. Instead, the HttpURLConnection.connect() method will fail and throw an IOException which occurred from the last proxy tested. security-libs/javax.net.ssl: JDK-8219551: Updated the Default Enabled Cipher Suites Preference ================================================================= The preference of the default enabled cipher suites has been changed. The compatibility impact should be minimal. If needed, applications can customize the enabled cipher suites and the preference. For more details, refer to the SunJSSE provider documentation and the JSSE Reference Guide documentation. -- Thorsten Glaser Fri, 05 Nov 2021 23:57:46 +0000 openjdk-8 (8u282-b08-2) unstable; urgency=medium Note about support for OpenJDK 8: - OpenJDK 8 was shipped with Debian 9 (“stretch”) and provided via jessie-backports for Debian 8; updates are shipped for both using the regular LTS and ELTS channels and policies, respectively. - Debian 10 (“buster”) and 11 (“bullseye”) ship with OpenJDK 11 supported. Therefore, OpenJDK 8 is not officially supported on these releases. - OpenJDK 8 is provided in Debian unstable (“sid”) but without any support whatsoever. It is intended to be used mainly to bootstrap certain JVM languages that don’t work with newer JDK. - In Ubuntu, OpenJDK 8 is nominally supported, but only for as long as 16.04 LTS (“xenial”) is still supported (regular support ended with April 2021, but ESM may still be available). - Please check with per-distribution, official, sources; this information is merely provided as heads-up note here and not guaranteed to be up-to-date. (This notice reflects the support info available to the packager at the time of writing.) -- Thorsten Glaser Thu, 25 Mar 2021 20:49:51 +0100