Re: xz backdoor
On Sun, Mar 31, 2024 at 09:35:09AM +0200, Bastian Blank wrote:
> On Sat, Mar 30, 2024 at 08:15:10PM +0000, Colin Watson wrote:
> > On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote:
> > > I have seen discussion about shifting away from the whole auto(re)conf
> > > tooling to CMake or Meson with there being a reasonable drawback to CMake.
> > > Is that something being discussed within Debian as well?
> > It's not in general something that Debian can unilaterally change. And
> > in a number of cases switching build system would be pretty non-trivial.
>
> What we can do unilaterally is to disallow vendoring those files.
>
> Does it help? At least in the case of autoconf it removes one common
> source of hard to read files.
That's doable unilaterally to some extent, using the dh-autoreconf style
of approach: the files may be vendored in the upstream tarball, but
we'll throw them away and rebuild them. I did that recently for the
packages that use gnulib where I'm upstream (e.g.
https://salsa.debian.org/debian/libpipeline/-/commit/b596ee5555fb342e93136cf1f479415981fc7f48).
Frankly, I suspect that it will introduce slightly more FTBFS bugs over
time due to differences between the packaged version of gnulib and the
version in use upstream (although things have got better in that regard
over the last year or so with the introduction of stable branches), but
it does seem to be worth it for transparency.
It's going to take some extra work in some cases though. For example,
when I looked at groff, I quickly ran into needing
https://lists.gnu.org/archive/html/groff/2024-03/msg00211.html. And in
cases where upstreams have just copied some individual files from gnulib
rather than adopting the bootstrap script, there may be a bigger hill to
climb.
--
Colin Watson (he/him) [cjwatson@debian.org]
Reply to: