In the wake of the malicious compromise of xz, we should take some reasonable steps here to try to mitigate issues in the future. Notably, the major avenue of compromise involved a malicious modification to the m4 scripts used in building xz through Autotools.

I propose we consider doing three things:

1. If a project supports Autotools and another supported build system (such as CMake or Meson), that should be preferred instead. With CMake and Meson as examples, we have many more knowledgeable people that can understand what's going on and examine the build scripts. Furthermore, both build systems do not rely on pregenerated code, so it's much easier to understand what is going on in the first place. In the xz case, it also supports being built with CMake, and we should consider switching to that.
2. If a project only supports Autotools, we should regenerate all the build scripts to verify it's fully buildable from sources.
3. We need a macro that regenerates the build scripts and also forces the replacement of m4 macros with packaged variants as available and provide guidance of what build dependencies are needed at the minimum for Autotools projects.

These are just my early morning thoughts based on what I think would be appropriate for us to do. We could also put a recommendation that packagers consider engaging with upstreams to convince them to convert away from Autotools to something more supportable, but I'm not sure that's feasible advice.