Re: Sourceware mitigating and preventing the next xz-backdoor

[Jonathon Anderson <anderson.jonathonm@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

On Wed, Apr 10, 2024, 07:09 Frank Ch. Eigler <fche@elastic.org> wrote:

> Hi -
>
> > In Autotools, `make dist` produces a tarball that contains many
> > files not present in the source respoitory, it includes build system
> > core files and this fact was used for the xz attack. In contrast,
> > for newer build systems the "release tarball" is purely a snapshot
> > of the source repository: there is no `cmake dist`, and `meson dist`
> > is essentially `git archive` [...]
>
> For what it's worth, not every auto* using project uses "make dist" to
> build their release tarballs.  If they can get over the matter of
> including auto*-generated scripts being located in the source repo,
> then indeed a "git archive" is sufficient.


This is very true, however a few words of caution: IME this is a
maintainability nightmare. Fixing patches that forgot to regenerate,
regenerating on rebase, confirming everything is up-to-date before merge,
etc etc. It can be handled, I have, but it was painful and
time-consuming.The hardest part was ensuring everyone was actually running
the "right" version of Auto*. (
Did you know Debian ships a different version of the *.m4? That caused more
than a few hours lost to confusion:
https://sources.debian.org/src/autoconf/2.72-2/debian/patches/add-runstatedir.patch
)

To make matters worse, this behavior adds a lot of near-duplicate code and
large unreadable changes to patches. For my team that meant we didn't often
read the generated parts of patches with build system changes, and
definitely not close enough to detect any malicious injections. Which
should make everyone here squeamish given the recent xz attack.

Thanks,
-Jonathon

>