Luca Boccassi <bl...@debian.org> writes: > On Wed, 17 May 2023 at 01:05, Russ Allbery <r...@debian.org> wrote:
>> I do think the industry is moving away (well, has already moved away) >> from Linux Standards Base pre-compiled C binaries without wrappers like >> snap or flatpak, although there are some very notable exceptions, such >> as Steam's special use cases explained elsewhere on the thread. I >> don't believe the industry is moving away from Go and Rust binaries, so >> this is, I think, a more complicated picture than your description >> indicates. > I know absolutely nothing about Go, and preciously little about Rust, > but my understanding from news article and so on was that both of those > ecosystems pretty openly avoid "traditional" distributions, in favour of > their own self-contained ecosystems. I think apt-cache search will show that's a significant overstatement and quite a lot of Go and Rust code is packaged for Debian. Lots of Debian maintainers put a lot of hard work into that. > So would that use case be affected, even by an hypothetical and at this > point extremely unlikely archive-wide change? If we only modified specific core packages to use a different PT_INTERP, obviously only those packages would be affected and execution of general Go and Rust binaries would not be affected. I suspect none of those core packages today are Go or Rust. (I do think it's likely that we'll have critical bootstrapping packages written in Rust within the next decade, though.) If all Debian packages were built with a different PT_INTERP but the toolchain itself was not modified, then Go and Rust binaries packaged for Debian could not be copied to and run on non-Debian Linux systems (unless it happened to work by accident because those Linux systems were also /usr-merged and thus the non-canonical PT_INTERP also was present on those systems). This would be unfortunate and surprising and I'm sure that it would break use cases that currently work, but it probably wouldn't be catastrophic. Still, it would obviously be a regression. If the toolchain shipped with Debian were modified to build binaries with a different PT_INTERP, then Go and Rust binaries built with that toolchain would not work on other Linux distributions. If every other major Linux distribution were /usr-merged and thus the modified PT_INTERP worked somewhat by accident on most other distributions, this likewise would still break some things for some people, but similar to the previous point it would be a regression but probably wouldn't be catastrophic. It would be more serious than the previous problem, though, since now we're affecting user-built binaries and not just packaged binaries. Many more of those will be built with the intent to copy them to other systems. If changes caused Go and Rust binaries built on Debian to not work on numerous major non-Debian Linux distributions, I would consider that a serious release-critical bug. But that doesn't seem all that likely from this specific change assuming that the modified PT_INTERP would also be present on other major Linux distributions such as Red Hat, Fedora, SuSE, Arch, Gentoo, etc. I am *assuming* those are all /usr-merging, and thus it might be, but I have not tracked this and do not know if that's true. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
