Bug#1098925: transition: glibc 2.41

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: ***@packages.debian.org
Control: affects -1 + src:glibc
User: ***@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

[Debian Bug Tracking System]

Post by Aurelien Jarno
affects -1 + src:glibc

Bug #1098925 [release.debian.org] transition: glibc 2.41
Added indication that 1098925 affects src:glibc

[Sebastian Ramacher]

Post by Aurelien Jarno
Package: release.debian.org
Severity: normal
Control: affects -1 + src:glibc
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
- 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).

binNMUs for those have been scheduled.

Cheers

Post by Aurelien Jarno
The experimental pseudo-excuses look good overall, besides the usual
issues with britney and some packages that can't be really tested with
- 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
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

[Debian Bug Tracking System]

tags -1 confirmed

Bug #1098925 [release.debian.org] transition: glibc 2.41
Added tag(s) confirmed.

[Aurelien Jarno]

Control: tags -1 confirmed
Hi Aurelien,

Post by Aurelien Jarno
Package: release.debian.org
Severity: normal
Control: affects -1 + src:glibc
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
- 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
- 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
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

[Sebastian Ramacher]

Post by Aurelien Jarno

Control: tags -1 confirmed
Hi Aurelien,

Post by Aurelien Jarno
Package: release.debian.org
Severity: normal
Control: affects -1 + src:glibc
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
- 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
- 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
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

[Aurelien Jarno]

Post by Sebastian Ramacher

Post by Aurelien Jarno

Go ahead.

Thanks, I have just uploaded it.

Unfortunately this version has a serious bug due to a multiarch
conflict with lintian override files. I have just uploaded version
2.41-3 to fix that.

Anyway I have started to look briefly at autopkgtest regressions, and it
appears that my assumption that checking executable stack only on amd64
was going to be representative for all architecture was wrong. It seems
that at least hand written neon code on armel/armhf also causes the
stack to be executable. I'll scan the archive on other architectures but
that will take some time... In the meantime I have already found:

nmu 3 libde265 . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu libmad . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu x264 . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"

That will probably requires a new upload to add the corresponding
breaks, but I'll do that once I have collected all of them. And maybe
it'll be acceptable to leave the glibc package migrate to testing anyway
and fix that afterwards.

Also it seems that britney decided to group glibc with a few unrelated
packages, let's hope it'll do better for 2.41-3.

Post by Sebastian Ramacher
Thanks, binNMUs with --extra-depends "libc-bin (>= 2.41)" scheduled.

Thanks. Could you please also binNMU dante on non-time64 architectures?
It is only in sid for that reason, but that should make the package
installable again for those architectures.

nmu dante . amd64 arm64 i386 mips64el ppc64el riscv64 s390x hurd-amd64 hurd-i386 loong64 ppc64 sparc64 x32 . -m "Rebuild against glibc 2.41" --extra-depends "libc-bin (>= 2.41)"

Thanks
Aurelien

[Sebastian Ramacher]

Post by Aurelien Jarno

Post by Sebastian Ramacher

Post by Aurelien Jarno

Go ahead.

Thanks, I have just uploaded it.

Unfortunately this version has a serious bug due to a multiarch
conflict with lintian override files. I have just uploaded version
2.41-3 to fix that.

Thanks.

Post by Aurelien Jarno
Anyway I have started to look briefly at autopkgtest regressions, and it
appears that my assumption that checking executable stack only on amd64
was going to be representative for all architecture was wrong. It seems
that at least hand written neon code on armel/armhf also causes the
stack to be executable. I'll scan the archive on other architectures but
nmu 3 libde265 . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu libmad . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu x264 . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"

Scheduled.

Post by Aurelien Jarno
That will probably requires a new upload to add the corresponding
breaks, but I'll do that once I have collected all of them. And maybe
it'll be acceptable to leave the glibc package migrate to testing anyway
and fix that afterwards.

I think we can postpone them to the next upload.

Post by Aurelien Jarno
Also it seems that britney decided to group glibc with a few unrelated
packages, let's hope it'll do better for 2.41-3.

Post by Sebastian Ramacher
Thanks, binNMUs with --extra-depends "libc-bin (>= 2.41)" scheduled.

Thanks. Could you please also binNMU dante on non-time64 architectures?
It is only in sid for that reason, but that should make the package
installable again for those architectures.
nmu dante . amd64 arm64 i386 mips64el ppc64el riscv64 s390x hurd-amd64 hurd-i386 loong64 ppc64 sparc64 x32 . -m "Rebuild against glibc 2.41" --extra-depends "libc-bin (>= 2.41)"

Also scheduled.

Cheers

[Aurelien Jarno]

Hi Sebastian,

Post by Sebastian Ramacher

Post by Aurelien Jarno
Anyway I have started to look briefly at autopkgtest regressions, and it
appears that my assumption that checking executable stack only on amd64
was going to be representative for all architecture was wrong. It seems
that at least hand written neon code on armel/armhf also causes the
stack to be executable. I'll scan the archive on other architectures but
nmu 3 libde265 . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu libmad . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu x264 . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"

Scheduled.

Thanks.

I have finished scanning the archive for the other architectures.
Fortunately the number of affected packages are limited. I have found
the following binNMUs are needed:

For armel/armhf:
nmu doublecmd . armel armhf . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu 3 mpeg2dec . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu ne10 . armel armhf . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu pdbg . armel ppc64el ppc64 . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"

For armel/armhf/s390x:
nmu openblas . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"

For i386:
nmu 3 libfec_1.0-26-gc5d935f-1 . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"

Note that I am sure about the architectures for doublecmd, I do not
think we need multiarch sync, but I might be wrong.

Cheers
Aurelien

[Sebastian Ramacher]

Post by Aurelien Jarno
Hi Sebastian,

Post by Sebastian Ramacher

Post by Aurelien Jarno
Anyway I have started to look briefly at autopkgtest regressions, and it
appears that my assumption that checking executable stack only on amd64
was going to be representative for all architecture was wrong. It seems
that at least hand written neon code on armel/armhf also causes the
stack to be executable. I'll scan the archive on other architectures but
nmu 3 libde265 . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu libmad . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu x264 . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"

Scheduled.

Thanks.
I have finished scanning the archive for the other architectures.
Fortunately the number of affected packages are limited. I have found
nmu doublecmd . armel armhf . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu 3 mpeg2dec . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu ne10 . armel armhf . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu pdbg . armel ppc64el ppc64 . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu openblas . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"
nmu 3 libfec_1.0-26-gc5d935f-1 . ANY . -m "Rebuild with binutils >= 2.44-2 to build without executable stack" --extra-depends "binutils (>= 2.44-2)"

All scheduled.

Post by Aurelien Jarno
Note that I am sure about the architectures for doublecmd, I do not
think we need multiarch sync, but I might be wrong.

It doesn't build any MA: same packages, so we don't need to sync it.

Cheers