Hi, Short introduction: I work at Canonical in the Foundations team and made changes in gnutls which is one of the packages that first encountered/caused issues which then started blocking various migrations and changes.
On Fri, Nov 24, 2023, Matthias Klose wrote: > On 24.11.23 07:19, Emanuele Rocca wrote: > > Hello! > > > > On 2023-11-24 01:34, Guillem Jover wrote: > > > According to https://bugs.debian.org/918914#73 there were no pending > > > toolchain issues related to this. > > > > That is correct. The GCC maintainers at Arm confirm that > > stack-clash-protection is supported on 32 bit too. > > yes, but it's a different implementation, that apparently breaks a few more > things than on the other architectures where it is enabled. > > > > In case there are any bugs, which is of course possible, please file > > them and add debian-arm@ to X-Debbugs-CC. > > No, I will not do that. Sorry, but the task of the porters it NOT to put > this kind of work on the shoulders on others, but to do this analysis > themself. You seem to rely on every other package maintainer to figure out > these issues on their own. Please don't do that. > > Debian is the first distro to turn this on on armhf, but didn't do any > checks or test rebuilds before turning this on. > > > So far I'm only aware of an issue with plplot, which turned out to be an > > actual bug in the software that stack-clash-protection helped uncover: > > https://bugs.debian.org/1055228#24 > > I filed now > https://bugs.launchpad.net/ubuntu/+source/libselinux/+bug/2044506 > to collect some information what Ubuntu apparently hit. Thanks. I put some details on https://code.launchpad.net/~adrien-n/ubuntu/+source/dpkg/+git/dpkg/+merge/456181 and I'll expand the information on the bug but I need a couple hours first. I expected the topic to be shorter somehow (it was late in the day :) ). > A major problem will be valgrind stopping to work, causing issues in the > test suites of other packages. > > Also after rebuilding libxml2, libarchive, gnutls28, libselinux without this > flag on armhf, issues go away again. I'm not directly working on these, so > can't give more information. I'm not opposed to investigating the issues but the number of failures we'll get is still unknown, and their source and whether it would actually be due to the use of valgrind aren't clear. In any case, the failure under valgrind is 100% unexploitable. I want to look at that plplot bug in order to understand how this helped find an actual bug because what I've seen so far doesn't lend itself to quick analysis. What I'm not convinced is that packages should be uploaded in that state. As far as I understand, it's possible to work on the libraries of a single package at a time and a test rebuild followed by an (emulated) autopkgtest should be enough; iterating maybe wouldn't be incredibly fast but still probably much faster than iterating through the archive. Moreover a local build is probably needed anyway because AFAICT there's nothing to learn from the current test logs. I'm not here to tell how to run Debian and it's probably worth noting that we're still early in the current debian cycle while we're quite far in the ubuntu cycle for an LTS release (plus holidays season). This might lead to different solutions but in any case, the change and the breadth and depth of its consequences were a surprise; this is recent yet the problematic packages were really quickly piling on. Reflecting a bit more on this: would the issues raised be always similar? I mean, if we expect the same kind of issues in most packages and the same solutions, we should make a guide for maintainers so they can address this quickly. And if it's likely different every time, we need to think about the maintainers' time and availability. -- Adrien
