Re: xz backdoor
On Sun, Mar 31, 2024 at 11:59:35AM +0100, Colin Watson wrote:
> > 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.
No, I don't think that this is adequat. There are too many ways they
could still be used accidentaly or on purpose. The only way to make
sure it is never used, is to remove it all.
In other words:
dh-autoreconf fails open: if something happens it will just use the
vendored stuff.
Nuking the files fails close: if something happens it will just not work
at all.
> 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.
Thanks about this first step.
But shipping dead code is not defence in depth. It will just produce
another completely unaudited pool of hard to read code.
Bastian
--
If a man had a child who'd gone anti-social, killed perhaps, he'd still
tend to protect that child.
-- McCoy, "The Ultimate Computer", stardate 4731.3
Reply to: