On 2025-02-26 09:30, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > Hi Aurelien, > > On 26/02/2025 06:34, Aurelien Jarno wrote: > > 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. > > Go ahead.
Thanks, I have just uploaded it. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
