61–70 of 169 posts
In all likelihood there's no process to do such an audit? Let's assume such a process did exist, forcing attackers to take a different strategy. Could the rain have hidden in plain sight in the source repo anyways?
Autoconf is one of the absolutely hilarious things about UNIX. On the one hand, we've got people optimizing kernels down to the individual instructions (often doing very unsafe dirty C tricks underneath), sometimes with super-clunky and overly complex APIs as a result...and on the other hand you have all the shell script absolute nuttery like the behemoth heap of kludges that is autoconf. It's crazy to me the disconn…
> scripts and autoconf and all that stringly-typed pipe stuff, ended up becoming (IMHO) the most reusable, pluggable programming environment yet devised... I mean yes, but also only because the rest of computing is stuck in the same era. Meanwhile I'm over here popping nix-shells having my nice exact same nushell on every machine I could possibly want it on. IMO it's all symptoms of the same problems. Related, I don'…
You can pre-answer most autoconf sections using /etc/config.site, and a system distributor can create an /usr/share/config.site[1]. It's just really hard to get right, nobody uses it effectively. Autoconf also has a config.cache[2], which it uses to store answers to reuse across multiple of the same checks and reruns of the configure script. [1]: https://www.gnu.org/software/autoconf/manual/autoconf-2.63/h... [2]: ht…
and if I understand correctly, any such /etc/config.site falls prey to one of the more famous N problems in computer science, since the only truly stable things one could put in any such file would be the host triple and byte order. Maybe if there was a systemwide hook into deb or rpm to regenerate it after any package updates it would solve the cache invalidation part
Earlier quoted context omitted.
I use autotools for my C++ projects and I hate it (in my weak defense, I hate cmake more). config.cache helps (and ccache helps a lot, too; most of my ccache hits are on stupid autoconf test programs; ya gotta use ccache if you use autoconf), but rerunning configure is still s l o w. Worse, automake and autoconf have a cyclic dependency, so if you're a developer (as opposed to a user building from source on a system)…
libtool does serve a purpose: it causes plain 'make' to produce shell script wrappers as outputs, which is maybe kinda sorta vaguely useful when developing and utterly and completely obnoxious if you want an actual ELF file. So you end up running 'make install' when you didn’t actually want to install or trying to remember how to find the actual ELF files. And you then wonder why 'make install' appears to be building…
Earlier quoted context omitted.
> scripts and autoconf and all that stringly-typed pipe stuff, ended up becoming (IMHO) the most reusable, pluggable programming environment yet devised... I mean yes, but also only because the rest of computing is stuck in the same era. Meanwhile I'm over here popping nix-shells having my nice exact same nushell on every machine I could possibly want it on. IMO it's all symptoms of the same problems. Related, I don'…
Which comment about Meson are you referring to?
You can pre-answer most autoconf sections using /etc/config.site, and a system distributor can create an /usr/share/config.site[1]. It's just really hard to get right, nobody uses it effectively. Autoconf also has a config.cache[2], which it uses to store answers to reuse across multiple of the same checks and reruns of the configure script. [1]: https://www.gnu.org/software/autoconf/manual/autoconf-2.63/h... [2]: ht…
I use autotools for my C++ projects and I hate it (in my weak defense, I hate cmake more). config.cache helps (and ccache helps a lot, too; most of my ccache hits are on stupid autoconf test programs; ya gotta use ccache if you use autoconf), but rerunning configure is still s l o w. Worse, automake and autoconf have a cyclic dependency, so if you're a developer (as opposed to a user building from source on a system)…
No you don't: automake generates rules for `Makefile.am -> Makefile.in` (`automake`) and `Makefile.in -> Makefile` (`config.status`). You should just be able to edit `Makefile.am` and run `make`.
> Is it really less effort to write Makefile.am than to write a straight Makefile? Wouldn't that be simpler?
I don't think so. Not if you want to get DESTDIR support right, and proper dependency tracking (dep info as a side-effect of compilation, so you get all the headers and don't slow down one-off builds), and support for all the standard Makefile targets, etc.
As for your "which build tool to actually use?" question, I wrote a longer post about that in the context of bootstrappable software: http://jackkelly.name/blog/archives/2024/04/01/which_build_t...
It really does seem like autotools remain one of the least bad options, but maybe muon (C99!meson) and samurai (C99!ninja) might be a workable option.
Does autotools really matter here? Did folks at the distros really audit the tainted package contents against the source repo and decide that the additional contents must be legitimate? In all likelihood there's no process to do such an audit? Let's assume such a process did exist, forcing attackers to take a different strategy. Could the rain have hidden in plain sight in the source repo anyways?
Earlier quoted context omitted.
The major downside of using git clone build workflows from an autotools project is that your build environment and the developer's may have different enough versions of autotools that macro incompatibility introduces more problems for you to solve. I've noticed this less recently (say 5 years) but still has come up occasionally. While a distributed tarball will have the "developer blessed" autoreconf run and declared…
Ultimately autotools isn't doing anything magical, so it's not unusual for cross-platform package managers like vcpkg to simply ignore all that and write their own clean CMakeLists.txt. In this particular case xz-utils actually did support CMake for building liblzma, so that's what you use if you don't care about the command line tools.
It's also worth appreciating that in the case of the xz project, the CMake flow is secondary other than for Windows. While I have no evidence one way or another, I wonder if the period in the CMake test that disabled Linux Landlock was actually intentional. Since it disabled it for the CMake build and not the autotools build, it seems like it could have been accidental, unless some significant liblzma consumer builds with CMake and would have otherwise had Landlock enabled.