Package: release.debian.org Severity: normal X-Debbugs-Cc: gl...@packages.debian.org Control: affects -1 + src:glibc User: release.debian....@packages.debian.org Usertags: transition
Dear release team, I would like to get a transition slot for glibc 2.41. It has been available in experimental only for almost a month, and it looks in good state. I would also like to have this version in Trixie, in order to avoid shipping a one-year-old version in Trixie and to make the maintenance (i.e. backporting fixes) during the Trixie lifecycle simpler. It has been built successfully on all release architectures and most ports architectures. One important change is that starting with this version, the dlopen and dlmopen functions no longer make the stack executable if a shared library requires it and instead just fail. This change aims to improve security, as the previous behaviour was used as a vector for RCE (CVE-2023-38408). I have therefore scanned the archive (on amd64) to find ELF files with executable stack, and found this affects 45 packages. After excluding files not linked against glibc, binaries, libraries opened from a binary with an executable stack, and libraries that are clearly not used through dlopen, I ended up with the following list of possibly or surely affected packages: - mrgingham_1.24-2 - pdp_1:0.14.1+darcs20180201-6 - postgresql-pllua_1:2.0.12-3 - rccl_5.4.3-3 - rocm-hipamd_5.7.1-5 - swupdate_2024.12.1+dfsg-1 - uwsgi-plugin-pypy_0.0.2 In most of the cases the executable stack is due to a missing .note.GNU-stack note (which defines if the stack needs to be executable or not). Binutils defaulted to an executable stack in an absence of this note, but this has been changed in version 2.44-2 (which is now in testing). This means all the above except mrgingham can be fixed by a binNMU against binutils >= 2.44-2. For mrgingham, a patch is available in the BTS (#1098892). The experimental pseudo-excuses look good overall, besides the usual issues with britney and some packages that can't be really tested with experimental. The others are: - glibc/arm64: this is fixed in git - bart-cuda (not in testing): reported as #1096018 - mrgingham: reported as #1098892 - postgresql-pllua: reported as #1096038 (can be fixed with a binNMU) As glibc is using symbol versioning, there is no soname change. That said a few packages are using libc internal symbols and have to be rebuilt for this transition. Here is the corresponding ben file: title = "glibc"; is_affected = .depends ~ /libc[0-9.]* \(<</; is_good = .depends ~ /libc[0-9.]* \(<< 2.42\)/; is_bad = .depends ~ /libc[0-9.]* \(<< 2.41\)/; This version does not provide existing symbols with a GLIBC_2.41 version, however it adds the sched_setattr and sched_getattr symbols to libc and the acospi*, asinpi*, atan2pi*, atanpi*, cospi*, sinpi*, tanpi* ISO C23 trigonometric functions to libm. They are unlikely to be used at this point, so this should not block package migration to testing during the transition. Thanks for considering. Regards, Aurelien
