openjdk-8 (8u442-ga-1) unstable; urgency=low

  Upstream-provided “Notes on individual issues” as applicable:

  core-libs/java.util.jar:

  JDK-8335912/JDK-8337499: Add an operation mode to the jar command when
                           extracting to not overwriting existing files
  ======================================================================
  In previous OpenJDK releases, when the jar tool extracted files from
  an archive, it would overwrite any existing files with the same name
  in the target directory. With this release, a new option ('-k') may be
  specified so that existing files are not overwritten.

  The option may be specified as in the following example:

  * jar xkf foo.jar

  By default, the old behaviour remains in place and files will be
  overwritten.

 -- Thorsten Glaser <tg@mirbsd.de>  Sun, 09 Feb 2025 20:41:52 +0100

openjdk-8 (8u432-b06-1) unstable; urgency=medium

  Upstream-provided “Notes on individual issues” as applicable:

  security-libs/javax.net.ssl:

  JDK-8279164: Disable TLS_ECDH_* cipher suites
  =============================================
  The TLS_ECDH cipher suites do not preserve forward secrecy and are
  rarely used in practice. With this release, they are disabled by
  adding "ECDH" to the `jdk.tls.disabledAlgorithms` security property in
  the `java.security` configuration file. Attempts to use these suites
  with this release will result in a `SSLHandshakeException` being
  thrown. Note that ECDH cipher suites which use RC4 were already
  disabled prior to this change.

  Users can, *at their own risk*, remove this restriction by modifying
  the `java.security` configuration file (or override it by using the
  `java.security.properties` system property) so "ECDH" is no longer
  listed in the `jdk.tls.disabledAlgorithms` security property.

  This change has no effect on TLS_ECDHE cipher suites, which remain
  enabled by default.

  JDK-8337664: Distrust TLS server certificates issued after Oct 2024 and
               anchored by Entrust Root CAs
  JDK-8341059: Change Entrust TLS distrust date to November 12, 2024
  =======================================================================
  In accordance with similar plans recently announced by Google and
  Mozilla, the JDK will not trust Transport Layer Security (TLS)
  certificates issued after the 11th of November 2024 which are anchored
  by Entrust root certificates.  This includes certificates branded as
  AffirmTrust, which are managed by Entrust.

  Certificates issued on or before November 11th, 2024 will continue to
  be trusted until they expire.

  If a server's certificate chain is anchored by an affected
  certificate, attempts to negotiate a TLS session will fail with an
  Exception that indicates the trust anchor is not trusted. For example,

  "TLS server certificate issued after 2024-11-11 and anchored by a
  distrusted legacy Entrust root CA: CN=Entrust.net Certification
  Authority (2048), OU=(c) 1999 Entrust.net Limited,
  OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),
  O=Entrust.net"

  To check whether a certificate in a JDK keystore is affected by this
  change, you can the `keytool` utility:

  keytool -v -list -alias <your_server_alias> -keystore <keystore_filename>

  If any of the certificates in the chain are affected by this change,
  then you will need to update the certificate or contact the
  organisation responsible for managing the certificate.

  These restrictions apply to the following Entrust root certificates
  included in the JDK:

  Alias name: entrustevca [jdk]
  CN=Entrust Root Certification Authority
  OU=(c) 2006 Entrust, Inc.
  OU=www.entrust.net/CPS is incorporated by reference
  O=Entrust, Inc.
  C=US
  SHA256: 73:C1:76:43:4F:1B:C6:D5:AD:F4:5B:0E:76:E7:27:28:\
          7C:8D:E5:76:16:C1:E6:E6:14:1A:2B:2C:BC:7D:8E:4C

  Alias name: entrustrootcaec1 [jdk]
  CN=Entrust Root Certification Authority - EC1
  OU=(c) 2012 Entrust, Inc. - for authorized use only
  OU=See www.entrust.net/legal-terms
  O=Entrust, Inc.
  C=US
  SHA256: 02:ED:0E:B2:8C:14:DA:45:16:5C:56:67:91:70:0D:64:\
          51:D7:FB:56:F0:B2:AB:1D:3B:8E:B0:70:E5:6E:DF:F5

  Alias name: entrustrootcag2 [jdk]
  CN=Entrust Root Certification Authority - G2
  OU=(c) 2009 Entrust, Inc. - for authorized use only
  OU=See www.entrust.net/legal-terms
  O=Entrust, Inc.
  C=US
  SHA256: 43:DF:57:74:B0:3E:7F:EF:5F:E4:0D:93:1A:7B:ED:F1:\
          BB:2E:6B:42:73:8C:4E:6D:38:41:10:3D:3A:A7:F3:39

  Alias name: entrustrootcag4 [jdk]
  CN=Entrust Root Certification Authority - G4
  OU=(c) 2015 Entrust, Inc. - for authorized use only
  OU=See www.entrust.net/legal-terms
  O=Entrust, Inc.
  C=US
  SHA256: DB:35:17:D1:F6:73:2A:2D:5A:B9:7C:53:3E:C7:07:79:\
          EE:32:70:A6:2F:B4:AC:42:38:37:24:60:E6:F0:1E:88

  Alias name: entrust2048ca [jdk]
  CN=Entrust.net Certification Authority (2048)
  OU=(c) 1999 Entrust.net Limited
  OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)
  O=Entrust.net
  SHA256: 6D:C4:71:72:E0:1C:BC:B0:BF:62:58:0D:89:5F:E2:B8:\
          AC:9A:D4:F8:73:80:1E:0C:10:B9:C8:37:D2:1E:B1:77

  Alias name: affirmtrustcommercialca [jdk]
  CN=AffirmTrust Commercial
  O=AffirmTrust
  C=US
  SHA256: 03:76:AB:1D:54:C5:F9:80:3C:E4:B2:E2:01:A0:EE:7E:\
          EF:7B:57:B6:36:E8:A9:3C:9B:8D:48:60:C9:6F:5F:A7

  Alias name: affirmtrustnetworkingca [jdk]
  CN=AffirmTrust Networking
  O=AffirmTrust
  C=US
  SHA256: 0A:81:EC:5A:92:97:77:F1:45:90:4A:F3:8D:5D:50:9F:\
          66:B5:E2:C5:8F:CD:B5:31:05:8B:0E:17:F3:F0B4:1B

  Alias name: affirmtrustpremiumca [jdk]
  CN=AffirmTrust Premium
  O=AffirmTrust
  C=US
  SHA256: 70:A7:3F:7F:37:6B:60:07:42:48:90:45:34:B1:14:82:\
          D5:BF:0E:69:8E:CC:49:8D:F5:25:77:EB:F2:E9:3B:9A

  Alias name: affirmtrustpremiumeccca [jdk]
  CN=AffirmTrust Premium ECC
  O=AffirmTrust
  C=US
  SHA256: BD:71:FD:F6:DA:97:E4:CF:62:D1:64:7A:DD:25:81:B0:\
          7D:79:AD:F8:39:7E:B4:EC:BA:9C:5E:84:88:82:14:23

  Users can, *at their own risk*, remove this restriction by modifying
  the `java.security` configuration file (or override it by using the
  `java.security.properties` system property) so "ENTRUST_TLS" is no
  longer listed in the `jdk.security.caDistrustPolicies` security
  property.

  client-libs:

  JDK-8307779: Relax the java.awt.Robot specification
  ===================================================
  This release of OpenJDK 8 updates to the latest maintenance release of
  the Java 8 specification. This relaxes the specification of three
  methods in the `java.awt.Robot` class - `mouseMove(int,int)`,
  `getPixelColor(int,int)` and `createScreenCapture(Rectangle)` - to
  allow these methods to fail when the desktop environment does not
  permit moving the mouse pointer or capturing screen content.

  core-libs/javax.naming:

  JDK-8290367, JDK-8332643: Update default value and extend the scope of
                            com.sun.jndi.ldap.object.trustSerialData
                            system property
  ======================================================================
  With this OpenJDK release, the JDK implementation of the LDAP provider
  no longer supports the deserialisation of Java objects by
  default. This is achieved by the system property
  `com.sun.jndi.ldap.object.trustSerialData` being set to `false` by
  default.

  Note that this release also increases the scope of the
  `com.sun.jndi.ldap.object.trustSerialData` to cover the reconstruction
  of RMI remote objects from the `javaRemoteLocation` LDAP attribute.

  The result of this change is that transparent deserialisation of Java
  objects will require an explicit opt-in. Applications that wish to
  reconstruct Java objects and RMI stubs from LDAP attributes will need
  to set the `com.sun.jndi.ldap.object.trustSerialData` to `true`.

  core-libs/java.net:

  JDK-8328286: Enhance HTTP client
  ================================
  This OpenJDK release limits the maximum header field size accepted by
  the HTTP client within the JDK for all supported versions of the HTTP
  protocol. The header field size is computed as the sum of the size of
  the uncompressed header name, the size of the uncompressed header
  value and a overhead of 32 bytes for each field section line. If a
  peer sends a field section that exceeds this limit, a
  `java.net.ProtocolException` will be raised.

  This release also introduces a new system property,
  `jdk.http.maxHeaderSize`. This property can be used to alter the
  maximum header field size (in bytes) or disable it by setting the
  value to zero or a negative value. The default value is 393,216 bytes
  or 384kB.

  core-libs/java.util.jar:

  JDK-8193682: Infinite loop in ZipOutputStream.close()
  =====================================================
  In previous releases, the `DeflaterOutputStream.close()`,
  `GZIPOutputStream.finish()` and `ZipOutputStream.closeEntry()` methods
  did not close the associated default JDK compressor when an exception
  was thrown during closure.  With this release, the default compressor
  is closed before propogating the Throwable up the stack. In the case
  of `ZipOutputStream`, this only happens when the exception is not a
  `ZipException`.

 -- Thorsten Glaser <tg@mirbsd.de>  Sun, 09 Feb 2025 20:40:32 +0100

openjdk-8 (8u422-b05-1) unstable; urgency=medium

  Upstream-provided “Notes on individual issues” as applicable:

  core-libs/java.net:

  JDK-8278067: Make HttpURLConnection Default Keep Alive Timeout Configurable
  ===========================================================================
  Two system properties have been added which control the keep alive
  behaviour of HttpURLConnection in the case where the server does not
  specify a keep alive time. These are:

  * `http.keepAlive.time.server`
  * `http.keepAlive.time.proxy`

  which control the number of seconds before an idle connection to a
  server or proxy will be closed, respectively. If the server or proxy
  specifies a keep alive time in a "Keep-Alive" response header, this
  will take precedence over the values of these properties.

 -- Thorsten Glaser <tg@mirbsd.de>  Fri, 19 Jul 2024 21:29:27 +0200

openjdk-8 (8u412-ga-1) unstable; urgency=medium

  Upstream-provided “Notes on individual issues” as applicable:

  security-libs/org.ietf.jgss:krb5:

  JDK-8168518: rcache interop with krb5-1.15
  ==========================================
  The hash algorithm used in the Kerberos 5 replay cache file (rcache)
  has been changed from MD5 to SHA256. This is the same algorithm used
  by MIT krb5-1.15 and is interoperable with earlier releases of MIT
  krb5.

  The MD5 algorithm can still be used by setting the new
  jdk.krb5.rcache.useMD5 property to 'true':

  java -Djdk.krb5.rcache.useMD5=true ...

  This is useful where either the system has a coarse clock and has to
  depend on hash values in replay attack detection, or interoperability
  with the rcache files in older versions of OpenJDK is required.

  client-libs/java.awt:

  JDK-8322750: AWT SystemTray API Is Not Supported on Most Linux Desktops
  =======================================================================
  The java.awt.SystemTray API is used to interact with the system's
  desktop taskbar to provide notifications and may include an icon
  representing an application. The GNOME desktop's support for taskbar
  icons has not worked properly for several years, due to a platform
  bug. This bug, in turn, affects the JDK's SystemTray support on GNOME
  desktops.

  Therefore, in accordance with the SystemTray API specification,
  java.awt.SystemTray.isSupported() will now return false on systems
  that exhibit this bug, which is assumed to be those running a version
  of GNOME Shell below 45.

  The impact of this change is likely to be minimal, as users of the
  SystemTray API should already be able to handle isSupported()
  returning false and the system tray on such platforms has already been
  unsupported for a number of years for all applications.

 -- Thorsten Glaser <tg@mirbsd.de>  Fri, 19 Apr 2024 23:12:48 +0200

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 <tg@mirbsd.de>  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 <tg@mirbsd.de>  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 <tg@mirbsd.de>  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 <tg@mirbsd.de>  Thu, 25 Mar 2021 20:49:51 +0100
