More and more software seems to have taken to using GNU autoconf, or more properly configure scripts generated by it, for configuration, despite variety in systems decreasing rather than increasing and thus the need for all-singing-all-dancing automated configuration diminishing rather than growing. Today's rant is about such configure scripts and why they are a very bad idea.
First, they don't do what they try to, and pretend to, do: automatically configure the software correctly for the system it's being built on. I have four cases at ready hand to cite (and these are just the ones that come to mind immediately). Package version numbers cited below were all the most current version at the point at which I fetched them, and they weren't all observed on the same system, but were each observed on at least one system.
checking number of arguments to statfs()... unknown configure: error: unable to determine number of arguments to statfs()The crash arises because the configure script tries to probe for the existence of statfs() by checking whether a program calling it links, after going to some lengths to avoid going anywhere near any API that might exist. This succeeded because the system in question has a compatibility ABI version of statfs(). But then, having discovered that an ABI exists, it assumes an API for it must exist as well and tries to discover things about it. Since the API does not exist (the ABI exists only for binary compatibility), this fails, and the script's pointy little head explodes rather than falling back to the substitute it would have used if it couldn't find statfs() at all.
I'm sure each of these works just fine when run on the developers' dev boxes. That's irrelevant; the whole point of configure scripts is to auto-adjust to disparate build environments, and far too often they fall flat on their faces at that.
Second, such configuration scripts are a security disaster waiting to happen. They are basically perfect trojaning targets: mind-numbing to try to vet manually, very hard to sandbox (at best you end up configuring the software to run in the sandbox), difficult to check with automated assistance (usually substantially harder to check than the software they're configuring), and far too often run as root (and, even when not, quite often run as a user that root trusts).
I'm not very afraid, given the sort of software I'm interested in installing, of software authors deliberately trojaning their configure scripts. I'm much more concerned about a distribution site getting cracked; less likely but far worse if it happens, the possibility of a developer's dev machine getting cracked and having a trojaned version of autoconf installed on it.
Third, and perhaps worst from a long-term perspective, configure scripts encourage people to blindly run software they've just fetched from the net. While admittedly this would happen anyway with the software putatively being configured, that software is often at least somewhat feasible to vet. I think making the first step be the running of a piece that's approximately impossible to check in any way is a disaster in the attitudes and habits it develops in people.
./configure: Just Say No.