Debian recommends using autoreconf and provides their rationale and some guidance for doing so here:
https://wiki.debian.org/Autoreconf On Mar 24, 2025, at 16:59, Fred Wright wrote: > > Yes, it may avoid that one particular form of malware, but in general, > unnecessary rebuilding expands the attack surface to include more potential > toolchain attacks. This isn't purely theoretical: > > https://wiki.c2.com/?TheKenThompsonHack > https://irreal.org/blog/?p=11754 I've heard this theory before, which is that you can't know whether your toolchain (compiler, linker, other programs that generate code) has been compromised and will insert malware into generated files. I don't think it's relevant to the discussion. If you believe the toolchain MacPorts uses is compromised, then you can't trust the sanctity of anything MacPorts has installed, or indeed anything else on your computer. And if you don't believe the toolchain is compromised, then it is acceptable and reasonable to use autoconf or compilers or linkers or any other programs to generate files, as most ports already do. > Another reason is that auto[re]conf is one of the worst tools on the planet > when it comes to reproducibility. In principle, rerunning autoconf on the > same input *should* produce an *equivalent* 'configure', but in practice the > result is usually so diff-proof that it's impractical to easily verify that. > So unless you're confident that you have good enough test coverage to catch > unwanted 'configure' changes, it's safest just to leave the provided > 'configure' alone (if it works). Obviously nobody diffs generated configure scripts especially when autoconf versions differ. That fact is how the xz-utils backdoor could be inserted and go unnoticed. MacPorts doesn't have "test coverage". We have an automated build system. Especially when a new OS version comes out, we rebuild all ports and maybe somebody notices if something doesn't build and fixes it. Many, many build failures these days are because of new compilers issuing errors for old coding practices that old compilers just warned about. If those errors are in ancient generated configure scripts, and if autoreconf can update the configure script, then if we had already been using autoreconf, we wouldn't be encountering so many of these problems and spending so much time fixing them (or, it seems, lately, just leaving them broken for years). The point is that a configure script that "just works" today may not work tomorrow on a newer compiler and proactively using autoreconf should help with that. > Sometimes issues arise that require changing something in 'configure', which > leads to the question of how best to handle that. There are several options: > > 1) Patch 'configure' and avoid rerunning autoconf. This is the simplest > approach, but it's fragile, since anything that causes autoconf to rerun will > wipe out the patches. This is what most ports do and what we currently recommend when it is not inconvenient. ("Inconvenient" would include when the resulting configure patch file is huge whereas the configure.ac patch file would be tiny.) It's not especially fragile. Nothing will suddenly cause autoreconf to run. It does cause additional work sometimes if a port is updated, the new version still needs the patch, and the generated configure script has changed substantially. Patching configure.ac instead and using autoreconf eliminates that work. > 2) Patch the sources of 'configure' and rerun autoconf. This is the > conceptually cleanest approach, but it not only adds unnecessary build time > but also adds the reproducibility/verifiability issue noted above. This is what I am proposing we switch to. As I said, added build time is decreasing to negligibility as computers get faster. I'd rather our build machines spend a few more seconds on a build than spend an hour of my time manually patching an old configure script. > 3) Patch both and don't rerun autoconf. This is in principle a reasonable > belt-'n-suspenders approach, and may work fine for some projects, but some > projects include a Makefile rule that reruns autoconf whenever 'configure' is > considered to be outdated, thereby possibly being like #2 (perhaps > opportunistically). > > 4) Patch both in separate patchfiles, and ensure that they run in the correct > order so that 'configure' has a later mtime than its sources. This is in > principle a good fix for #3, but only if mtimes have sufficiently high > resolution on all relevant systems to ensure that the mtime of 'configure' is > strictly greater than those of its sources. Since many systems only have > one-second resolution on mtimes, this may not be reliable. > > 5) Patch both in separate patchfiles, ensure that they run in the correct > order, and bump the mtime of 'configure' by one second. This is a version of > #4 which works reliably on any system whose mtime resolution is one second or > better. It's a bit kludgy in that the mtime of 'configure' may be in the > future for up to one second, but it's doubtful that anything cares about > that. It's also questionable that any MacPorts build could progress from the > patch phase to any build phase within one second as long as it remains > written in Tcl. :-) > > Approach #5 is what I currently use in the Ruby ports that need 'configure' > patches. None of these are recommended. If I had noticed you were using them in the ruby ports I would have asked you to switch to one of the first two methods.
