Paul Eggert <egg...@cs.ucla.edu> 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.
