One of the sad side-effects of the #xz#backdoor is that many projects feel like they need to move away from #autoconf, when the problem wasn’t autoconf itself, but shipping a bunch of .m4 files – and that nobody diffed repo vs tarball (if nobody does that, it doesn’t matter what you do in the repo, e.g. switching build systems).
This is sad because it means cross-compiling stuff will soon no longer be possible, as autoconf is so far the only thing that gets cross-compiling right. CMake is a complete mess, Meson is far from great for cross-compiling and everything else just outright doesn’t support it.
People, clean up your configure.ac, get rid of .m4 and audit repo vs. tarball! That’s less work, much more effective and doesn’t kill cross-compiling!
Also, if you absolutely must blame a piece of software that was used by xz for this: That’ll be #gettext, which was the reason for the insane amount of .m4 files in the first place. gettext is a mess and that is really something we should get rid of.
Regarding the #xz backdoor Jonathan Corbet from https://lwn.net/ thinks that #autoconf is part of the problem: "Why are we still using ancient build systems that almost nobody understands?"
So do I. I have not been using #sendmail for decades which used to have the same #m4 bullshit.
I'm old enough to have begun using #unix before #linux, and in the first years, I used *nix (well, SunOS, Solaris, and Digital OSF/1, to say more precisely) for so long. I'm what nowadays is considered a Veteran Unix Admin or #vua. I'm still curious enough to stay updated about current tech, but I wonder how many people out there in the #fediverse are still passionate about tech novelties but even cultivate legacy knowledge such as #C, #Perl, #Tcl, #autoconf and #automake, #m4 and above all why?
(this is planned to become a default in make dist—the limit is there to support some really old tar implementations—but currently the default is still tar-v7 with max 99 chars)