I agree that autocrap is the worst build system in use now. However writing plain Makefiles is not an option for projects that are more complex than hello world. It is very difficult to write them portably (between various OSes, compilers and make implementations) and to support cross compiling. That’s why developers used to write configure scripts that evolved to autocrap.

Happily we have better alternatives like cmake and meson (I personally prefer cmake and don’t like meson, but it is also a good build system solving the complexity problem).

A lot of projects would be better served with a plain Makefile although for widely posted projects something is required.

Qemu has used a single readable POSIX shell script for configure although recently most of the tests are in meson (avoiding some Makefile shenanigans in the process). While it’s a new syntax to learn at least the intent is clear and reviewable.

One problem the blog missed is that it becomes next to impossible to migrate a build system after some time.

Just considering autotools, configuration is written in an obscure macro language to describe the resulting sh lines.

Boost has been “migrating” to CMake from their B2 (that nobody uses) for like a decade if not more.

The blog says people should move on from autotools, but that’s an impossible solution for too many libraries at this point.

Good writeup. I think the basic issue is a lack of static scanning for open source repos. No, it may not have caught this particular thing, but who knows. This was clever. Devious even. Spread out over time to avoid detection. There may be more out there. We need some scanning tools to be able to detect patterns like this if possible, or new conventions to prevent things like this from happening again.

This blog is great. I wish they did comparison with CMake or meson.

Tbf CMake does many checks like autotools does, but the advantage of Cmake is that the check will not be embedded in the project source like autotools does. It’s in the CMake program. That’s why the project source ends up leaner.

The blog says this, too, but the configure script generated by autotools can become very different depending on the autotools version. Therefore, checking the git diff for security reasons is very difficult. You get thousands of lines of diffs (in sh!) often without proper comment. The git commit message doesn’t help because the best you can understand from there is that someone used their own autotools version.

Nobody has the time to check the thousands of lines of crap in one git diff. Or maybe millions of them.

If you stop shipping autotools generated artefacts in your tarballs, things will be a lot simpler.

Weirdly enough the malicious code does look eerily similar to the benign code, because both are unnecessarily obfuscated.

This is not a human written or readable file you’re talking about. It’s a generated script.