Re: Sourceware mitigating and preventing the next xz-backdoor

Paul Eggert <[email protected]> writes:

> On 4/9/24 14:40, Jeffrey Walton wrote:
>> Code provenance and code integrity was not enforced. Part of the
>> problem is the Autotools design. It is from a bygone era.
>
> No, Andreas is right. This isn't an Autotools-vs-Meson thing.
>
> Most of the Autotools-based projects I help maintain would have been
> immune to this particular exploit, partly because they don't maintain
> their own of Gnulib .m4 files. Conversely, any Meson-based project
> that had the same sort of out-of-repository sloppiness and lack of
> review that xz had, would be vulnerable to similar attacks.
>

While it could indeed happen via a variety of methods, it's still worth
talking about how to reduce places for it to hide in, and make review
easier, I think.

>> No one should be able to override a named, GNU supplied m4 macro.
>
> That ship sailed long ago, for Autoconf and for Meson and for every
> other widely-available build tool I know of. Everyone can write and
> run their own code, whether it comes from GNU or not. That's a feature
> that developers want and need. Although this feature can be misused,
> it's not a bug per se.

Meson doesn't allow user-defined functions and macros to avoid
metaprogramming hell:
https://mesonbuild.com/FAQ.html#why-doesnt-meson-have-user-defined-functionsmacros.