Autoconf and m4 [LWN.net]

Autoconf and m4

Posted Apr 30, 2024 20:23 UTC (Tue) by Paf (subscriber, #91811)
In reply to: Autoconf and m4 by epa
Parent article: Security patterns and anti-patterns in embedded development

RE: Assume sensible defaults.

The problem - or so it seems to me - is that configure is the main way builds find and report missing dependencies. So I'm building X and the build requires totally-reasonable-but-not-universal library Y (or god forbid it requires obscure library Z). Those dependencies are generally expressed via the configure script. Seems like a non-starter.

to post comments

Autoconf and m4

Posted Apr 30, 2024 20:50 UTC (Tue) by epa (subscriber, #39769) [Link] (2 responses)

But if the deps are missing the build will fail anyway. The configure script is mostly for configuring optional dependencies. (We saw this used in the xz attack, I believe, where the detection of Landlock was subtly broken so that the build continued without it.)

There will be exceptions, but generally I think you could define a default build that requires most of the dependencies without having to sniff whether they are available. If that’s not flexible enough for everyone, some will stay using the configure script.

Autoconf and m4

Posted May 1, 2024 7:16 UTC (Wed) by epa (subscriber, #39769) [Link] (1 responses)

I guess one improvement would be a "strict mode" for the configure script where everything has to be explicitly specified as either --with-foo or --without-foo. If some new dependency appears then you'd get a message like

This configure script was invoked with --strict. The optional dependency 'libfoo' has not been specified.
You must pass either --with-libfoo or --without-libfoo.
Autodetection found that libfoo is present on this system.

Then build systems for Linux distributions would tend to use the --strict flag and nail down exactly what dependencies they want, leaving nothing to autodetection. That would have stopped the xz attack where the configure script stopped including the Landlock dependency and nobody noticed.

Autoconf and m4

Posted May 3, 2024 1:22 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Yes, I've found that explicit requests for things like that are best. It's really frustrating when you copy a configure line from one machine to another and get a result because somewhere in the middle of the log dependency X's state differed between the two machines and you're left figuring out why behavior Y differs. *Some* things make sense to just inspect and change, but that's for things that you can polyfill (BSD routines on Linux or glibc routines elsewhere) or are just plain impossible on the platform (e.g., v4l support on macOS or Windows).