glibc (2.41-7) unstable; urgency=medium

  Starting with glibc 2.41, shared libraries requiring an executable stack
  cannot be dynamically loaded through the dlopen mechanism from a binary that
  does not require an executable stack. This change aims to improve security,
  as the previous behavior was used as a vector for RCE (CVE-2023-38408).
  Attempting to do so will result in the following error:

    cannot enable executable stack as shared object requires: Invalid argument

  While most libraries generated in the past 20 years do not require an
  executable stack, some third-party software still need this capability. Many
  vendors have already updated their binaries to address this.

  If you need to run a program that requires an executable stack through
  dynamic loaded shared libraries, you can use the glibc.rtld.execstack
  tunable:

    GLIBC_TUNABLES=glibc.rtld.execstack=2 ./program

 -- Aurelien Jarno <aurel32@debian.org>  Sun, 13 Apr 2025 14:41:11 +0200

glibc (2.32-0experimental1) experimental; urgency=medium

  The libc0.3-xen and libc6-xen packages have been removed in this version,
  due to the removal of the "nosegneg" support from glibc and due to the
  removal of 32-bit Xen PV support from Linux kernel 5.9. PVH or PVHVM guests
  should be used instead.

 -- Aurelien Jarno <aurel32@debian.org>  Tue, 24 Aug 2021 20:42:24 +0200

glibc (2.31-5) unstable; urgency=medium

  Starting with glibc 2.31-5, the NIS and NIS+ name service modules
  libnss_nis.so.2.0.0 and libnss_nisplus.so.2.0.0 are not provided anymore by
  the libc6 package. People needing those modules have to install the
  libnss-nis and/or the libnss-nisplus packages, which are recommended by
  the libc6 package.

 -- Aurelien Jarno <aurel32@debian.org>  Tue, 01 Dec 2020 08:42:44 +0100

glibc (2.31-0experimental2) experimental; urgency=medium

  Starting with glibc 2.31, the DNS stub resolver does not blindly trust the
  AD (authenticated data) flag, indicating a DNSSEC validation:

  - By default the name servers and the network path to them are treated as
    untrusted. In this mode, the AD flag is not set in queries, and it is
    automatically cleared in responses, indicating a lack of DNSSEC
    validation.

  - A new trust-ad option, set via the options directive in /etc/resolv.conf
    (or if RES_TRUSTAD is set in _res.options), indicates that the name
    server is trusted. In this mode, the AD bit, as provided by the name
    server, is made available to the applications.

  Therefore if you trust your name servers, for example because you use a
  locally running validating resolver (e.g. unbound, systemd-resolved or
  dnsmasq), you might want to add the following line to /etc/resolv.conf:

    options trust-ad

 -- Aurelien Jarno <aurel32@debian.org>  Sun, 17 May 2020 15:59:38 +0200
