Bug#1063088: weston: NMU diff for 64-bit time_t transition
On Wed, Mar 06, 2024 at 10:42:16AM +0100, Dylan Aïssi wrote: > Hello, > Le lun. 5 févr. 2024 à 02:54, Steve Langasek a écrit : > > If you have any concerns about this patch, please reach out ASAP. Although > > this package will be uploaded to experimental immediately, there will be a > > period of several days before we begin uploads to unstable; so if > > information > > becomes available that your package should not be included in the > > transition, > > there is time for us to amend the planned uploads. > I am wondering what is the plan with this package/bug? I noticed that changes > related to the 64-bit time_t transition were not uploaded to unstable and > because I uploaded several versions in unstable after your NMU in exp, I > wonder if I haven't interfered with this transition. Sorry, yes, the uploads with renaming of both dev package and runtime lib package in the midst of the transition resulted in this package being lost. Since this is a completely new soname, and only packages built from weston source depend on it, I suggest that you simply request a binNMU of weston on armhf and armel and consider this resolved. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#1065551: spirv-headers: please update to commit b73e168ca5e123dcf3dea8a34b19a5130f421ae1 or later
Source: spirv-headers Version: 1.6.1+1.3.275.0-1 Severity: wishlist Hi, spirv-llvm-translator upstream just had in its llvm_release_180 branch a commit (d970c9126c033ebcbb7187bc705eae2e54726b74) pushed that bumps the header dependency to b73e168ca5e123dcf3dea8a34b19a5130f421ae1 for using SPV_INTEL_maximum_registers. This will be part of the 18.0.0 release soon and in order to package that we need some newer spirv-headers packaged, too. AFAICS there is no new spirv-headers tag yet that includes this commit. Thanks Andreas
Bug#1065542: libxxf86vm1: Please rebuild to avoid overly huge ELF segment alignment
Package: libxxf86vm1 Version: 1:1.1.4-1+b2 Severity: normal X-Debbugs-Cc: mini...@grsecurity.net Dear Maintainer, After investigating ELF binaries and libraries on Debian systems, I noticed that libxxf86vm1 uses an overly huge alignemnt for its segments. This will lead to an unnecessary ASLR degradation for (transitive) users of this library like cinnamon or gnome-software. Below is the relevant output: minipli@bell:~/src/paxtest (master)$ ./contrib/check_align.sh /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0 /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0 (max align=0x20) minipli@bell:~/src/paxtest (master)$ readelf -Wl /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0 | grep -B2 LOAD Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x 0x 0x00405c 0x00405c R E 0x20 LOAD 0x004dd0 0x00204dd0 0x00204dd0 0x000370 0x000398 RW 0x20 The cause for the excessive segment alignment of 2MB instead of the usual 4kB is binutils' ld which did, from versions v2.11 up to v2.30 (in Debian, at least), use a huge default, even if no segment required such a huge alignment. That was fixed in Debian with the release of buster, which makes use of binutils v2.31+. The full technical background behind overly huge alignment was reported here: https://grsecurity.net/toolchain_necromancy_past_mistakes_haunting_aslr Rebuilding the package will implicitly make use of a recent version of ld and thereby fix the issue which is what I'm herby requesting. Thanks, Mathias -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libxxf86vm1 depends on: ii libc6 2.36-9+deb12u4 ii libx11-6 2:1.8.4-2+deb12u2 ii libxext6 2:1.3.4-1+b1 libxxf86vm1 recommends no packages. libxxf86vm1 suggests no packages. -- no debconf information
Bug#1065541: libxshmfence1: Please rebuild to avoid overly huge ELF segment alignment
Package: libxshmfence1 Version: 1.3-1 Severity: normal X-Debbugs-Cc: mini...@grsecurity.net Dear Maintainer, After investigating ELF binaries and libraries on Debian systems, I noticed that libxshmfence1 uses an overly huge alignemnt for its segments. This will lead to an unnecessary ASLR degradation for (transitive) users of this library like xserver-xorg-core, cinnamon or gnome-software. Below is the relevant output: minipli@bell:~/src/paxtest (master)$ ./contrib/check_align.sh /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0 /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0 (max align=0x20) minipli@bell:~/src/paxtest (master)$ readelf -Wl /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0 | grep -B2 LOAD Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x 0x 0x000df8 0x000df8 R E 0x20 LOAD 0x000e00 0x00200e00 0x00200e00 0x000270 0x000278 RW 0x20 The cause for the excessive segment alignment of 2MB instead of the usual 4kB is binutils' ld which did, from versions v2.11 up to v2.30 (in Debian, at least), use a huge default, even if no segment required such a huge alignment. That was fixed in Debian with the release of buster, which makes use of binutils v2.31+. The full technical background behind overly huge alignment was reported here: https://grsecurity.net/toolchain_necromancy_past_mistakes_haunting_aslr Rebuilding the package will implicitly make use of a recent version of ld and thereby fix the issue which is what I'm herby requesting. Thanks, Mathias -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libxshmfence1 depends on: ii libc6 2.36-9+deb12u4 libxshmfence1 recommends no packages. libxshmfence1 suggests no packages. -- no debconf information
Bug#1065540: libxdmcp6: Please rebuild to avoid overly huge ELF segment alignment
Package: libxdmcp6 Version: 1:1.1.2-3 Severity: normal X-Debbugs-Cc: mini...@grsecurity.net Dear Maintainer, After investigating ELF binaries and libraries on Debian systems, I noticed that libxdmcp6 uses an overly huge alignemnt for its segments. This will lead to an unnecessary ASLR degradation for (transitive) users of this library like xserver-xorg-core, lightdm, cinnamon-session, cinnamon-settings-daemon, pipewire-bin and many others. Below is the relevant output: minipli@bell:~/src/paxtest (master)$ ./contrib/check_align.sh /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 (max align=0x20) minipli@bell:~/src/paxtest (master)$ readelf -Wl /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 | grep -B2 LOAD Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x 0x 0x0046c4 0x0046c4 R E 0x20 LOAD 0x004de0 0x00204de0 0x00204de0 0x000308 0x000310 RW 0x20 The cause for the excessive segment alignment of 2MB instead of the usual 4kB is binutils' ld which did, from versions v2.11 up to v2.30 (in Debian, at least), use a huge default, even if no segment required such a huge alignment. That was fixed in Debian with the release of buster, which makes use of binutils v2.31+. The full technical background behind overly huge alignment was reported here: https://grsecurity.net/toolchain_necromancy_past_mistakes_haunting_aslr Rebuilding the package will implicitly make use of a recent version of ld and thereby fix the issue which is what I'm herby requesting. Thanks, Mathias -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libxdmcp6 depends on: ii libbsd0 0.11.7-2 ii libc62.36-9+deb12u4 libxdmcp6 recommends no packages. libxdmcp6 suggests no packages. -- no debconf information
Bug#1063088: weston: NMU diff for 64-bit time_t transition
Hello, Le lun. 5 févr. 2024 à 02:54, Steve Langasek a écrit : > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. > I am wondering what is the plan with this package/bug? I noticed that changes related to the 64-bit time_t transition were not uploaded to unstable and because I uploaded several versions in unstable after your NMU in exp, I wonder if I haven't interfered with this transition. Best regards, Dylan
