On 2025-02-28 19:04:25 +0100, Aurelien Jarno wrote: > 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: [email protected] > > > Control: affects -1 + src:glibc > > > User: [email protected] > > > 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.
Thanks, binNMUs with --extra-depends "libc-bin (>= 2.41)" scheduled. Cheers -- Sebastian Ramacher
