Re: xz backdoor
In days of yore (Sun, 31 Mar 2024), Bastian Blank thus quoth:
> 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.
Reduction of complexity is IMHO always worthwhile as it would open the
door for more people being able to step up as maintainers (taking into
account that volunteers right this minute might not be overly welcome and
when they are, they should likely not be near authentication, crypto and
compression at least initially).
Not worth boiling the ocean over, but is there an estimate of how many
packaged projects have customisations to their autoconf that is not found
in the upstream autoconf project? If that number is low single digit
percent, it may motivate those projects to upstream their modifications.
If it is double digits percent, it might not be possible to disallow
vendoring the files.
--
Kind regards,
/S
Reply to: